<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 6, 2014 at 3:28 PM, Paul Vixie <span dir="ltr"><<a href="mailto:paul@redbarn.org" target="_blank">paul@redbarn.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-family:tt;font-size:11pt" bgcolor="#FFFFFF" text="#000000"><div style="font-size:11pt;font-family:tt">first, i think we need
 smaller numbers, since at those volumes, opendns's pipes are full, and 
nobody would get any answers to any questions. so let's pick some number
 of requests and SYNs per second that is enough to use all the head room
 opendns had, but without affecting response flows to queries not 
related to your attack.<br></div></div></blockquote><div><br></div><div>I chose a fairly typical number, which is actually below average. Arbor's data on DDOS puts 10M somewhere between the 40th and 50th percentile.  I'd be really surprised if OpenDNS's pipes fill up with that kind of small volume. </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-family:tt;font-size:11pt" bgcolor="#FFFFFF" text="#000000"><div style="font-size:11pt;font-family:tt">
second, RRL does not see SYNs. the kernel
 probably has SYN flood protection, which like a stateful firewall might
 penalize a host or netblock's real SYNs, but that has nothing to do 
with RRL's logic.</div></div></blockquote><div><br></div><div>So the reflection attack is completed? If you're going to respond to all of the SYNs, you may as well respond to the UDP queries. It'll be the same reflected PPS. The byte count will be a little higher, but most networks are bottlenecked on PPS at DNS payload sizes. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-family:tt;font-size:11pt" bgcolor="#FFFFFF" text="#000000"><div style="font-size:11pt;font-family:tt">
so, third, let's 
look squarely at "large enough UDP flow to activate RRL". </div></div></blockquote><div><br></div><div>10M requests/sec for <a href="http://www.example.com">www.example.com</a>, type=A. Would that be large enough?<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="font-family:tt;font-size:11pt" bgcolor="#FFFFFF" text="#000000"><div style="font-size:11pt;font-family:tt">
in that steady state situation, opendns's 
legitimate queries whose response matches an RRL flow are mixed with an 
avalanche of forged questions soliciting the same answer. opendns will 
retry three times over ten to 90 seconds. if opendns ever gets an 
answer, it will fill its cache and stop asking that question. the 
possibility of opendns receiving a TC=1 and retrying with TCP, or 
receiving one of our periodic normal answers, and either way filling its
 cache is high, on the order of unity. of course, opendns might ask 
other authorities in between retries to any one authority, so you'll 
need to spoof all of the potential authorities who could help with the 
terminal cache-fill operation that ends the race.<br></div></div></blockquote><div><br></div><div>I agree with all of this, but I don't think that the numbers work out. If you're getting an attack of 10M PPS, which is very realistic, you'll end up denying service to real users. </div>
<div><br></div><div>Important to consider here, is that if you did nothing, and let the responses go answered (if you can), there's no impact on the real users. The reflection target does get hit of course though.  So in effect, at realistic DDOS scales, RRL can be used to deny service to your real users to protect victims of reflection attacks. That's a form of asymmetric altruism. I'm not against it, doing the internet a favour is worthwhile, we all benefit ; but it's worth calling out. </div>
<div> </div></div>-- <br>Colm
</div></div>