[dns-operations] rate-limiting state

[Vernon Schryver]

> From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= <colm at stdlib.net>


> Both can cause collateral damage, but to different targets. RRL does reduce
> the collateral damage to a reflection target. But it also increases the
> collateral damage to your legitimate users. If an attacker spoofs a popular
> resolver, then for just 5-10 queries per second they cause a degradation in
> service to the real legitimate users of that resolver. With the default
> settings, 12.5% of queries from that resolver may not get any answer at
> all, even with three attempts, and the lookup time is increased by about
> 1.3 RTTs on average.  With the resolver trying 3 authoritative nameservers,
> the availability hit diminishes to about 0.2% (which brings us to two
> nines), but the RTT hit gets worse.

Great!  Colm has finally read a little.  He still hasn't bothered
to understand.

> Now if I have a botnet or client that can generate 1M PPS (this is small,
> but adjust to any number), I can try to spoof 66,666 popular resolvers
> (this is a knowable set) at 5 QPS each to 3 auth servers, I can use RRL to
> degrade service in a more widespread way.

nonsense.

  - there are a lot more than 66K open resolvers, almost all of
     which should be closed, but there are not 66K popular resolvers
     in the sense that Google, OpenDNS, Comcast, &co are popular.

  - My (or someone else's) 12.5% number copied above assumes only
     a few retries.  Colm's latest doomsday scenario would cause
     more than only a few retries, which would drive that 12.5% way
     down.  The neat thing about the probabililty of failure in
     schemes like this is that it goes as (a/b)**r where a<b and r
     is the number of retries.

  - Colm still hasn't paid attention to that extra "R" in "RRR" and is
     still assuming that RRL is about simplistic IP source address
     rate limiting.  His botnet would need to forge not only IP source
     addresses but also the (qclass,qtype,qname) tuples of his victims.


> My overall point is that with RRL there is some trade-off between
> protecting innocent reflection victims and opening yourself to an attack
> that degrade service to your real users in some way. 

That is always true about any defense.  The resources including
bandwidth, CPU cycles, and human sweat devoted to RRL necessarily
reduce what can be spent for the service itself.  RRL has a remarkably
light footprint as such things go, but while Colm's specific
complaints are trolling nonsense, RRL's footprint is non-zero.  RRL
should not be used in networks that do not DNS reflection issues.


>                                                      Were RRL to be widely
> deployed, attacks could shift to table-exhaustion and popular-resolver
> spoofing and be effective in different ways.

RRL is long since widely deployed, the bad guys still haven't switched 
in that way.

That bit about "table exhaustion" is trolling based on the false
assumption that RRL is a naive firewall rate limit that uses a naive
firewall ACL (naive in this context but not necessarily other
firewall contexts).

There is an serious, ultimately fatal problem with RRL that has been
discussed repeatedly here and elsewhere, but it's unrelated to Colm's
"collateral damage".


Vernon Schryver    vjs at rhyolite.com