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
