North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Blackholes and IXs and Completing the Attack.

  • From: Danny McPherson
  • Date: Sat Feb 02 16:00:23 2008

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.:

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

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.