Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Size of Packets

potaroo.net

Post reply on HN
Print view View original

61–70 of 73 posts

Re: The Size of Packets

#61

Post by zamadatix »

ay wrote: post #50
zamadatix wrote: post #48

Earlier quoted context omitted.

Agree wholeheartedly on the pragmatic standpoint of just using minimums. With regard to the problems of out of band signaling in plain PMTUD I fully agree with all your well stated points, doubly so on PLPMTUD! PLPMTUD is my preferred variation of PMTUD and I was glad to see the datagram form utilized in QUIC (especially since it's really a generic secure network tunneling protocol, not just the HTTP variant). I'm al…

> "everyone is expecting 1280" This works great until there is an app that is expecting 1280 and there is an operator that gives you 1280, and you have to run this app over an encrypted GENÈVE tunnel that attempts to add half a kilobyte of metadata :-). RADIUS with EAP or DHCP with a bunch of options can be a good example of a user app like this. Unfortunately this is a real-world problem. The smaller mismatch but no…

Agreed, still not perfect by any means.

One minor Ethernet MTU thing I would change with a time machine is to have the network header portion of the MTU be more like 802.11. I.e. instead of sized exactly to the headers of the day it intentionally was larger to allow variation over time. It wouldn't really do anything for most of the MTU concerns discussed here or for clients but I think it would have been helpful for the evolution of wired protocols.

Happy eyeballs! Yes, I loved that one! I was always a huge IPv6 nerd as well, though I didn't get started until shortly after that. The "nats are good" video isn't ringing any bells but if you have a link I'd definitely give it a watch as it sounds right up my humour alley.

Unfortunately all of that Cisco affiliation means we are forever blood enemies and can never speak again... ;). I kid, I came up through the Nortel heritage originally so I'm bound by contract to make such statements.

I've heard great things about the Fast Data Project, I'll definitely have to look into it some before the Oblivion remake comes out :). Maybe after this current project at work I'll finally get to mess with software based dataplanes properly.

It was great running into you here, I hope to catch you around more now that I know to look!

Re: The Size of Packets

#62

Post by zamadatix »

Veserv wrote: post #54
zamadatix wrote: post #49

Earlier quoted context omitted.

> Your first point appears to be about physical layer concerns. My suggestion was not meant to operate at that level. The proposal doesn't operate at that level but it must be compatible with the operations of that level. I.e. that the physical layer can also cause truncation of layers riding on top of it needs to be accounted for in the way those upper layers consider what truncation means. The same is true for poss…

I just do not understand the problems you are stating. Let me present a concrete example. We have A B C. A wishes to transmit a packet of 0x1000 bytes containing a Ethernet, IPv4, and then bespoke protocol, P, which is a header containing a length, MAC on the length + header, MAC on entire packet, encrypted payload, in that order. A then prepares transmit descriptors pointing at the packet and with size 0x1000 bytes.…

In this process one can only show they are unable to authenticate the packet's length matches the length the header said it should have been i.e. you can only authenticate that nobody tried to claim the MTU should change. You have not provided any authentication to the parts of the message signaling the MTU is now supposed be 0x500.

The authentication header can only helps you authenticate when the MTU stayed the same as expected during delivery, it cannot help you authenticate the signals claiming MTU was supposed to be something else as those modifications, inherently, do not come from nodes partaking in the authentication header. The malicious middleman could falsely truncate a single packet to 0x500 bytes just as easily as they could falsely create an ICMP packet claiming the MTU is 0x500 bytes, in both cases the only thing you know for sure is "someone is trying to claim that last packet was too big".

Re: The Size of Packets

#63

Post by avidiax »

jeffbee wrote: post #25

The efficiency argument applies to private flows mostly. In terms of overall network traffic, the huge majority takes place between peers that share a local or private network. Internetworking as such has a relatively small share of total flows. So large frame sizes are beneficial in the context where they are also not problematic, and path MTU discovery is not beneficial in the context where it has many drawbacks. I…

If you've ever tried to enable jumbo packets on your LAN, you'd soon learn that it causes lots of problems.

First, every L2 "dumb" switch that doesn't support your jumbogram size just silently drops the packet, which is no good.

Then, you have to figure out what size of jumbogram every device on your network supports, and select the minimum. In many cases, you'll have clients that don't support it at all.

And I hope all your OSes support setting an MTU per route, and you enjoy setting special routes on all of your clients, since Path MTU discovery, even where it is enabled and supported, at the very least adds latency to every connection, if it even works at all.

