North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Blackholes and IXs and Completing the Attack.
On Feb 3, 2008 5:18 PM, Ben Butler <[email protected]> wrote: > > 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