[ratelimits] RRL vs other approaches
rdobbins at arbor.net
Sun Feb 24 04:49:35 UTC 2013
Vernon Schryver <vjs at rhyolite.com> wrote:
>That you manage to "authenticate" some DNS requests from 10.2.3.4
>using TCP, TSIG, or any other scheme IMPLIES NOTHING about other
>UDP requests that claim to be from 10.2.3.4.
That's true - but, you know, I've been using this mechanism to defeat some pretty serious spoofed DDoS attacks for the last 11 years or so, and it works pretty well, in practice. More granularity is welcome, but in a majority of cases, it's been Good Enough.
Those of who mitigate DDoS attacks on an ongoing basis tend not to sneer at methods which a) are deployable & b) aren't perfect.
>It is not the attacker that would "a) authenticate via TCP", but
>the victim. After the victim authenticates itself, it would be
>wrong to trust the UDP/IP source address in the packets from the
The world is not composed solely of authoritative DNS servers. Open recursors are abused to make reflection/amplification attacks possible, as well as other types of attacks. Truncate-mode, while imperfect, actually works pretty well in these circumstances.
>During real attacks, reflectors using RRL and SLIP see the victim
>continually "a) authenticate via TCP" even as the bad guy continues
>to "b) zorch the servers in question by spoofing the authenticated
Again, you're looking at the problem from only one angle, and only for one kind of attack. There are lots of other attacks against the DNS besides reflection/amplification attacks, and quite a few of them employ spoofing.
>There is no way in the current DNS protocol to connect the
>"authenticating" done with a TCP handshake to UDP packets that
>happen to have the same IP source address.
Again, it's easy to preach perfection from a theoretical point of view, whilst those of us toiling at the coal-face get along with whatever we can lay our hands on at any given moment.
>DNS Cookies seems to be a good way to do that but there are no known >implementations
Actually, it has been implemented in at least one commercial DDoS mitigation system, & it does work pretty well for authoritative servers.
>That relies on the false assumption that ANY is a required or
>universal aspect of DNS reflection DoS attacks. In the real world
>of DNS reflection attacks, ANY is neither required nor always used.
I've worked plenty of DNS reflection/amplification attacks which don't use ANY, so I'm not assuming anything. I've also worked ANY attacks which weren't reflection/amplification attacks. So, whoever is making assumptions in this thread, it isn't me.
>****** MANY REAL RELFECTION ATTACKS DO NOT USE any *****
I know this, no need to shout the obvious.
>Besides, RRL deals with attackers that use ANY by "disallowing ANY
>queries during an attack" (provided each valid qname is repeated more
>than the threshold, which can be as low as 5 qps). The basic idea of
>RRL is to disallow not just ANY but whatever qtype is used (again
>provided the qname is above the threshold).
I understand how it works, thanks.
Roland Dobbins <rdobbins at arbor.net>
More information about the ratelimits