Paul-san, and folks, Now we (including me) have known the dangers and limitations, so should we set max-udp-size to 1220 on every authoritative servers?
-- Orange From: Paul Vixie <p...@redbarn.org> Date: Mon, 09 Sep 2013 04:47:44 -0700 > regrettably, the author of RFC 2671 knew the dangers and limitations of > fragmented IP, but specified it anyway. > > see especially: http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.html > > (where the authors of WRL-87-3 were two early mentors of the later > author of RFC 2671, who not only ought to have, but did, know better.) > > vixie > > re: > > Haya Shulman wrote: > > Yasuhiro-san :-) > > > > Nice find, thanks for sharing!! > > I will add reference to it in our works. > > > > On Sun, Sep 8, 2013 at 3:00 PM, > > <dns-operations-requ...@lists.dns-oarc.net > > <mailto:dns-operations-requ...@lists.dns-oarc.net>> wrote: > > > > > > > > Message: 6 > > Date: Sun, 08 Sep 2013 <tel:2013> 17:30:57 +0900 (JST) > > From: Yasuhiro Orange Morishita / ???? <yasuh...@jprs.co.jp > > <mailto:yasuh...@jprs.co.jp>> > > To: aa...@arbor.net <mailto:aa...@arbor.net> > > Cc: dns-operati...@mail.dns-oarc.net > > <mailto:dns-operati...@mail.dns-oarc.net>, edmo...@mycre.ws > > <mailto:edmo...@mycre.ws> > > Subject: Re: [dns-operations] DNS Attack over UDP fragmentation > > Message-ID: <20130908.173057.37558842.yasuh...@jprs.co.jp > > <mailto:20130908.173057.37558842.yasuh...@jprs.co.jp>> > > Content-Type: Text/Plain; charset=utf-8 > > > > Aaron-san, Haya-san, and folks, > > > > I've found the following RFC, it's published in 2007 <tel:2007>. > > > > RFC 4963 <tel:4963> - IPv4 Reassembly Errors at High Data Rates > > <http://tools.ietf.org/html/rfc4963> > > > > And I've cited "Security Considerations" of this RFC as below: > > > > BTW, When the RFC was I-D, it's titled "IPv4 Fragmentation Considered > > Very Harmful". > > > > <http://tools.ietf.org/html/draft-heffner-frag-harmful-03> > > > > So, we should have been discussing this issue before DNSSEC > > deployment. > > > > -- Orange > > > > --- > > 7. Security Considerations > > > > If a malicious entity knows that a pair of hosts are communicating > > using a fragmented stream, it may be presented with an > > opportunity to > > corrupt the flow. By sending "high" fragments (those with offset > > greater than zero) with a forged source address, the attacker can > > deliberately cause corruption as described above. Exploiting this > > vulnerability requires only knowledge of the source and destination > > addresses of the flow, its protocol number, and fragment > > boundaries. > > It does not require knowledge of port or sequence numbers. > > > > If the attacker has visibility of packets on the path, the attack > > profile is similar to injecting full segments. Using this attack > > makes blind disruptions easier and might possibly be used to cause > > degradation of service. We believe only streams using IPv4 > > fragmentation are likely vulnerable. Because of the nature of the > > problems outlined in this document, the use of IPv4 > > fragmentation for > > critical applications may not be advisable, regardless of security > > concerns. > > --- > > > > > > From: Aaron Campbell <aa...@arbor.net <mailto:aa...@arbor.net>> > > Date: Sat, 7 Sep 2013 <tel:2013> 08:27:47 -0300 > > > > > On 2013-09-06, at 1:42 PM, Robert Edmonds <edmo...@mycre.ws > > <mailto:edmo...@mycre.ws>> wrote: > > > > > > > Aaron Campbell wrote: > > > >> Here is a thought, but I will defer to the protocol experts > > on plausibility. The resolver knows the size of each DNS message > > it parses. What if it didn't trust glue records contained within > > large (i.e., > 1400 bytes or so) responses? In these cases, the > > resolver sends a separate query to resolve the dangling authority > > NS records. This introduces overhead, but only for large replies. > > It also makes a few assumptions, namely that the fragmentation > > point is something around 1500 bytes (and not something lower), > > and that the attack is only practical against the glue records, > > not the authority section. May be able to play games with name > > compression there though? perhaps it is as least worth discussing > > as an additional barrier. > > > > > > > > this sounds vaguely similar to unbound's > > "harden-referral-path" option, > > > > though it applies to all lookups. > > > > > > > > > I researched this, and found that it was first described here: > > > > > > > > > > http://tools.ietf.org/html/draft-wijngaards-dnsext-resolver-side-mitigation-01#section-3.3 > > > > > > The option is currently marked "experimental" due to not being > > RFC standard, and performance concerns. If the option were > > applied only to large responses (specifically to mitigate this > > type of attack), that would reduce the performance impact. > > > > > > -Aaron > > > _______________________________________________ > > > dns-operations mailing list > > > dns-operations@lists.dns-oarc.net > > <mailto: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 > > > > > > > ------------------------------ > > > > _______________________________________________ > > dns-operations mailing list > > dns-operations@lists.dns-oarc.net > > <mailto:dns-operations@lists.dns-oarc.net> > > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > > > > > > End of dns-operations Digest, Vol 92, Issue 13 > > ********************************************** > > > > > > > > > > -- > > Best Regards, > > S.H. > > _______________________________________________ > > 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 _______________________________________________ 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
