[dns-operations] rate-limiting state

[Patrick W. Gilmore]

On Feb 06, 2014, at 18:59 , Colm MacCárthaigh <colm at stdlib.net> wrote:
> On Thu, Feb 6, 2014 at 3:28 PM, Paul Vixie <paul at redbarn.org> wrote:

>> 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.
> 
> 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. 

Paul was responding at RRL. Whether the OS on a name server responds to SYNs is outside RRL's scope.

Plus who is going to hit a name server with SYNs when pretty much every server on the Internet will ACK any SYN sent to it? Pick your favorite NN million servers and send them all 10 SYNs / sec, will fall under anyone's rate limiting and you're done.



>> so, third, let's look squarely at "large enough UDP flow to activate RRL".
> 
> 10M requests/sec for www.example.com, type=A. Would that be large enough?
> 
>> 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.
> 
> 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. 

You don't think the numbers work out? That's your response. Lots of people have RRL installed & have survived attacks with it. Have you any data other than "I don't think that the numbers work out" to show otherwise?


> 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. 

I think you'll find there is huge impact on the real users, since the target is down and the target is a real user. Plus all the people between the reflector and the target.

Until you can do better than "I don't think the numbers work out", I think I'll go with this being better than nothing despite your reservations.

-- 
TTFN,
patrick