[dns-operations] DNS Attack over UDP fragmentation
Yasuhiro Orange Morishita / 森下泰宏
yasuhiro at jprs.co.jp
Sun Sep 8 08:30:57 UTC 2013
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
And I've cited "Security Considerations" of this RFC as below:
BTW, When the RFC was I-D, it's titled "IPv4 Fragmentation Considered
So, we should have been discussing this issue before DNSSEC deployment.
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
From: Aaron Campbell <aaron at arbor.net>
Date: Sat, 7 Sep 2013 08:27:47 -0300
> On 2013-09-06, at 1:42 PM, Robert Edmonds <edmonds at 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:
> 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.
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> dns-jobs mailing list
More information about the dns-operations