<div dir="ltr"><div class="gmail_default" style="font-family:garamond,serif">Hello Aaron,</div><div class="gmail_default" style="font-family:garamond,serif"><br></div><div class="gmail_default" style="font-family:garamond,serif">
Please see below.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 6, <a href="tel:2013" value="+9722013" target="_blank">2013</a> at 7:33 AM, Aaron Campbell <span dir="ltr"><<a href="mailto:aaron@arbor.net" target="_blank">aaron@arbor.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 2013-09-05, at 10:02 PM, Haya Shulman <<a href="mailto:haya.shulman@gmail.com" target="_blank">haya.shulman@gmail.com</a>> wrote:<br>
<br>
> I would recommend short term patched (that we recommend in the paper) in the meanwhile, and addressing the deployment challenges of DNSSEC.<br>
<br>
</div>Some comments on these recommendations. Based on the caveats documented by Google, I'm not sure the random prefix defenses would be recommended for general deployment, see link:<br></blockquote><div><br></div>
<div class="gmail_default" style="font-family:garamond,serif">You are right, these are certainly obstacles to deployment of such a countermeasure. We also mentioned in that paper, that there is no perfect solution, that would prevent all the attacks, but adoption of additional randomisation (in second fragment) along with reduction of IP defragmentation buffer, would make the attacks by off-path adversaries very difficult to launch.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<a href="https://developers.google.com/speed/public-dns/docs/security#add_entropy" target="_blank">https://developers.google.com/speed/public-dns/docs/security#add_entropy</a><br>
<br>
i.e., blacklist management. I also speculate that this will become even weirder with the new gTLD rollout.<br>
<br>
The random suffix defense makes sense, except then the attacker just has to repeat the attack for different checksums. Based on your research, only 1% of resolvers actually randomize the IP-ID, so it provides marginal entropy at best (side note, OpenBSD has been randomizing IP-ID for eons, I think even since the 90's-- <a href="http://www.openbsd.org/crypto.html#prng" target="_blank">http://www.openbsd.org/crypto.html#prng</a>).<br>
</blockquote><div><br></div><div class="gmail_default" style="font-family:garamond,serif">We studied the IPID randomisation on the name servers (not the resolvers). Only the name server side IPID randomisation is relevant to the attack, since it is the response from the name server that the attacker attempts to alter (by crafting a spoofed second fragment). IPID randomisation on the server, along with a smaller defragmentation buffer on the resolver, should suffice to make the attack impractical. The random suffix further raises the bar for the attacker.</div>
<div class="gmail_default" style="font-family:garamond,serif"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Unmentioned variation: random-length suffix? Instead of just randomizing the fictitious IP address, tack a random string on the front of the fictitious domain name. The advantage is that, in addition to the checksum, you add IP and UDP length to the entropy (although these adjust in tandem, unfortunately).<br>
</blockquote><div><br></div><div class="gmail_default" style="font-family:garamond,serif">Do you mean to add a random `name` and not only `value` in the fictitious resource record? I think that this seems like a good idea. Thanks!</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I would like to know if there is any merit to my earlier suggestion to Florian, namely, ignore glue records in large DNS responses, and have the recursors resolve dangling authority referrals using a separate (shorter) query. The second request is a simple A or AAAA query for the first[*] nameserver listed in the original response. The reply should contain the same authority and glue from the original response, but the data is more credible since the parameters of this query were not chosen by an untrusted stub. The assumption is that this second response would not also be fragmented, although I suppose the recursor could drop the EDNS0 option to force TC=1 just in case (even though that would result in a 3rd transaction, ugh).<br>
<br></blockquote><div class="gmail_default" style="font-family:garamond,serif">Fragmentation can also occur in the `authority` section, e.g., similarly to our attack exploiting referral response from a parent domain. So, I am not sure how this can work, I think that this requires evaluation to confirm.</div>
<div class="gmail_default" style="font-family:garamond,serif"><br></div><div class="gmail_default" style="font-family:garamond,serif">Thanks.</div><div class="gmail_default" style="font-family:garamond,serif"><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-Aaron<br>
<br>
[*] It is important to use the first namserver, since this is the one most likely to be contained in the first fragment (we have to consider that an attacker could corrupt the authority RRs, not just the additional glue RRs).</blockquote>
</div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div>Best Regards,<br></div>S.H.<br></div>
</div></div>