v6 DNSSEC fail, was Buying IPv4 blocks

Fri Oct 5 06:22:48 UTC 2018

On 10/5/18 1:53 AM, Mark Andrews wrote:
> If you don’t want fragmented IPv6 UDP responses use
> 
> 	server ::/0 { edns-udp-size 1232; };
> 
> That’s 1280 - IPv6 header - UDP header.  Anything bigger than that can theoretically
> be fragmented.  You will then have to deal with PMTUD failures as the servers switch
> over to TCP.

Speaking of, anyone have any good reports similar to that which was the 
genesis of this discussion but regarding PMTUD broken-ness on IPv6? 
Perhaps specifically focusing on its impact w.r.t DNS over TCP?

My understanding is that this is quite common on IPv4 but not as evident 
due to in-transit transparent fragmentation.

> 
> What I find ridiculous is firewall vendor that claim to support adding stateful rules
> on demand but don’t add “from <src> to <dst> frag offset != 0” when they add “from <src> to <dst> proto xxx src-port <dst-port> dst-port <src-port>” or don’t do packet reassembly to
> work around the lack of passing fragments.  This is IP and fragments are part
> and parcel of IP whether it is IPv4 or IPv6.

I think the "justification" for not allowing fragments is that they can 
be crafted specifically to evade filter policies.

Now, I'd argue that, if you want to not be a broken device, you then 
need to do reassembly so that you can inspect.  At minimum, do so for 
the typical attack case which uses very small fragments and/or large L3 
headers to split up application data since the result is presumably 
something that fits within the MTU of your LAN.  Or statefully track 
whether fragments are expected for a conversation.  Or drop fragments 
that could be used to evade policies but permit fragments that couldn't. 
  Or...something other than breaking things horribly and whining that 
the protocol is broken.

Of course, a lot of these are also the same boxes that, through design 
or misconfiguration, break PMTUD, too, I suspect.
-- 
Brandon Martin