
The Wire Image of a Network Protocol - okket
https://tools.ietf.org/html/rfc8546
======
wyldfire
> QUIC is ... the first ... protocol to ... prevent ossification

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/](https://lwn.net/Articles/745590/)

~~~
solotronics
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.

~~~
keepmesmall
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.

~~~
solotronics
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.

~~~
keepmesmall
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.

------
mindslight
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.

~~~
pas
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.

~~~
mindslight
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.

~~~
pas
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.)

~~~
mindslight
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.

