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

[Mark Andrews]

In message <5065BD2C.7030302 at redbarn.org>, paul vixie writes:
> On 9/28/2012 2:48 PM, Mark Andrews wrote:
> > In message <alpine.LSU.2.00.1209281541070.1469 at hermes-1.csi.cam.ac.uk>, Ton
> y Finch writes:
> >> Mark Andrews <marka at isc.org> wrote:
> >>> Server cookies are the way to go though I would add timestamps so
> >>> that server secrets don't need to be changed.  The time stamp would
> >>> have to be within X seconds of the servers current concept of time
> >>> or it will be treated as a bad cookie.  The time would be concatenated
> >>> to the rest of the data to be hashed.
> >> 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.

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

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

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.

> 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
> 
> -- 
> "I suspect I'm not known as a font of optimism." (VJS, 2012)
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org