"destination-based blackhole routing for mitigation *effectively completes the attack*, which is often times undesirable. Inter-domain source-based blackhole routing is pretty much a non-option." That is why I put Completing the Attack in my subject line - and didnt attempt to sujest this as an approach for source based filtering. "If you do implement something like this you may wish to scope advertisement only to adjacent ASes via NO_EXPORT or the like, to scope both more-specific propagation, and to ensure that some lack of consistent drop community semantic interpretation doesn't hose something." It is upto the receiving AS what they do with the announcement and whether they advertise it to their BGP customers or not - they shouldnt be announcing to anyone else anyway. I would sugest they dont, but I wouldnt presume. Advertisments to transits do not get propigated outside their AS. "I suppose if folks rely on it for native peering then it might be reasonable." This is envisage to be used between members of the same Internet Exchange only. Where there are so many peers the overhead of trying to do this on a peer peer basis / agreeing comunities is going to be a pain in the arse. And that this gives an easier way to get to the goal - we do after all trust the IX operator to run the critical bit of infrastrucutre which is the exchange. Kind Regards Ben -----Original Message----- From: Danny McPherson [mailto:danny@tcb.net] Sent: 02 February 2008 20:49 To: Ben Butler Cc: NANOG NANOG Subject: Re: Blackholes and IXs and Completing the Attack. On Feb 2, 2008, at 1:16 PM, Ben Butler wrote:
So, given we all now understand each other - why is no one doing the above?
Some folks are doing this, just not via some third-party route servers. For example, either via customer peering sessions, or other BGP interconnections between peers. E.g.: http://www.nanog.org/mtg-0402/morrow.html I'm not sure it's ideal to employ third-party route servers for this purpose, as it only increases the attacks/error surface. I suppose if folks rely on it for native peering then it might be reasonable.
At the end of the day if an IX member doesn't want the announcements don't peer with the blackhole reflector, simple, and it will get Null routed as soon as it hits my edge router at the IX - it would just seem more sensible to enable people to block the traffic before it traverses the IX and further back in their own networks.
Yes, helping to ease effects of collateral damage from large-scale attacks by conveying drop policies to upstream ASes for prefixes which you originate. And perhaps as significant, being able to allow the target AS to remove those policies dynamically, rather than having to contact each upstream AS that appears to have imposed them manually out-of-band. I think Paul's comments were more regarding the fact that destination-based blackhole routing for mitigation *effectively completes the attack*, which is often times undesirable. Inter-domain source-based blackhole routing is pretty much a non-option. One other offshoot is that advertised more-specifics are going to further contribute to routing AND forwarding table bloat, and a single new prefixes might result in 10+ new paths in the iBGP RIBs. If you do implement something like this you may wish to scope advertisement only to adjacent ASes via NO_EXPORT or the like, to scope both more-specific propagation, and to ensure that some lack of consistent drop community semantic interpretation doesn't hose something. Also, if you impose this as a standard attack response mechanism recall that you lose visibility of attack scales, and knowing just when to resume normal forwarding policies is a bit more complex. As such, your policy sets may want to provide hooks that enable selective prefix advertise/withdraw drop policies so that it can be applied or removed incrementally. -danny