From: Ben Butler (no email)
Date: Sun Feb 03 2008 - 17:18:51 EST
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
-----Original Message-----
From: [mailto:] On Behalf Of
Christopher Morrow
Sent: 03 February 2008 20:56
To: Tomas L. Byrnes
Cc:
Subject: Re: Blackholes and IXs and Completing the Attack.
On Feb 3, 2008 2:53 PM, Tomas L. Byrnes <> wrote:
> 3: Backbone routers can't reasonably filter on a bunch of /32s and
> also forward traffic at wire speed.
yes they can. the size of the individual route doesn't matter to the
devices in question, the NUMBER of routes does... (as does the
associated change-rate of that number, but that's a story for another
day)
>
> 4: It would be much harder to get all the ingress networks, which
> include all sorts of small local and regional ISPs, to join such a
> scheme than it would be to get larger ISPS to do so, assuming item 3
> above is not true.
>
some already do this though... not in quite the manner Ben's aiming to
do, but there are folks that accept BGP feeds in order to drop traffic
inside there network(s).
> 5: When one /32 is under DDOS, the rest of the hosts served by the
> same links are also effectively DOSed, ergo renumbering them out of
> the DOSed space, while painful, might be less painful than continuing
> to deal with the DOS.
>
you have not had to deal with renumbering I presume? not a raft of
end-users (consumers nevermind businesses). Why is the assumption that
the surrounding space is a /24 relevant exactly? The aggregation scheme
used inside any particular network isn't necessarily '/24 per
pop/link/service-area'...
renumbering for DDoS isn't really a workable solution, save the distinct
case when you own the IP in question and services it provides (and other
ancillary bits/bytes related to said ip/device/thingy).
> 8: Disaggregation can be done now, with the tools currently available,
> and requires no additional hardware, software, or legal agreements.
>
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...)
anyway, the idea behind multi-as blackholing has been (and apparently
contunues to get) rehashed a few times over the last 5-8 years... good
luck!
-Chris
|
|
|