On 10/5/18 1:53 AM, Mark Andrews wrote:
If you don’t want fragmented IPv6 UDP responses useserver ::/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
