December 2004 - Test - lists.nanog.org

Re: Dampening considered harmful? (Was: Re: verizon.net and other email grief)
by Jerry Pasker 21 Dec '04

21 Dec '04

>Well, a particular router doesn't get to set its dampening according >to its 'view' today, and that view is going to vary depending on >prefix. > >I would like to argue that how we define flapping today is simply a >broken concept. We count up/down/path change transitions, but such >transitions can exist due to connectivity or implementation >differences and may have nothing to do with not complying with >ettiquette. If people were damped for a single up/down, then yes, that's a problem. Dampening someone because they have a single path change is not the idea. That would sort of nullify the spirit of being multihomed with BGP, or even using BGP in any production or transit network for that matter. IF there's a connection problem, or implementation difference that makes a lot of up/down, then dampening could occur close to the "problem" but it will be contained close, and won't spread to the rest of the internet. >I submit that a better way of measuring flap is to look at the >period over which a particular prefix is flapping. Anti-social >behavior is many changes occurring over long periods of time. >However, many changes over a short period may well not be a problem. > >Regards, >Tony > So configure your route dampening that way. No one's twisting your arm to use the defaults. Want many flaps in the short term to not be damped? Simply increase your suppress limit. Way way up. Increase or decrease your half-life as you see fit. Just don't expect the rest of the world to do the same. But do expect to see others damp the flapping that you leak to their network. <gut feeling> If no one on the net ran dampening, routers wouldn't get anything done except processing constant churn. </gut feeling> I'm grateful that routers out there in the world are doing route-damp so my router's CPU doesn't have to deal with needless route-churn, even if it does impact my connectivity (to poorly connected) end sites somewhat. The stability is worth it. Another item to consider, is this is a sentence from RFC2439 " By damping their own routing information, providers can reduce their own need to make requests of other providers to clear damping state after correcting a problem." Using that logic, I'm also grateful for my transit providers dampening the advertisements to their peers, of my flapping transit links to them. That way, when they flap, (hey, it happens to everyone eventually) it doesn't get me damped by the rest of the internet, and my connections to different transit providers can do their job of carrying the traffic. Dampening, in it's current state, really is a good idea. -Jerry

2 1

Botnet pointer
by Hannigan, Martin 21 Dec '04

21 Dec '04

I've received a number of emails that indicates a lot of people are in the dark about BotNets. John Kristoff made an excellent technical presentation regarding BotNets at NANOG 32 in Reston. http://www.nanog.org/mtg-0410/pdf/kristoff.pdf I have an executive level summary I'm willing to share if it can be useful. Off-list please. Thanks. -M< -- Martin Hannigan (c) 617-388-2663 VeriSign, Inc. (w) 703-948-7018 Network Engineer IV Operations & Infrastructure hannigan(a)verisign.com

5 5

Re: Dampening considered harmful? (Was: Re: verizon.net and other email grief)
by Jerry Pasker 20 Dec '04

20 Dec '04

>An even more important consideration is whether our current paradigm >of flap dampening actually is the behavior that we want to penalize. > >If a single link bounces just once, then thanks to our mesh, >confederations, differing MRAI's etc., we can see many many changes >to the AS path, resulting in dampening. Do we really want to >inflict pain over such an incident? > >Tony > Of course not. Dampening should be set on a router according to that router's views. The more chances a router can see a single event multiplied, the more lax dampening should be on that router. I think Rob Thomas's saying of "know your network" really applies here. In my book, the threat of dampening to anyone not playing nice is the true value of route dampening. Automatic enforcement of etiquette. -Jerry .

1 0

Re: Botnet pointer
by Fergie (Paul Ferguson) 20 Dec '04

20 Dec '04

Here's a decent pointer: http://en.wikipedia.org/wiki/Botnet - ferg -- "william(at)elan.net" <william(a)elan.net> wrote: Can somebody also share good definition of "BOT" and "BOTNET" for glossary and description of 2-4 lines? -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net

2 1

Spammers ordered to pay $1 billion
by Hank Nussbacher 20 Dec '04

20 Dec '04

http://www.cnn.com/2004/LAW/12/18/spam.lawsuit.ap/index.html What a nice present for the holiday season :-) -Hank

4 3

RE: Anycast 101
by Hannigan, Martin 20 Dec '04

20 Dec '04

> -----Original Message----- > From: Gadi Evron [mailto:ge@linuxbox.org] > Sent: Monday, December 20, 2004 3:32 PM > To: Bill Nash > Cc: Hannigan, Martin; nanog(a)merit.edu > Subject: Re: Anycast 101 > > > > Botnets aren't new. They've been prototyped on various IRC > networks for > > years. It started with hordes of linked eggdrop bots for Death Star > > style privmsg/notice flood attacks on single users (1998? > 1999?). When > > For history's sake, most people name BO and netbus as the "original" > remote control Trojan horses. Those that started all the mess. My sentence was a typo. I mean they "aren't a new" phenomenon. I agree with you on the rest.

1 0

RE: Anycast 101
by Hannigan, Martin 20 Dec '04

20 Dec '04

