Haya-san, > Yasuhiro-san :-)
Please call me "Orange" frankly. It's my nickname. Just FYI and as you may know, Mark Andrews wrote the following I-D. It's published the next day of your presentation at IETF saag (and now updated to -01). draft-andrews-6man-fragopt-01 - IPv6 Stateless Fragmentation Identification Options <http://tools.ietf.org/html/draft-andrews-6man-fragopt-01> I think it is one of measures of the attack. It adds the identication on fragmented packet. So, perhaps, you can refer it. -- Orange From: Haya Shulman <[email protected]> Date: Mon, 9 Sep 2013 14:30:49 +0300 > 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, > <[email protected]>wrote: > > > > > > > Message: 6 > > Date: Sun, 08 Sep 2013 17:30:57 +0900 (JST) > > From: Yasuhiro Orange Morishita / ???? < > > [email protected]> > > To: [email protected] > > Cc: [email protected], [email protected] > > Subject: Re: [dns-operations] DNS Attack over UDP fragmentation > > Message-ID: <[email protected]> > > Content-Type: Text/Plain; charset=utf-8 > > > > Aaron-san, Haya-san, and folks, > > > > I've found the following RFC, it's published in 2007. > > > > RFC 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 <[email protected]> > > Date: Sat, 7 Sep 2013 08:27:47 -0300 > > > > > On 2013-09-06, at 1:42 PM, Robert Edmonds <[email protected]> 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 > > > [email protected] > > > 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 > > [email protected] > > 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 [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
