Re: v6 DNSSEC fail, was Buying IPv4 blocks

[Mark Andrews <marka () isc org>]

> On 5 Oct 2018, at 4:22 pm, Brandon Martin <lists.nanog () monmotha net> wrote:
>
> 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.

So require frag 0 to have what you require to do the filtering. Most stacks send maximal sized initial fragments up to 
1280 bytes. For DNS the UDP header will be there as there is at least 8 bytes of fragmented packet.  Additionally 
reassembly attacks are much harder as there is 32 bits of fragmentation identifier rather than 16 in IPv4.

IPv6 fragmentation was designed with knowledge of the IPv4 reassembly attacks in mind.

> 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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka () isc org