Dealing with IPv6 fragmentation in the DNS • Hacker News Board

Re: Dealing with IPv6 fragmentation in the DNS

#31

Post by verri » Tue, Aug 22, 2017, 5:49 PM UTC

feld wrote: post #29

kevin_nisbet wrote: post #19

Earlier quoted context omitted.

I've actually had this conversation before, and it get's a bit tricky. I'd say it has a few main facets: - ICMP is dangerous, and needs to be blocked. This is partly true, as there is historically information leakage with ICMP under certain codes. So blocking all of it is easier than trying to figure out what should be allowed and what should not. - It's not perceived to be a problem. Most services just work, so TCP/…

> I'd say it has a few main facets: - ICMP is dangerous, and needs to be blocked. This is partly true, as there is historically information leakage with ICMP under certain codes. So blocking all of it is easier than trying to figure out what should be allowed and what should not. It's actually quite easy to identify which should be allowed and which should not. ICMP: 0,3,8,11 (echo reply, destination unreachable, ech…

But why filter ICMP at all? I can understand that ICMP allows for covert tunnelling, but by that logic any IP protocol number should be blocked.

Re: Dealing with IPv6 fragmentation in the DNS

#32

Post by teddyh » Tue, Aug 22, 2017, 5:57 PM UTC

stephengillie wrote: post #9

Having a variable header complicates Cut-Through switching[0], which forwards the entire frame just after the switch gets the destination field of the header. This sounds like it would force a return to Store-And-Forward[1], where the switch waits for the entire frame to load into memory, before forwarding to its next hop. Waiting these few milliseconds doesn't sound bad, until you consider that's added to each packe…

You seem to be confusing IP headers with Ethernet headers. Cut-through switching only looks at the Ethernet header, which is not variable, and thus will still be perfectly viable.

Re: Dealing with IPv6 fragmentation in the DNS

#33

Post by wmf » Tue, Aug 22, 2017, 5:58 PM UTC

tssva wrote: post #21

stephengillie wrote: post #9

Having a variable header complicates Cut-Through switching[0], which forwards the entire frame just after the switch gets the destination field of the header. This sounds like it would force a return to Store-And-Forward[1], where the switch waits for the entire frame to load into memory, before forwarding to its next hop. Waiting these few milliseconds doesn't sound bad, until you consider that's added to each packe…

Totally different layers. Switching occurs at layer 2 and isn't affected by whether the frame contains IPv4 or IPv6.

It would be nice if that was the case, but switches often look deeper for ECMP.

Re: Dealing with IPv6 fragmentation in the DNS

#34

Post by wmf » Tue, Aug 22, 2017, 6:03 PM UTC

stephengillie wrote: post #9

Having a variable header complicates Cut-Through switching[0], which forwards the entire frame just after the switch gets the destination field of the header. This sounds like it would force a return to Store-And-Forward[1], where the switch waits for the entire frame to load into memory, before forwarding to its next hop. Waiting these few milliseconds doesn't sound bad, until you consider that's added to each packe…

The way cut-through is really implemented is that the first N bytes of the packet (usually 128 or 256) are treated as the "header" and are passed through the header pipeline regardless of how big the actual header is. So variable headers like VLAN tags, MPLS stacks, or IP extension headers shouldn't prevent cut-through.

Also, the difference between cut-through and store-and-forward is generally in single-digit microseconds, not milliseconds. A good rule of thumb is ~1 us/KB at 10G.

Re: Dealing with IPv6 fragmentation in the DNS

#35

Post by verri » Tue, Aug 22, 2017, 6:09 PM UTC

squeed wrote: post #16

stephengillie wrote: post #9

Having a variable header complicates Cut-Through switching[0], which forwards the entire frame just after the switch gets the destination field of the header. This sounds like it would force a return to Store-And-Forward[1], where the switch waits for the entire frame to load into memory, before forwarding to its next hop. Waiting these few milliseconds doesn't sound bad, until you consider that's added to each packe…

The real problem is that you can no longer look at a fixed offset for your parameters, which complicates filtering silicon. In other words, if you want to have a firewall rule of "drop tcp 135", in ipv4 you can just look at bytes 0x24-25 (for Ethernet). IPv6's extension-header mechanism means that the header has a non-fixed length, so you need to do work for the same effect. Given that firewalls are critical in a wor…

But IPv4 headers could have a variable length too, it's just that we don't encounter that much in the wild. And what about the AH header, GRE and IPIP tunnel headers, 6rd/6in4 tunnel headers, etc. Filtering at fixed offsets sounds very brittle to me. Isn't the real problem here that network providers and administrators appropriate the right to filter on OSI layers they shouldn't be touching? This problem sounds like the exact reason why Google insisted on having its QUIC headers ciphered: so network equipment can't pull of this kind of misbehaviour.

Re: Dealing with IPv6 fragmentation in the DNS

#36

Post by noselasd » Tue, Aug 22, 2017, 7:27 PM UTC

verri wrote: post #35

squeed wrote: post #16

Earlier quoted context omitted.

The real problem is that you can no longer look at a fixed offset for your parameters, which complicates filtering silicon. In other words, if you want to have a firewall rule of "drop tcp 135", in ipv4 you can just look at bytes 0x24-25 (for Ethernet). IPv6's extension-header mechanism means that the header has a non-fixed length, so you need to do work for the same effect. Given that firewalls are critical in a wor…

But IPv4 headers could have a variable length too, it's just that we don't encounter that much in the wild. And what about the AH header, GRE and IPIP tunnel headers, 6rd/6in4 tunnel headers, etc. Filtering at fixed offsets sounds very brittle to me. Isn't the real problem here that network providers and administrators appropriate the right to filter on OSI layers they shouldn't be touching? This problem sounds like…

At least with IPv4 you can easily compute the start of layer 4, it's just ipv4[0]&0xf * 4 - trivially implemented with little real-estate in hardware.

IPv6 requires you to loop through all extension headers to reach layer 4, and you need to know about a handful of those extension headers as not all follow the same format.

Re: Dealing with IPv6 fragmentation in the DNS

#37

Post by kevin_nisbet » Tue, Aug 22, 2017, 9:34 PM UTC

feld wrote: post #29

kevin_nisbet wrote: post #19

Earlier quoted context omitted.

I've actually had this conversation before, and it get's a bit tricky. I'd say it has a few main facets: - ICMP is dangerous, and needs to be blocked. This is partly true, as there is historically information leakage with ICMP under certain codes. So blocking all of it is easier than trying to figure out what should be allowed and what should not. - It's not perceived to be a problem. Most services just work, so TCP/…

> I'd say it has a few main facets: - ICMP is dangerous, and needs to be blocked. This is partly true, as there is historically information leakage with ICMP under certain codes. So blocking all of it is easier than trying to figure out what should be allowed and what should not. It's actually quite easy to identify which should be allowed and which should not. ICMP: 0,3,8,11 (echo reply, destination unreachable, ech…

Agreed.

It's just the argument that gets made for filtering, is we'd rather just filter it all instead of trying to understand what should and should not be filtered.

Re: Dealing with IPv6 fragmentation in the DNS

#38

Post by myrandomcomment » Wed, Aug 23, 2017, 12:10 AM UTC

wmf wrote: post #34

stephengillie wrote: post #9

Having a variable header complicates Cut-Through switching[0], which forwards the entire frame just after the switch gets the destination field of the header. This sounds like it would force a return to Store-And-Forward[1], where the switch waits for the entire frame to load into memory, before forwarding to its next hop. Waiting these few milliseconds doesn't sound bad, until you consider that's added to each packe…

The way cut-through is really implemented is that the first N bytes of the packet (usually 128 or 256) are treated as the "header" and are passed through the header pipeline regardless of how big the actual header is. So variable headers like VLAN tags, MPLS stacks, or IP extension headers shouldn't prevent cut-through. Also, the difference between cut-through and store-and-forward is generally in single-digit micros…

So there was a huge argument of CT vs SF switching way back when. IIRC there was Kalpana (CT) which Cisco acquired and Granite (Cat4K, SF) and Crescendo (Cat5/6K, SF). Cisco killed cut-through. The 1st real ASIC that did cut-through since then was the FM4000 (Fulcum) which was used in the Arista 7124, BNT, etc. The FM4000 latency was 600ns vs. 6 microseconds for the standard Wall Street switch at the time (Cat4900). 600ns to 6 microseconds is huge.

The FM4000 looked at 64 bytes before forwarding (IIRC). The 1st Broadcom chips that did cut-through were the Trident line. They looked at something like ~200 or ~500 bytes before making a forwarding decision (sorry exact number is not in cache anymore). They cut that down with the T+ chips.

The funny issue about cut-through is that it will forward a corrupted packet. Trying to pinpoint the source can be fun.

With static webpages, etc, old school internet the latency was not a big deal. The improvements in switching with cut-through and low latency were a game changer for storage, video, etc.

Re: Dealing with IPv6 fragmentation in the DNS

#39

Post by mgsouth » Wed, Aug 23, 2017, 1:11 AM UTC

verri wrote: post #31

feld wrote: post #29

Earlier quoted context omitted.

> I'd say it has a few main facets: - ICMP is dangerous, and needs to be blocked. This is partly true, as there is historically information leakage with ICMP under certain codes. So blocking all of it is easier than trying to figure out what should be allowed and what should not. It's actually quite easy to identify which should be allowed and which should not. ICMP: 0,3,8,11 (echo reply, destination unreachable, ech…

But why filter ICMP at all? I can understand that ICMP allows for covert tunnelling, but by that logic any IP protocol number should be blocked.

I think it's more the incoming ICMP that is troublesome, particularly redirect, and to a lesser extent destination unreachable (DOS).

Re: Dealing with IPv6 fragmentation in the DNS

#40

Post by Avernar » Wed, Aug 23, 2017, 1:46 AM UTC

rocqua wrote: post #26

the8472 wrote: post #8

> IPv6 Extension Headers require any transport protocol-sensitive functions in network switches to unravel the packet header’s extension header chain. This takes a variable number of cycles for the device and furthermore requires that the switch should recognise all the extension headers encountered on the header chain. This is anathema to a switch, in so far as it entails a variable amount of time to process. If it…

I agree that switches shouldn't care about TCP or UDP ports. That is a job for a firewall. However, that does not mean it is a good idea to have variable length headers in IPv6. In fact it seems like a singularly bad idea to me. Regarding firewalls, I imagine it still sucks a firewall cannot judge each IP-packet separately but needs to deal with possible fragmented packets. Then again, that is the cost of being a fir…

I don't see an issue with extension headers in IPv6. The RFCs have rules on who should look at what header and what to do when an unrecognized one is encountered.

Most firewalls I've dealt with have some option to defragment the inbound packet at the firewall so that the rest of the rules can be processed properly and to protect nodes from malicious fragments.