4 ms·

The Wire Image of a Network Protocol

69 points by okket 8y ago

wyldfire 8y ago
> 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/
- signa11 8y ago
  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...
- solotronics 8y ago
  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 8y ago
    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 8y ago
      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 8y ago
        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.
- jandrese 8y ago
  Of course for this reason QUIC is sometimes blocked outright in organizations that deploy those TCP middleboxes.
mindslight 8y ago
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 8y ago
  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 8y ago
    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.
    - 8y ago

69 points by okket 8y ago

> 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/

signa11 8y ago
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...
solotronics 8y ago
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 8y ago
  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 8y ago
    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 8y ago
      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.
jandrese 8y ago
Of course for this reason QUIC is sometimes blocked outright in organizations that deploy those TCP middleboxes.

mindslight 8y ago

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 8y ago
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 8y ago
  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.
  - 8y ago