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 <aa...@arbor.net> Date: Sat, 7 Sep 2013 08:27:47 -0300 > On 2013-09-06, at 1:42 PM, Robert Edmonds <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 > 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
