North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Blackhole Routes

  • From: Ian Dickinson
  • Date: Sun Oct 03 06:58:35 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
[email protected]
http://www.pipex.net

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