The Wire Image of a Network Protocol(tools.ietf.org)
tools.ietf.org
The Wire Image of a Network Protocol
https://tools.ietf.org/html/rfc8546
12 comments
This brings up some interesting considerations
I personally believe in absolute freedom of speech so from a network engineering perspective this manifests as a personal responsibility to make the networks I control pass packets without discrimination. The public internet is just a conglomeration of seperate private networks that operate under their own sets of rules.
To have absolute freedom when passing traffic the underlying protocol should be fully encrypted and probably even hide the source and destination IP address and port. This is a very tough problem to solve technically because you have to know the destination IP to efficiently route a packet.
I personally believe in absolute freedom of speech so from a network engineering perspective this manifests as a personal responsibility to make the networks I control pass packets without discrimination. The public internet is just a conglomeration of seperate private networks that operate under their own sets of rules.
To have absolute freedom when passing traffic the underlying protocol should be fully encrypted and probably even hide the source and destination IP address and port. This is a very tough problem to solve technically because you have to know the destination IP to efficiently route a packet.
The destination IP could be hidden opportunistically?
Send the destination IP for high-priority requests and retry without the destination. Low-priority/long-latency requests would always hide the destination.
... I can't articulate why, but I feel even this introduces a very large amount of hidden complexity. It solves efficient routing and freedom in part, but does not consider privacy.
Send the destination IP for high-priority requests and retry without the destination. Low-priority/long-latency requests would always hide the destination.
... I can't articulate why, but I feel even this introduces a very large amount of hidden complexity. It solves efficient routing and freedom in part, but does not consider privacy.
I don't see how you can hide destination IP. Each router has to know the destination IP to determine where to send the packet, yes there are some cases such as MPLS/VXLAN/v4VPN where the packet is encapsulated inside more routing info but for it to get to its destination the routers have to have an IP.
If the routers have public keys it's possible, then the client has to determine (some or all points on) the route. I think future protocols will track use and payment via client-provided keys which are somehow linked to their ISP.
Of course for this reason QUIC is sometimes blocked outright in organizations that deploy those TCP middleboxes.
one of the primary reasons for openflow was to work around ‘ossification’ of core internet protocols. almost all seminal sdn/openflow papers (notably those from mckeon) do bring it up...
What is this specifically aimed at? The entire point of the End to End Principle is that mid-nodes should be passing packets, not mucking about with them. Everything that has been developed contrary to that (eg DPI boxen) are basically exploits of security vulnerabilities attempting to force the old top-down telco services model.
So yes, putting a name on what m[ie]ddle nodes can observe is useful. But I have to ask for what end, given that any modern protocol should be aimed at reducing this "wire image" to the absolute minimum possible. The only reason necessitating still using plaintext-header TCP/UDP is because we're stuck with NAT, and the only reason to use ip.saddr is because we're stuck with egress filtering.
So yes, putting a name on what m[ie]ddle nodes can observe is useful. But I have to ask for what end, given that any modern protocol should be aimed at reducing this "wire image" to the absolute minimum possible. The only reason necessitating still using plaintext-header TCP/UDP is because we're stuck with NAT, and the only reason to use ip.saddr is because we're stuck with egress filtering.
The problem is, even in a situation with only good faith actors, not every codepath is equally developed/tested/working, and bugs creep in. Especially if some parts of a protocol are there for future use. Then if a buggy implementation gets widespread, that effectively nixes that part of the future potential of the protocol.
That's why, if you think about a clever solution for something, and your solution depends on the letter of the standard instead on actual large scale experiments, then the risk of stumbling into big problems is large. Sure, it might be only 1-5% of the Internet that cannot use your clever solution. But historically developers opted to chose solutions that work for 99.9%, even at the cost of even more layers/encapsulation/complexity.
That's why, if you think about a clever solution for something, and your solution depends on the letter of the standard instead on actual large scale experiments, then the risk of stumbling into big problems is large. Sure, it might be only 1-5% of the Internet that cannot use your clever solution. But historically developers opted to chose solutions that work for 99.9%, even at the cost of even more layers/encapsulation/complexity.
Doesn't this line up with my point? What you're saying seems to be most relevant in the context of unaccountable meddle boxes - eg I fully agree if you want your protocol to work widely, you have to accept the current Internet as it is and set ip.proto = {1,6,17}.
But to avoid creating even more of these constraints you want to keep as much as possible out of sight of the meddle boxes, lest they get ideas to start doing even more filtering. Given that crypto is now computationally inexpensive, this seems straightforward with anything that is not already in IP/TCP/UDP headers.
But to avoid creating even more of these constraints you want to keep as much as possible out of sight of the meddle boxes, lest they get ideas to start doing even more filtering. Given that crypto is now computationally inexpensive, this seems straightforward with anything that is not already in IP/TCP/UDP headers.
It lines up, I just wanted to point out that there needs to be no malicious exploitative intent, this kind of network state degradation naturally follows from the always ongoing optimization of resource allocation by actors involved in the process. And thus there is a natural priority of features when it comes to network equipment design, development, production, testing, marketing, support and eventual replacement.
And yes, crypto helps with enforcing the layers, it forces engineers to move to a different part of the solution space when it comes to doing things that used to be done with DPI/snooping/etc. (A lot of the meddleboxes were sort of rational responses, like a MITM caching proxy, DNS hijacking, captive portals, blablabla. And they were quick and dirty.)
And yes, crypto helps with enforcing the layers, it forces engineers to move to a different part of the solution space when it comes to doing things that used to be done with DPI/snooping/etc. (A lot of the meddleboxes were sort of rational responses, like a MITM caching proxy, DNS hijacking, captive portals, blablabla. And they were quick and dirty.)
I stand by the characterization of "exploitative". The point of protocols is to mediate between parties with diverging interests. The parties deploying meddle boxes are rationally trying to further their own interests, but they are doing so by stepping over the delineating line. In 2019, the idea that neighborly courtesy would preserve the line was obviously naive. Now we need to build concrete walls.
And lest you think that my viewpoint is completely at odds with network administrators - elsewhere I've argued that raw unrestricted IP access will eventually come to be seen as a bug. Surveillance companies backhaul much of their collect unhindered precisely because "Internet access" is given as an all-or-nothing condition. IP is actually horrible for addressing such concerns, which is why attempts at egress firewalls devolve into idiotic "block everything but 80/443" (and then new devices respond by working over HTTPS).
I think in the future, if we're lucky, the equivalent of firewalls will be based around type systems over PDUs, and embedded devices will be forced to specify exactly what they communicate. But those capabilities need to be kept at personal network edges (or even per-user) by devices' owners making them transparent (akin to installing a personal CA), with traffic over the centrally-controlled transit network remaining completely opaque.
And lest you think that my viewpoint is completely at odds with network administrators - elsewhere I've argued that raw unrestricted IP access will eventually come to be seen as a bug. Surveillance companies backhaul much of their collect unhindered precisely because "Internet access" is given as an all-or-nothing condition. IP is actually horrible for addressing such concerns, which is why attempts at egress firewalls devolve into idiotic "block everything but 80/443" (and then new devices respond by working over HTTPS).
I think in the future, if we're lucky, the equivalent of firewalls will be based around type systems over PDUs, and embedded devices will be forced to specify exactly what they communicate. But those capabilities need to be kept at personal network edges (or even per-user) by devices' owners making them transparent (akin to installing a personal CA), with traffic over the centrally-controlled transit network remaining completely opaque.
I'd never heard of the term 'ossification' regarding a protocol before. But "QUIC as a solution to protocol ossification" from LWN [1] clears it up:
> TCP suffers other problems as well. ... Middleboxes (routers between the endpoints of a connection) interfere with traffic and make it difficult to improve the protocol. They aren't supposed to be looking at TCP headers, but they do so anyway and make decisions based on what they see, often blocking traffic that looks in any way out of the norm. This "ossification" of the protocol makes it nearly impossible to make changes to TCP itself.
[1] https://lwn.net/Articles/745590/