> On 5 Oct 2018, at 4:22 pm, Brandon Martin <lists.na...@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: ma...@isc.org

Reply via email to