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

[Mark Andrews]

In message <5069473B.1070900 at redbarn.org>, Paul Vixie writes:
> 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 o
> f identifying that set of clients.  Those clients arn't using the server a re
> flector.  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.

There is NO problem for multiple 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.

No one is saying to assume that every client coming from a address
supports cookies.   The server does not remember which clients
supports cookies or does not support cookies.  The address + cookie
content + secret is enough for the server to determine if this
*query* is from client it has talked to before.

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

What server side state?  cookies has no per client server side state.  It
has a server secret (shared with anycast servers).

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

Cookies is trivial to implement.  It gives benefit to those that
implement it.  As for RFC 2671 it's hard to find servers that don't
implement it today.  Most of RFC 2671's problem lie in firewalls
and only a small percentage of the ones that caused RFC 2671 problems
look at the contents of a DNS message.

Adding EDNS options, which this is, has been much smoother that
adding EDNS itself.

> >> 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 i
> nto browsers are going to start to look like those for the game of fizbin." -
> -rick jones
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org