North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
RE: Blackholes and IXs and Completing the Attack.
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: owner-nanog@xxxxxxxxx [mailto:owner-nanog@xxxxxxxxx] On Behalf Of Christopher Morrow Sent: 03 February 2008 20:56 To: Tomas L. Byrnes Cc: nanog@xxxxxxxxx Subject: Re: Blackholes and IXs and Completing the Attack. On Feb 3, 2008 2:53 PM, Tomas L. Byrnes <tomb@xxxxxxxxxxx> 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