On Tuesday, 14 April 2020 17:32:54 UTC Paul Wouters wrote: > On Tue, 14 Apr 2020, Tim Wicinski wrote: > > This starts a Call for Adoption for > > draft-fujiwara-dnsop-avoid-fragmentation > > > > ... > > > > We are looking for *explicit* support for adoption. > > I am in favour of adoption. > > > Please also indicate if you are willing to contribute text, review, etc. > > I am willing to contribute text and review.
ty! > What I find missing is some text to explain that this is only a problem > for legacy DNS not using DNSSEC[*] and perhaps even mention that when > resolvers are setting the +DO flag, then fragmentation should still be > avoided, but that this is no longer a security issue. > > I think it is important to point out (again) that this issue would have > been a non-issue if people deploy DNSSEC. If we don't keep hammering > that down, people keep being misguided into believing DNSSEC is > optional and a matter of personal taste. that view, while agreeable, is also very narrow. the draft references three sources related to cache poisoning and dnssec: > [Fujiwara2018] > Fujiwara, K., "Measures against cache poisoning attacks > using IP fragmentation in DNS", OARC 30 Workshop , 2019. > > [Herzberg2013] > Herzberg, A. and H. Shulman, "Fragmentation Considered > Poisonous", IEEE Conference on Communications and Network > Security , 2013. > > [Hlavacek2013] > Hlavacek, T., "IP fragmentation attack on DNS", RIPE 67 > Meeting , 2013, <https://ripe67.ripe.net/ > presentations/240-ipfragattack.pdf>. however, the motivation for this draft is inclusive but not exclusive of those sources. see for example: > [I-D.ietf-intarea-frag-fragile] > Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., > and F. Gont, "IP Fragmentation Considered Fragile", draft- > ietf-intarea-frag-fragile-17 (work in progress), September > 2019. and also: Fragmentation Considered Harmful, Kent, C., Mogul, J., December 1978 https://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf --- what's at issue for fragments and fragmentation is that inter packet gap introduced for rate limiting so as to avoid congestion in a UDP-spewing service like NFS or DNS, there is no way to avoid microbursts which occur below the kernel. thus a steady-state equilibrium maintained with usleep() can be fatally upset when fragmentation occurs. this would be true even if PMTUD6 had actually worked. we have to never fragment. this draft specifies IP_DONTFRAG and IP6_DONTFRAG for that reason. and it's because of that recommendation, it becomes vital that we not copy/paste magic numbers like "1232" but rather make a considered decision as to what the response size ought to be, assuming that the PMTU is either 1500, or something smaller represented by the interface's MTU. -- Paul _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
