Blackholes and IXs and Completing the Attack.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

anyway, the idea behind multi-as blackholing has been (and
apparently continues to get) rehashed a few times over the
last 5-8 years... good luck!

It seems that way. People seem to forget about the conversations and
work around 2000 - 2002. We not only had RTBH (static), multi AS
RTBH, Source based RTBH (why uRPF Loose check was created), BGP
Community based packet filtering (QPPB - source or destination),
Backscatter Traceback (Chris and Brian's cool technique), Customer
triggered RTBH (another Chris and Brian trick), BGP Shunts
(originally created for the Great Firewall), MAPS's grow (which had
multi-AS eBGP multihops BGP RTBHs back in 1997 for anti-SPAM
filtering), and then all the BGP Flow-Spec work.

We even have a RFC - 3882 Configuring BGP to Block Denial-of-Service
Attacks. by D. Turk. published in September 2004.

This is a good conversation for NANOG, but we really need to build up
some FAQ so we don't keep going over the same things every year.

Barry

Hi Barry,

Thank you for some really useful pointers, I am off to do some more
reading.

Kind Regards

Ben

Hi,

<snip>
"your point here is that perhaps instead of this scheme one would just
advertise the max-prefix-length (/24 currently) from a 'better' place on
your network and suck all the 'bad' traffic (all traffic in point of
fact) for the attacked destination via a transit/peer/place which can
deal with it properly?

This isn't a bad solution, and it gives you some control on the traffic
stream, it does have the penalty to everyone else of 'one more route in
the RIB/FIB'... which I think was Ben's vote against this method. (also
not a bad vote...)"
</snip>

Personally, I would achieve this using multiple sinkholes at the edge in
IGP rather than advertising an extra /24 in BGP to suck it to one
router.

PA Deagregation as evidenced in some of my other posts is a pet hate of
mine. PI space (and for that matter v6 PI please) is not - especially if
we clean up the act on the PA front.

Because, my research into anti DoS is still work in progress, I was
going to sort out traffic mitigation through completing the attack
first, then move on to investigating classification using sinks, and
then worry about scrubbing / source filtering last.

I just haven't got around at looking at sinks and scrubbing yet.

I fully accept there is no single silver bullet for all situations and
circumstances, but equally a tactic should be as effective as possible
when it is selected and deployed - which started this thread. And I am
trying to advocate being able to extend completing the attack beyond
just transit feeds that is all.

I don't know about other people our multiple Internet Exchange peak
interconnect capacity versus our transit peak capacity is a significant
%. While effectively securing my AS as a whole against the sources that
reach me via transit, currently I cant do the same trick with XPs. Now
the number of end host systems that I reach via peers is obviously a lot
less than transit but the potential is still there as an unsecured
ingress which could cause problems either through router/wan overload or
interconnect congestion causing packet loss for other traffic. Either
isn't good. In the absence of an alternative, it appears that in the
scenario that I am under DoS, have blackholed a /32 to transit but my
interconnect with an IX is saturated to the detriment of customer
traffic - that the only thing I can sensibly do to resolve the situation
is to temporally admin down / remove my prefix announcement from the IX
peerings to shift the load to transit. This also doesn't seem very
sensible.

Kind Regards

Ben

Hi,

<snip>
"your point here is that perhaps instead of this scheme one would just
advertise the max-prefix-length (/24 currently) from a 'better' place on
your network and suck all the 'bad' traffic (all traffic in point of
fact) for the attacked destination via a transit/peer/place which can
deal with it properly?

This isn't a bad solution, and it gives you some control on the traffic
stream, it does have the penalty to everyone else of 'one more route in
the RIB/FIB'... which I think was Ben's vote against this method. (also
not a bad vote...)"
</snip>

Personally, I would achieve this using multiple sinkholes at the edge in
IGP rather than advertising an extra /24 in BGP to suck it to one
router.

Oops, I think I wasn't clear, my point was you could force traffic off
of most peers and transits and onto a single transit by advertising
the most specific global route possible (/24 today) through a single
transit. This way you can force all of the world to find your attacked
host through a place you choose, rather than 'everywhere'.

Shifting around things in your IGP isn't going to help the
rest-of-the-worlds view of your problem... My proposal would allow you
to normalize traffic on your peer/transit links save one (or a smaller
selection of them)...

You could extend this to pulling the /24 down some sacrificial link
(t1 sort of thing) as well, of course. You could also reverse the
logic and either drop the route toward peers or extend the path via
as-prepend...

I fully accept there is no single silver bullet for all situations and
circumstances, but equally a tactic should be as effective as possible
when it is selected and deployed - which started this thread. And I am
trying to advocate being able to extend completing the attack beyond
just transit feeds that is all.

Sure, and as I and Barry said, there have been several iterations of
this discussion, not that that's a bad thing just a note that this is
ground covered at least a few times.

I don't know about other people our multiple Internet Exchange peak
interconnect capacity versus our transit peak capacity is a significant
%. While effectively securing my AS as a whole against the sources that
reach me via transit, currently I cant do the same trick with XPs. Now

sure you can, just don't have the traffic arrive there, draw it
elsewhere, somewhere you are better prepared to deal with the
problem... Something about fighting battles on your terms not theirs?

traffic - that the only thing I can sensibly do to resolve the situation
is to temporally admin down / remove my prefix announcement from the IX
peerings to shift the load to transit. This also doesn't seem very
sensible.

I'd couch this in the following terms:

"Don't be where the flood is, or deal with it where you are best
equipped to..."

There are many option, getting 'peer' folks to do BHR things for you
isn't simple (most times they don't want you traffic engineering
inside their network...), getting a transit to is another story, most
times they have this facility it's just a matter of finding someone
inside their support crew to get you the right bits/setup.

Extra BGP sessions and unbounded /32 growth doesn't bode well for this
plan either... anyway, it'll be interesting to watch the discussion
progress.

-Chris

If you're trying to do it on a /32 basis, I doubt you'd find too many
border router operators interested in accepting a route that small, but
I may be wrong.
  

I can think of at least one Global Tier One that offers a service that allows one to do exactly this (ie. advertise a /30 or /32 to them with a specific community) and blackhole it.