[dns-operations] rate-limiting state

[Vernon Schryver]

> From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= <colm at stdlib.net>
> To: Paul Vixie <paul at redbarn.org>
> Cc: DNS Operations List <dns-operations at lists.dns-oarc.net>

> > For example, if the authoritative provider www.example.com were to
> > implement RRL as you describe, then an attacker could spoof traffic
> > purporting to be from Google Public DNS, OpenDNS, Comcast ... etc, and
> > cause www.example.com to be un-resolvable by users of those resolvers.
> >
> > no. it just does not work that way.
>
> O.k., so say I spoof 10M UDP queries per second and 10M TCP SYNs per second
> purporting to be from OpenDNS's IP address. Does RRL  a)  Let the queries
> and SYNs go answered. Or b) Rate limit the responses?
>
> If it's (a) RRL doesn't prevent the reflection. If it's (b) then you
> complete a denial of service attack against the OpenDNS users.
>
> Which is it? or what's option (c)?

I think one option (c) (there might be others) is related to what
Paul Vixie meant when he wrote:

]  The more common case will be like DNS RRL, where deep knowledge
]  of the protocol is necessary for a correctly engineered rate-limiting
]  solution applicable to the protocol

in http://queue.acm.org/detail.cfm?id=2578510

I've written too many times here and elsewhere that DNS RRL is not a
naive firewall rate limit.  Simplistic firewall rate limiting against
DNS reflections is little better than blocking all ICMP on "security"
grounds.  That is why DNS RRL is in the DNS code instead of firewalls.
That's also why there are two R's in RRL.

There are plenty of words in the documentation, technical reports, and
analyses of the various RRL implementations about RRL false positives.
There is disagreement about the best values for the parameters that
minimize RRL false positives, but we who have the least interest in
the topic agree that neither option (a) nor option (b) fit.


Vernon Schryver    vjs at rhyolite.com