From: Danny McPherson (no email)
Date: Sat Feb 02 2008 - 15:49:12 EST
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
|
|
|