And god help you once you try to scale up your sweet jumbo frame solution. Plenty of routers have strict ICMP rate limits either imposed in software or hardware (because ICMP may be handled in an anemic CPU). So those ICMP fragmentation needed packets aren't reliably returned to your clients. It's even worse if your ISP doesn't block jumbograms outright. You will soon learn which of your ISPs peerings do or don't support jumbograms and whether they do or don't emit or forward ICMP.

The only advisable way to use jumbo frames is if you are running a datacenter and you have a group of machines that can be properly configured for route-based MTU and that would benefit from jumbo frames, and every piece of hardware you buy is carefully specced to support it.

Re: The Size of Packets

#64

Post by ay »

zamadatix wrote: post #61
ay wrote: post #50

Earlier quoted context omitted.

> "everyone is expecting 1280" This works great until there is an app that is expecting 1280 and there is an operator that gives you 1280, and you have to run this app over an encrypted GENÈVE tunnel that attempts to add half a kilobyte of metadata :-). RADIUS with EAP or DHCP with a bunch of options can be a good example of a user app like this. Unfortunately this is a real-world problem. The smaller mismatch but no…

Agreed, still not perfect by any means. One minor Ethernet MTU thing I would change with a time machine is to have the network header portion of the MTU be more like 802.11. I.e. instead of sized exactly to the headers of the day it intentionally was larger to allow variation over time. It wouldn't really do anything for most of the MTU concerns discussed here or for clients but I think it would have been helpful for…

> more like 802.11

L2 is “relatively simple” in a sense that it’s usually under the same administrative control; unlike with L3. And even then, if you have a look at all the complexity between the maintaining the interop in the wireless space… it’s amazing it works as well as it does, with so much functionality being conditional.

> "nats are good" video isn't ringing any bells

https://youtu.be/v26BAlfWBm8?feature=shared - it was a bit of a meme back at the time in making the “X fanboy” videos.

> I came up through the Nortel heritage originally

My networking cradle is Netware 4.1, and in those times it was a zoo of protocols anyway. I really liked conceptually the elegance of Nortel management being SNMP-first. Makes me smile hearing all these “API-first!” claims today.

> It was great running into you here

Indeed, nice to meet you too ! :-)

I do a fair bit of lurking. yesterday was a bit of an anomaly since the whole “truncation as a means to do PMTUD” was a subject of my idle ponder for more than a decade, so it struck the chord :-)

Re: The Size of Packets

#65

Post by ay »

zamadatix wrote: post #60
ay wrote: post #52

Earlier quoted context omitted.

Of course on the carrier boxes the fragmentation is done also not inline, so its behavior will depend on the aggressiveness of the CoPP configuration, and will be subject to the same pitfalls as the ICMP packet too big generation. Thanks for keeping me straight here! Based on the admittedly old study at [0] seems like some carriers just don’t bother to fragment, indeed - but by far not all of them. Firewalls might do…

Very interesting! It's like the best of the fragment-pre-encrypt world (everything appears as single packet 5 tuples to middleboxes) and fragment-post-encrypt world (transported packet data remains untouched) debate seen on IPsec deployments. Like you mention you could do this under QUIC but then you'd be hamstrung to some of the design mandates such as encryption. This is way better as it's just datagrams doing your…

Yeah, that was precisely the set of trade offs :-)

OTOH, I heard folks calling to banish the “no messing with a flow within 5-tuple” principle, so my hack may not have an overly long shelf life.

Re: The Size of Packets

#66

Post by Veserv »

zamadatix wrote: post #62
Veserv wrote: post #54

Earlier quoted context omitted.

I just do not understand the problems you are stating. Let me present a concrete example. We have A B C. A wishes to transmit a packet of 0x1000 bytes containing a Ethernet, IPv4, and then bespoke protocol, P, which is a header containing a length, MAC on the length + header, MAC on entire packet, encrypted payload, in that order. A then prepares transmit descriptors pointing at the packet and with size 0x1000 bytes.…

In this process one can only show they are unable to authenticate the packet's length matches the length the header said it should have been i.e. you can only authenticate that nobody tried to claim the MTU should change. You have not provided any authentication to the parts of the message signaling the MTU is now supposed be 0x500. The authentication header can only helps you authenticate when the MTU stayed the sam…

Can you please explain how a malicious node on your path truncating packets to 0x500 bytes is distinct from a 0x500 byte path MTU?

The distinction between this and a false ICMP packet is that a valid ICMP packet from a node in your path comes from a unauthenticated source. You can not generally distinguish this from a forged ICMP packet from a malicious entity not on your path.

In contrast, the model I propose results in the authenticated endpoint learning of the path MTU in a way that can only be altered by a node in the path refusing to send data beyond a certain size. The authenticated endpoint can then use a authenticated channel to feedback the data allowing the source to get authenticated path MTU information that could only come from the authenticated endpoint.

