Good luck with rate limiting! Fixing the edge is vital; having a way to inject a path/flow to take the traffic to a bucket is also important - routers work best when routing. (Openflow has a great use case in this area)
having distribution in the core and aggregation layer and routers that have the right capabilities to cope with attacks (and configured correctly) also important. Too many organisations also running networks off platforms that are software based or have shared fate. And IPV6 - the best attacks are yet to come. Neil Sent from my iPhone On 31 Jan 2013, at 19:34, "Tony Finch" <[email protected]> wrote: > Keith Mitchell <[email protected]> wrote: >> >> This only works for recursive resolvers - for authoritative nameservers, >> the traffic profiles are such that it's very difficult to >> distinguish between legitimate and attack traffic. > > That isn't true at the moment. There are a number of quite crude but > effective remedies against current amplification attacks, and response > rate limiting should be effective against many future attacks too. > >>> It's slightly easier to trace this if it's your nameserver that's >>> being used as one of the relay/reflectors rather than if you're the >>> target since you're closer to the true source of the fake queries. >> >> I know a number of large authoritative TLD operators who've been working >> on this for some months now, and have yet to report any results. If you >> know anyone or anything that can do better, I'd love to hear from them. > > Our experience (cam.ac.uk) of trying to trace back the source of attacks > has been very discouraging :-( > > Tony. > -- > f.anthony.n.finch <[email protected]> http://dotat.at/ > Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. > Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, > occasionally poor at first. > >