> -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > John Kristoff > Sent: Monday, December 20, 2004 1:10 PM > To: nanog(a)merit.edu > Subject: Re: Anycast 101 > > > > On Mon, 20 Dec 2004 17:18:30 +0000 > Paul Vixie <paul(a)vix.com> wrote: > > > there are some million-bot drone armies out there. with > enough attackers > > I've heard that claim before, but I've yet to be convinced that those > making it were doing more than speculating. It is not unreasonable to > believe there are millions of bot drones, but that is not the same as > an army under a single or even coordinated control structure. It is > entirely possible to build armies of that size, but maintaining them > over any length of time is probably quite difficult. I'd of course be > interested to hear about any evidence to the contrary on or off list. > > John I know I haven't seen any 1MM+ zombie armies out there and I'm looking for them. Why spend all that time getting 1MM bots when you only need 100K? -M<

2 1

RE: Anycast 101
by Hannigan, Martin 20 Dec '04

20 Dec '04

> -----Original Message----- > From: Bill Nash [mailto:billn@billn.net] > Sent: Monday, December 20, 2004 3:33 PM > To: Hannigan, Martin > Cc: John Kristoff; nanog(a)merit.edu > Subject: RE: Anycast 101 > > > On Mon, 20 Dec 2004, Hannigan, Martin wrote: > > > >>> there are some million-bot drone armies out there. with > >> enough attackers > >> > > I know I haven't seen any 1MM+ zombie armies out there and I'm > > looking for them. Why spend all that time getting 1MM bots when you > > only need 100K? > > Dormant reinforcements. Multiple operational floodnets in > smaller cells. > Rapid reconfiguration of a cell, cycling in new hosts, > removing hosts that > have sustained functional losses to reactive routing changes. > Having those > kinds of resources on hand allows an attacker to use a > 'Captain Tripps'[1] > style of attack to maintain a sustained assault on single, or even > multiple targets. We aren't dealing with stupid people. If 1/10th of the bots will do the trick, that's 1/10th of the work. A larger botnet would expose the controllers much more rapidly with focused traffic flows towards the controllers. No controller = no $$. You'd also have more people involved to speed up the process and now you're spending money that you don't have to when 100K will suffice nicely. Whether you buy the botnets or you build them yourself, you need time to generate revenue. Survival and greed are factors here. Aggregating botnets is possible, sure. But that means you're paying someone for their use. They aren't just giving them away. Of course, you could buy a botnet, but again, why buy when you can build 100K botnet in short order and for free? Discussing botnet sizes is irrelevant though except in the case of mitigation and deciding where to spend time working *80/20*. Look at how the discussions surrounding SPAM have evolved. It went from "damn abusers", to "damn software", to "where's the money coming from?". The BotNet problem has already evolved to "where's the money". Botnets are a new phenomenon. [ Gadi!?] [ SNIP ]

3 3

Re: Anycast 101
by Paul Vixie 20 Dec '04

20 Dec '04

> > but at that point, the only thing anycast would buy you is ddos > > resistance and the ability to have more than 13 physical > > servers... which is all the > > Is that true? I'm failing to see how anycast helps expand a network's > DDoS survivability. At best a dumb attacker would attack the IP > address of the server and it would be distributed to all the > participating anycast nodes. as it turns out, some attackers really are idiots, and it's considered socially acceptable to pander to them even while also attempting to guard against real attacks coming from experts. > What prevents the attacker to hit just a few nodes from the anycast > network to hurt percentages of the dns queries? nothing, of course. but we like that the percentage isn't always 100% (as it would be in the non-anycast case.) > Obviously health checking would prevent some of the problems but then > the attacker can just shift from site to site as the health checks > happen. there are some million-bot drone armies out there. with enough attackers you can just attack everything the defenders might try to use -- no need to shift from site to site in response to anything. > With that thought process, an anycast network is only as it's most > beefed up node. As the smaller nodes fail the one left standing will > be what prevents the attack, not anycast. i admit that this appears true on the surface... but if you dig into it you'll see that even a root name server with 10,000 direct 10GigE connections (one for every autonomous system in the internet) would still be vulnerable to congestion based attacks, since a congestion based attack is against OPN's (other people's networks) where even infinite point-source provisioning cannot help you. > For an example, let's look at f.root: > f.root-servers.org is 204.152.187.7 that's .org not .net. f.-.org is just a web server. you want f.-.net. > If an attacker wanted to be violent and have complete disregard for > the anycast design, he/she would hit either each node independently > and at the same time hit the upstream routes of both nodes. That > would isolate each node from the anycast primary "VIP" of > 204.152.187.7 and introduce problems into the design. Then, as those > sites were failed out, he/she would shift the attack to the current > operating sites. an effective attack doesn't need to be nearly that subtle. > Eventually this cat and mouse would cause such a problem that the > saving grace of the anycast design would be the strongest node in the > cluster and the operators would have to fail each site in and out as > the attack shifted around. i suppose that you could do it that way, if you wanted to be more artful. > If they were really violent they would include a randomized valid > query attack in the mix. you mean they aren't? > Can you explain to me how anycast would prevent this? i knew, at the time i wrote the words "ddos resistant" in this thread, that at least one person would think i meant "ddos proof". in wristwatches, "water resistant" means you can shower or bathe while wearing the device, but only "water proof" means you can scuba dive with it. anycast makes a dns service more ddos resistant. nothing can make a dns service ddos proof.

4 5

Re: Anycast 101
by Paul Vixie 20 Dec '04

20 Dec '04

> Since when bad engineering is bad to the big business? whenever it makes your service less attractive than your competitors. > The world is full of examples to the contrary. yes, but only where there's a monopoly of some kind.

1 0