<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 6, 2014 at 4:46 PM, Paul Vixie <span dir="ltr"><<a href="mailto:paul@redbarn.org" target="_blank">paul@redbarn.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

Damian Menscher wrote:<br>
> ...<br>
<div class="im">> My recommendation (which Vixie and Vernon disagree with) is to use RRL<br>
> with slip=1 -- return TC=1 responses to all queries over the limit.<br>
<br>
</div>my disagreement is explained in detail here:<br>
<a href="http://www.circleid.com/posts/20130913_on_the_time_value_of_security_features_in_dns/" target="_blank">http://www.circleid.com/posts/20130913_on_the_time_value_of_security_features_in_dns/</a></blockquote><div><br>

</div><div>Since I haven't explained my objections before, I'll pick apart your arguments:</div><div><br></div><div>1) "RRL must be attenuative in packets per second, not just in bits per second".  The attacker is using DNS amplification specifically to increase bits/second.  If they wanted to amplify packets/second they could just spoof syn packets to webservers.  Returning to a 1:1 ratio should be our goal, and slip=1 achieves that.</div>

<div><br></div><div>2) "A pure TCP fallback strategy would be less reliable due to the fragility of TCP/DNS".  You go on to argue that the 3-way handshake adds latency and server load, which I agree with.  But keep in mind only the legitimate queries will need to use TCP, so the actual load is low.  And these are queries which would otherwise have had to retry over UDP after a timeout (and even then only have a 50% success rate), so the amortized latency hit isn't particularly significant either.</div>

<div><br></div><div>3) [Addressing the increased poisoning risk], "requires many hours of uninterrupted 100 Mbit/sec blasting from the attacker to the victim in order to have a chance at success".  I don't worry about 100Mbps attacks, but in the age of 10Gbps (unamplified) attacks, I think this does introduce a non-negligible (and unnecessary!) risk for high-value domains.  Keep in mind a single poison packet can inject a high TTL to cause a long outage, and potentially use that time to steal unencrypted data (SMTP, for example).  Why take that risk just to reduce the amplification factor *below* 1:1?</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
> This ensures your legitimate users can get through with a TCP request,<br>
> rather than having to attempt multiple retries before learning to<br>
> retry over TCP.  Does slip=1 address your concerns?<br>
><br>
> Of course TCP isn't perfect -- it has higher latency and<br>
> per-connection costs -- but at least it ensures your legitimate users<br>
> can't be affected by the RRL.<br>
<br>
</div>it does not. see [ibid].<br></blockquote><div><br></div><div>Do you have additional arguments I missed?</div><div><br></div><div>Damian</div></div></div></div>