* Ondřej Surý: > I think it should be quite safe to cap the maximum EDNS0 to 1280 > (the minimum IPv6 MTU) and set DF flag in all responses.
Setting the DF flag on responses will be counterproductive because you must not perform path MTU discovery, either by disabling in the stack, or by filtering the ICMP packets. That part has been published as well, it seems. Anyway, that, plus lowering the MTU to 1200 or so, should do the trick. (I think 1280 is still a bit on the large side.) Exploiting this vulnerability successfully over the Internet against resolvers processing real-world traffic still seems difficult to me, at least if the resolver uses the Linux TCP/IP stack. This is not completely idle speculation because some of us tried to implement this attack several times over the past few years, putting in quite a bit of effort and failed. Compare this to the TTL evasion vulnerability, for which attacks were really easy to implement. (But keep in mind that other stacks have different beahviors and defaults, and could well be much more vulnerable.) On the other hand, if someone puts all the pieces together, and it turns out that there is a combination of tweaks, zone- and server-specific logic that actually works, changing server defaults in a security update to reduce the maximum EDNS buffer size to 1200 bytes by default, and modifying the server (and kernel) to ignore path MTU information when sending packets, is a workable response. Consequently, I haven't pushed for a more proactive approach to this vulnerability so far. Deploying IPv6 also happens to help, due to the increased fragment ID size. Like reflective denial-of-service attacks, this potential attack could be greatly mitigated by source IP address validation at the ISP level. _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
