From: Ben Butler (no email)
Date: Sat Feb 02 2008 - 17:34:13 EST
"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:]
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
|
|
|