The provider side solution for DDoS attacks is quite simple... unfortunatly, it's also quite expensive and involves having multiple service centers that are load/geographically balanced with a general massive over provisioning for everything (something that may be a little difficult to accomplish for an IRC network whos' financial model is... well... non-existant at best). The basic idea behind this philosophy is that when faced with large numbers, division is one of your best friends... divide and conquer... you know all that basic stuff they teach you in CS101. From another angle, avoiding the distribution of content goes against the church of the meme... who cares of anyone is looking at it; your content will inevitably end up in somebodies cache, increasing the chance that someone will see it without you having to give it to them. Just because you have an ASN doesn't mean that you're somehow qualified to determin what should be routed globally and what should not. If you want to do it for your own address space, that's fine; however, I do not know of any tier 1 carrier who would be crazy enough to indescriminatly knock their customers off the air because "their traffic profile looked suspicious", let alone other carriers' customers. Any carrier that did would soon find themselves the pariah of their fomer peers and an easy target for lawyers of even modest caliber. Beyond that, black-holing address space at the BGP level is a slippery slope prone to political (and other) exploitation. I like my DDoS solutions to come from the edge of the network, thank you. If you're too small to engineer global service correctly, then I can see how the outlined solution could appear seductive, but the end solution should involve opt-in from your edges and peers (that way nobody can complain when they disappear off the face of the internet for whatever no-good reason). Simon Lyall wrote:
I'm surprised there are not more comments on this. What are other people using to reduce the impact of floods?
On Tue, 3 Apr 2001, David Robb wrote:
An interesting idea which came up at a meeting here a while ago :
As people might be aware, adding routes to null0 isn't the most effective way sometimes of dropping flood traffic. Sending it to an IP address, and then staticly associating a bogus mac address to that IP is often better - the router simply forwards the packet out onto the lan, and the ethernet swallows it. This puts less load on the router.
Now a thought I had while thinking about this... could a BGP community be agreed upon between peers, such that (for example) any static routes to the bogus IP/mac on my router are exported to my upstream with this community set. They see the community, set the next-hop address to their version of the blackhole IP, and possibly pass it on further upstream.
Pro: A reasonably easy way to blackhole a target IP at upstream or peer ISPs without having to get their NOC to implement changes on routers. If the trust relationship for these communities extended far enough upstream, the target IP effectively disappears off the net.
Con: You'd have to trust the downstreams who are injecting these blackhole routes. This could be done careful use of prefix or access-lists, allowing people to propagate /32 blackhole routes for IPs under their control.
Thoughts? [1] Ok, so some configuration might also be needed on the switch to stop the traffic being flooded all over the place.
--------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog