[dns-operations] RRL specified in a stable place?

[Andrew Sullivan]

Hi,

On Mon, Feb 04, 2013 at 09:02:14PM +0000, Vernon Schryver wrote:

> >                  Consider that, if you spoof $ISP's resolver addresses
> > and perform one of these attacks, then $ISP gets at least degraded
> > service during the rate limit period.
> 
> Perhaps I misunderstand, but I think that's wrong in general and based
> on the persistent and by now very irritating confusion between client
> rate limiting and response rate limiting (RRL).  

No, it isn't.

Suppose that DNSprov provides DNS service on behalf of HiProfile.
Suppose that HiProfile has one of those services that is really
susceptible to the "no response, kill the page load" problems that the
big web presences -- Amazon, Yahoo, Twitter, &c -- keep worrying
about.  Moreover, because of the usual commercial reasons such
services have, the TTLs on HiProfile records are short.

Now, suppose that MrISP is a very large US-based cable provider with
something like (say) 10% of the domestic market.  All MsAttacker needs
do to cause significant pain is to send a DoS towards DNSprov with
source addresses of MrISP's resolver querying for HiProfile's names.
RRL will work, of course, in the sense that it will stop spewing
garbage.  But it will also rate limit responses to anyone apparently
coming from that address.  This means that MsAttacker can cause
MrISP's resolvers to be rate-limited as long as MsAttacker can keep up
the attack for something longer than $TTL on some record for
HiProfile.  In other words, MsAttacker can cause a short but probably
effective DoS against HiProfile, and with a little work can probably
cause intermittent outages for a significant percentage of MrISP's
customers every few minutes.  

This is perhaps a less bad attack than before, depending on DNSprov's
provisioning; but it is contractually devastating for DNSprov, who
promised not to drop queries on the floor for HiProfile, but who has
dropped such queries on purpose.  One can mitigate this to some extent
with various additional epicycles to the RRL approach (and I note that
you've done so, and congratulate you in your acumen and creativity),
but one cannot solve the fundamental issue, which has to do with very
high-value targets and very large communities behind certain
high-value resolvers.

It's a trade-off.  RRL works well in some -- maybe most -- cases, but
it's not something one can do in others.  That's hardly surprising, I
think.

> If you think not letting the IETF "improve" and then freeze the
> specification will lead to fragmentation and disparate implementations,
> then you should oppose an RFC.

I wasn't opposing anything.  I was trying to clear the ground so that
we understood, going in, what the bureaucratic hurdles would be so
that we wouldn't have to worry about them when we settled on an
approach to pursuing an RFC.  I'm neither here to defend nor bury the
IETF.  I intended only to ask what one wanted to do there _before_ we
got the IETF process wheel griding our bones to dust.

Best,

A

-- 
Andrew Sullivan
ajs at anvilwalrusden.com