<div dir="ltr"><div class="gmail_default" style="font-family:garamond,serif"><span class="" style="font-family:arial,sans-serif;font-size:12.727272033691406px">Yasuhiro-san :-)</span><br></div><div class="gmail_default" style="font-family:garamond,serif">
<span class="" style="font-family:arial,sans-serif;font-size:12.727272033691406px"><br></span></div><div class="gmail_default" style="font-family:garamond,serif"><span class="" style="font-family:arial,sans-serif;font-size:12.727272033691406px">Nice find, thanks for sharing!!</span></div>
<div class="gmail_default" style="font-family:garamond,serif"><span class="" style="font-family:arial,sans-serif;font-size:12.727272033691406px">I will add reference to it in our works.</span></div><div class="gmail_extra">
<br><div class="gmail_quote">On Sun, Sep 8, 2013 at 3:00 PM, <span dir="ltr"><<a href="mailto:dns-operations-request@lists.dns-oarc.net" target="_blank">dns-operations-request@lists.dns-oarc.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Message: 6<br>
Date: Sun, 08 Sep <a href="tel:2013" value="+9722013">2013</a> 17:30:57 +0900 (JST)<br>
From: Yasuhiro Orange Morishita / ???? <<a href="mailto:yasuhiro@jprs.co.jp"><div class="gmail_default" style="font-family:garamond,serif;display:inline"></div>yasuhiro@jprs.co.jp</a>><br>
To: <a href="mailto:aaron@arbor.net">aaron@arbor.net</a><br>
Cc: <a href="mailto:dns-operations@mail.dns-oarc.net">dns-operations@mail.dns-oarc.net</a>, <a href="mailto:edmonds@mycre.ws">edmonds@mycre.ws</a><br>
Subject: Re: [dns-operations] DNS Attack over UDP fragmentation<br>
Message-ID: <<a href="mailto:20130908.173057.37558842.yasuhiro@jprs.co.jp">20130908.173057.37558842.yasuhiro@jprs.co.jp</a>><br>
Content-Type: Text/Plain; charset=utf-8<br>
<br>
Aaron-san, Haya-san, and folks,<br>
<br>
I've found the following RFC, it's published in <a href="tel:2007" value="+9722007">2007</a>.<br>
<br>
RFC <a href="tel:4963" value="+9724963">4963</a> - IPv4 Reassembly Errors at High Data Rates<br>
<<a href="http://tools.ietf.org/html/rfc4963" target="_blank">http://tools.ietf.org/html/rfc4963</a>><br>
<br>
And I've cited "Security Considerations" of this RFC as below:<br>
<br>
BTW, When the RFC was I-D, it's titled "IPv4 Fragmentation Considered<br>
Very Harmful".<br>
<br>
<<a href="http://tools.ietf.org/html/draft-heffner-frag-harmful-03" target="_blank">http://tools.ietf.org/html/draft-heffner-frag-harmful-03</a>><br>
<br>
So, we should have been discussing this issue before DNSSEC deployment.<br>
<br>
-- Orange<br>
<br>
---<br>
7. Security Considerations<br>
<br>
If a malicious entity knows that a pair of hosts are communicating<br>
using a fragmented stream, it may be presented with an opportunity to<br>
corrupt the flow. By sending "high" fragments (those with offset<br>
greater than zero) with a forged source address, the attacker can<br>
deliberately cause corruption as described above. Exploiting this<br>
vulnerability requires only knowledge of the source and destination<br>
addresses of the flow, its protocol number, and fragment boundaries.<br>
It does not require knowledge of port or sequence numbers.<br>
<br>
If the attacker has visibility of packets on the path, the attack<br>
profile is similar to injecting full segments. Using this attack<br>
makes blind disruptions easier and might possibly be used to cause<br>
degradation of service. We believe only streams using IPv4<br>
fragmentation are likely vulnerable. Because of the nature of the<br>
problems outlined in this document, the use of IPv4 fragmentation for<br>
critical applications may not be advisable, regardless of security<br>
concerns.<br>
---<br>
<br>
<br>
From: Aaron Campbell <<a href="mailto:aaron@arbor.net">aaron@arbor.net</a>><br>
Date: Sat, 7 Sep <a href="tel:2013" value="+9722013">2013</a> 08:27:47 -0300<br>
<br>
> On 2013-09-06, at 1:42 PM, Robert Edmonds <<a href="mailto:edmonds@mycre.ws">edmonds@mycre.ws</a>> wrote:<br>
><br>
> > Aaron Campbell wrote:<br>
> >> 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.<br>
> ><br>
> > this sounds vaguely similar to unbound's "harden-referral-path" option,<br>
> > though it applies to all lookups.<br>
><br>
><br>
> I researched this, and found that it was first described here:<br>
><br>
> <a href="http://tools.ietf.org/html/draft-wijngaards-dnsext-resolver-side-mitigation-01#section-3.3" target="_blank">http://tools.ietf.org/html/draft-wijngaards-dnsext-resolver-side-mitigation-01#section-3.3</a><br>
><br>
> 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.<br>
><br>
> -Aaron<br>
> _______________________________________________<br>
> dns-operations mailing list<br>
> <a href="mailto:dns-operations@lists.dns-oarc.net">dns-operations@lists.dns-oarc.net</a><br>
> <a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
> dns-jobs mailing list<br>
> <a href="https://lists.dns-oarc.net/mailman/listinfo/dns-jobs" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-jobs</a><br>
><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
dns-operations mailing list<br>
<a href="mailto:dns-operations@lists.dns-oarc.net">dns-operations@lists.dns-oarc.net</a><br>
<a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations</a><br>
<br>
<br>
End of dns-operations Digest, Vol 92, Issue 13<br>
**********************************************<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div>Best Regards,<br></div>S.H.<br></div>
</div></div>