[dns-operations] dns-operations Digest, Vol 92, Issue 13
haya.shulman at gmail.com
Mon Sep 9 11:30:49 UTC 2013
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-request at lists.dns-oarc.net>wrote:
> Message: 6
> Date: Sun, 08 Sep 2013 17:30:57 +0900 (JST)
> From: Yasuhiro Orange Morishita / ???? <
> yasuhiro at jprs.co.jp>
> To: aaron at arbor.net
> Cc: dns-operations at mail.dns-oarc.net, edmonds at mycre.ws
> Subject: Re: [dns-operations] DNS Attack over UDP fragmentation
> Message-ID: <20130908.173057.37558842.yasuhiro at 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.
> 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
> Very Harmful".
> 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
> 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.
> > -Aaron
> > _______________________________________________
> > dns-operations mailing list
> > dns-operations at 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 at lists.dns-oarc.net
> End of dns-operations Digest, Vol 92, Issue 13
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dns-operations