Re: The Size of Packets

#67

Post by jeffbee »

avidiax wrote: post #63
jeffbee wrote: post #25

The efficiency argument applies to private flows mostly. In terms of overall network traffic, the huge majority takes place between peers that share a local or private network. Internetworking as such has a relatively small share of total flows. So large frame sizes are beneficial in the context where they are also not problematic, and path MTU discovery is not beneficial in the context where it has many drawbacks. I…

If you've ever tried to enable jumbo packets on your LAN, you'd soon learn that it causes lots of problems. First, every L2 "dumb" switch that doesn't support your jumbogram size just silently drops the packet, which is no good. Then, you have to figure out what size of jumbogram every device on your network supports, and select the minimum. In many cases, you'll have clients that don't support it at all. And I hope…

Yeah, but that's really my point. The byte-weighted flow of Ethernet frames on Earth is overwhelmingly happening inside the data centers of a handful of huge organizations.

Re: The Size of Packets

#68

Post by zamadatix »

ay wrote: post #65
zamadatix wrote: post #60

Earlier quoted context omitted.

Very interesting! It's like the best of the fragment-pre-encrypt world (everything appears as single packet 5 tuples to middleboxes) and fragment-post-encrypt world (transported packet data remains untouched) debate seen on IPsec deployments. Like you mention you could do this under QUIC but then you'd be hamstrung to some of the design mandates such as encryption. This is way better as it's just datagrams doing your…

Yeah, that was precisely the set of trade offs :-) OTOH, I heard folks calling to banish the “no messing with a flow within 5-tuple” principle, so my hack may not have an overly long shelf life.

Next up: Everything just ends up being QUIC because you can't fuck with what you can't see inside :).

Re: The Size of Packets

#69

Post by zamadatix »

Veserv wrote: post #66
zamadatix wrote: post #62

Earlier quoted context omitted.

In this process one can only show they are unable to authenticate the packet's length matches the length the header said it should have been i.e. you can only authenticate that nobody tried to claim the MTU should change. You have not provided any authentication to the parts of the message signaling the MTU is now supposed be 0x500. The authentication header can only helps you authenticate when the MTU stayed the sam…

Can you please explain how a malicious node on your path truncating packets to 0x500 bytes is distinct from a 0x500 byte path MTU? The distinction between this and a false ICMP packet is that a valid ICMP packet from a node in your path comes from a unauthenticated source. You can not generally distinguish this from a forged ICMP packet from a malicious entity not on your path. In contrast, the model I propose result…

> Can you please explain how a malicious node on your path truncating packets to 0x500 bytes is distinct from a 0x500 byte path MTU?

Sure, it doesn't even actually have to be truly in-path in all cases, though that makes things easier. I receive a copy of your message (be it I'm actually inline, tap, spoofed arp for a second, shared media, etc - pick your poison of the day) and I create a truncated version of that packet to send on the line. I don't even need to truncate every single one yet, since you haven't re-added the a probing mechanism like found in PLPMTUD to allow the MTU to be raised again yet :).

Putting all of the talk about the length authentication aside, I still don't see how the truncated headers was supposed to be an improvement over the ICMP approach of just sending the headers back as part of the payload. The ICMP destination unreachable message signaling the packet was too large already includes the original IP header + at minimum the first 8 bytes (though in practice RFC1812 increased that so you'll get significantly more) of data precisely so the client is able to map the request to the specific underlying session. If having the 5 tuple + identification number + TCP sequence number you sent match up with what you sent isn't already enough to trust it came from someone who got a copy of your message then you can add the HMAC anywhere in your headers without needing to replace the ICMP based signaling approach completely to get it sent back to you too? I guess because you want the message the message sent was too large to go to the remote side first instead of the sender?

Re: The Size of Packets

#70

Post by zamadatix »

ay wrote: post #64
zamadatix wrote: post #61

Earlier quoted context omitted.

Agreed, still not perfect by any means. One minor Ethernet MTU thing I would change with a time machine is to have the network header portion of the MTU be more like 802.11. I.e. instead of sized exactly to the headers of the day it intentionally was larger to allow variation over time. It wouldn't really do anything for most of the MTU concerns discussed here or for clients but I think it would have been helpful for…

> more like 802.11 L2 is “relatively simple” in a sense that it’s usually under the same administrative control; unlike with L3. And even then, if you have a look at all the complexity between the maintaining the interop in the wireless space… it’s amazing it works as well as it does, with so much functionality being conditional. > "nats are good" video isn't ringing any bells https://youtu.be/v26BAlfWBm8?feature=sha…

"Go buy some weed and smoke it" LOL
Post reply on HN