[dns-operations] First experiments with DNS dampening to fight amplification attacks

[Paul Vixie]

On 2012-09-29 2:28 AM, Mark Andrews wrote:
>>>> Are you referring to this?
>>>> http://tools.ietf.org/html/draft-eastlake-dnsext-cookies
>>> Yes.  It's a reasonable way to identify non-spoofed traffic which
>>> means you can apply filtering techiques to the rest of the traffic
>>> which will be a mix of spoofed and non-spoofed.
>> i don't agree. there's no way to tell the difference between a client
>> who hasn't upgraded, vs. a client who has downgraded or is behind a NAT
>> box, vs. a spoofer. therefore we will not be able to drop non-cookied
>> queries even while under attacks which spoof the same netblock as we get
>> a non-cookied query from.
> It's about identifying non spoofed returning clients.  It does a good job of identifying that set of clients.  Those clients arn't using the server a reflector.  Those clients don't need to be penalised.

unless we can distinguish between packets from clients who don't
implement EDNS from packets which are spoofed this is a small comfort to
us or them. this is especially problematic for a large set of clients
behind a NAT.

> It also does a good job of protecting clients from off path spoofed replies.

i don't think i'd be willing to drop non-EDNS requests just on the basis
that some EDNS+cookies requests are coming from that address. so, no.

> For the server queries that present no cookie or a bad cookie go
> into the potentially rate limited pile.

i'm ready to accept that rate limiting (as specified by DNS RRL) hurts
non-spoofing clients who ask "similar enough" questions during the
attack. but so far this has not been demonstrated or even described. a
real recursive-service initiator may be forced to retry by UDP or even
by TCP. but a real recursive-service initiator will usually have a
cache. so the number of "similar enough" questions they'll ask will be
so small that the total pain of this delay is not worth the investment
of server-side state to solve for it.

> For clients the benefits come in less need to use multiple ports
> and knowing they are not going to be rate limited other than on
> initial queries when talking to servers that support cookies.
>
> This is about pulling out good traffic from the undifferentiated
> traffic we have today.

given that RFC 2671 was finalized more than a decade ago, we now know
the deployment curve of something like this. for that investment i want
more payback next time. thus, RFC 6013.

>> see RFC 6013, as earlier summarized in ;login:
>> (http://static.usenix.org/publications/login/2009-12/openpdfs/metzger.pdf),
>> for another approach to fixing not just DNS but HTTP state management.

paul

-- 
"It seems like the rules for automagic completion of incomplete names typed into browsers are going to start to look like those for the game of fizbin." --rick jones