Blackhole Routes

Ian Dickinson ian.dickinson at pipex.net
Sun Oct 3 10:57:40 UTC 2004


Richard A Steenbergen wrote:
> On Sat, Oct 02, 2004 at 11:06:31PM +0100, Ian Dickinson wrote:
> 
>>You'd need an additional community to flag this eg. 65001:666 means to
>>blackhole, 65001:6666 means to propagate it as well.  I can't speak for
>>others but when we blackhole the destination (as opposed to blackholing 
>>the source or mitigating) we often only do it in the direction from
>>which the attack is coming*.  Why drop globally when you can drop
>>traffic from a subset of the Internet?  Your victim will thank you
>>if 90% of their customer base can reach them, versus none.  Similarly,
>>if they're multi-homed, they may well rely on you NOT propagating.
>>Maybe this looks different from the perspective of a global Tier-1.
> 
> 
> No, 65001:666 (or whatever value is chosen for a well known community, for 
> the sake of argument) means to set the next-hop to something that discards 
> packets, and otherwise propagate the route as normal. If you don't want it 
> to be exported in a specific direction, you add no-export or no-advertise 
> or just don't advertise it to peer X just like you would do with any other 
> route. Don't complicate the protocol unnecessarily based on your specific 
> assumptions of how you might or might not use a feature.
> 
> There is nothing more or less complicated about this than adding a value 
> to the end of http://www.iana.org/assignments/bgp-well-known-communities 
> and declaring it a standard blackhole community. How you use it, how you 
> export it, and who you accept it from, are provider specific policy 
> decisions. However, based on the knowledge that a blackhole community 
> route is no different than a regular route in its ability to cause 
> unreachability if incorrectly announced, I would tend to suspect that most 
> people would choose to allow this to be propagated globally.

My point is that no-export or no-advertise doesn't play well with 
multiple ASNs under common admin control.  Don't simplify the protocol
unnecessarily based on your specific assumptions on how others may or
may not use a feature.  Blackholing schemes need to be simple enough
to employ in a hurry at 4am whilst still achieving the desired effect.
-- 
Ian Dickinson
Development Engineer
PIPEX
ian.dickinson at pipex.net
http://www.pipex.net

This e-mail is subject to: http://www.pipex.net/disclaimer.html



More information about the NANOG mailing list