[ratelimits] RRL vs other approaches

[Vernon Schryver]

> From: Roland Dobbins <rdobbins at arbor.net>

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

Many things that were once Good Enough are no longer Good Enough
today.  Other things that are still Good Enough as desert toppings
are not Good Enough as floor waxes.


> Those of who mitigate DDoS attacks on an ongoing basis tend not
>to sneer at methods which a) are deployable & b) aren't perfect.

The old methods should be sneered at when they can be replaced.
Some of us sing "Back to the drawing board" with glee instead of
doom, gloom, or implications that RRL is not deployable.  Sometimes
we spare a thought for users with old versions or sales people who
must flog old versions to pay the bills while we code the next
version.


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

Truncate-mode (presumably answering all DNS/UDP with TC=1) is
inferior to RRL for mitigating reflection attacks at both authoritative
and recursive servers.  You can see that fact by noticing that
during attacks, RRL answers DNS/UDP with TC=1 similar to but better
than truncate-mode.

Unless you set RRL thresholds too high (but below triggers for old
mechanisms) to mitigate small or slightly distributed reflection
attacks, RRL is generally not good for recursive servers.  That is
because some applications differ from reflection attckers as seen
at recursive servers only by not using spoofed source addresses.


> 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 are many things that BCP38 would fix, but we're talking about
mitigating DNS reflection attacks instead of those many other attacks.
RRL is not both a desert topping and a floor wax.  RRL is for mitigating
DNS reflection attacks and not cleaning pipes.


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

Anyone still toiling at the coal face with picks and shovels has
at best non-technical reasons for not switching to modern machinery,
including automation that removes people from the face and that was
not available 10 or 20 years ago.  In other words, it's silly to
suggest that RRL is only theoretical or has only theoretical benefits.


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

I'm happy to be wrong; maybe those implementations (including stubs)
will provoke others.  However, please say how DNS cookies can be a
DDoS mitigation system while essentially no DNS recursive or stub
resolvers understand them.  You could use cookies between a private
server and private DNS clients, both special by understanding cookies.
That would not be a DDoS mitigation system and to me it sounds inferior
to many other ways to restrict access to a server.

As I see it, the hardest part of DNS Cookies is teaching stub resolvers
to cache cookies.  Stashing cookes in libc resolver libraries would
be as bad as the other libc host name related caches.  One tactic
also solves the DNSSEC verification problem; it is to give every stub
a simple caching recursive resolver on localhost.  (The difference
between that and stashing stuff in libc can be seen as an implementation
detail, but that detail has significant implications.)


> >Besides, RRL deals with attackers that use ANY by "disallowing ANY

> I understand how it works, thanks. 

Then why propose truncate mode as a good, current alternative to RRL?


Vernon Schryver    vjs at rhyolite.com