- NANOG - lists.nanog.org

Re: engineering --> ddos and flooding
by Walter Prue 04 Jun '01

04 Jun '01

I came up with a solution for networks with ISP connections to deal quickly with DDOS attacks without having to be able to work with a network technician at the ISP for immediate relief. If the ISP agrees, install a second low speed connection to the same router your primary router BGP peers with. Through this low speed connection you run a second bgp session advertising the /32 that is being attacked by the DDOS. You mark the /32 as NO-ADVERTISE so the route doesn't leave the border router. If you can't bgp peer with the same router as the primary connection you advertise the attacked /32 with the NO-EXPORT community so the route stays within the ISP's AS. This second low speed connection thus becomes a lightning rod for the DDOS traffic most of which will be discarded and not even delivered due to congestion on the slow speed link, the slower the better for you. This of course kills all traffic to the attacked node but the rest of the network remains usable. Then at least if the attack can be further defined you can contact your ISP for a port specific or source address specific filter so that more legitimate traffic can be accepted. Another approach might be for the ISP to take a low end router like a cisco 2600 and run multihop bgp with their customers who want this kind of service. The router would remap the next hop information for all routes it receives to null0 or perhaps a 100 Mb/s ethernet with nothing on it. It would also mark all the routes NO-EXPORT. Then only the single connection to the customer is needed. Two possible Achilles heal with this approach is that the multihop bgp session between the customer and the ISP's low end router may die under the flood of the attack. Also the low end router could drop it's IBGP peering if it becomes too flooded with the now redirected traffic. Of course appropriate route filtering would be essential so your customer could only advertise his own routes to be routed to a black hole. Walt

8 11

Re: A moment of silence.
by Simon Lockhart 04 Jun '01

04 Jun '01

>> >It appears that MFS finally went and did it, and the mae-east we >> >all came to know and love has finally been turned off. Please bow >> >your heads for a moment of silence. I've had a private reply to say that someone's MAE-E FDDI connection is still up. I've also heard of connections going down earlier this week. Could Worldcom be doing a phased shutdown? (Presumably this would be obvious to anyone who still has a live FDDI connection) Simon -- Simon Lockhart | Tel: +44 (0)1737 839676 Internet Engineering Manager | Fax: +44 (0)1737 839516 BBC Internet Services | Email: Simon.Lockhart(a)bbc.co.uk Kingswood Warren,Tadworth,Surrey,UK | URL: http://support.bbc.co.uk/

6 5

RE: 95th Percentile = Lame
by Joe Blanchard 04 Jun '01

04 Jun '01

Hmmm.. In reading this thread. Does this mean that if I send an 0xFFFF bit pattern to a network versus a 0x0000 pattern I'd be charged more for the energy consumption since all the 1's are high and consume more elecetric, and is there a larger charge for CA given the electric issues there? lol Well just had to throw that in since some of these comments are a bit far fetched.... just my 2¢s Happy Monday all. -Joe Blanchard

3 2

RE: 95th Percentile = Lame
by Joe Blanchard 04 Jun '01

04 Jun '01

Hmm, I thought 1's were high and 0's were low? lol Oh well, such is digital.. -Joe Blanchard -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Sunday, June 03, 2001 9:26 PM To: Joe Blanchard Cc: nanog(a)merit.edu Subject: RE: 95th Percentile = Lame > In reading this thread. Does this mean that if I send an 0xFFFF bit pattern > to a network versus a 0x0000 pattern I'd be charged more for the energy > consumption since all the 1's are high and consume more elecetric no, it's the transitions from 0 to 1 or vice versa that take the energy. that's why the nanog list is so repetitive, saves money. randy

1 0

Re: 95th Percentile again (was RE: C&W Peering Problem?)
by Paul Vixie 04 Jun '01

04 Jun '01

How quickly they forget. > UUNet bills for the MAXIMIUM 95th percentile on inbound OR outbound, > whichever is higher, as does AboveNet, and probably the majority of > networks trying to be like UUNet. In case this is unclear, AboveNet was the first to do 95th percentile, and UUNet was the first of those who have since followed in Dave Rand's footsteps. > But a significant portion of other networks will bill for the AVERAGE > under the 95th percentile. When I asked DLR why he those 95th percentile he claimed it was to account for the "averaged peak load" that a customer put on his backbone. Throwing away the highest 5% of samples was somewhat arbitrary -- could have been 4% or 6% and the result would've been about the same. What he was trying to get at was a way to make what the customer paid be related to what it cost him to provision backbone and peering links. It seems, based on the rest of the industry having followed his example, that he was onto something.

4 3

Re: 95th Percentile != Lame
by Richard A. Steenbergen 04 Jun '01

04 Jun '01

On Sun, Jun 03, 2001 at 08:16:28PM -0700, James Thomason wrote: > > This is very true. You have also in this example, defined your basis > of cost and could effectively say "Today, every bit that crosses my > network costs me X". This is a hard, quantified and total cost that > includes all of your provisioned capacity. Also, 95th percentile does not take into account peak hours for its pricing. You could push your peak traffic at off-peak hours and still be billed a very high amount. A more sensible system would be a different price for on-peak times. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

Re: 95th Percentile != Lame
by Paul Vixie 04 Jun '01

04 Jun '01

> I still fail to see how "peak bits" or "bursted bits" are more expensive > than "regular bits". A 100Mbit FE port costs whatever it costs, and does > not fluctuate with usage. This is true of almost all of your links within > the network - excluding those where you have negotiated usage-based > billing. An OC3, point to point, costs as much as it costs irrelevant of > its usage. Therefore, every bit that crosses this circuit has a cost. > > Why not simply pass this cost on to the customer bit for bit? let's say that you've sold 1Gb/s of connectivity to each of 50 customers. if you don't do anything fancy in your backbone provisioning, two things will happen: (1) you will need 50Gb/s of peering connectivity to EVERY PEER and on EVERY BACKBONE LINK (just in case all five customers send full blast to the same destination at the same time, as in a DDoS or flash crowd scenario); (2) when you try to pass the costs of this provisioned capacity to all of your customers (equally), you will have noncompetitive rates. what actually happens is that you provision as much capacity (including whatever headroom your business plan calls for) as is actually needed, and then try to upgrade it fast enough so that your customers always get their bits through. it is not actually possible to get 50Gb/s worth of peering connectivity to most peers -- and if you could then they'd be dropping most of your traffic one hop inbound on their network anyway. charging for 95th percentile (highest of in or out, not additive) is a way to get those customers whose traffic puts the most strain on the provisioning plan to pay more. but consider another model for a moment. the power companies hereabouts use the monthly peak to set the rate (per KwH) for the month. so if you never hit them very hard then every KwH you buy from them is cheaper. this model correctly passes the provisioning (especially headroom) costs to commercial customers who put the most stress on the system, but also correctly rewards customers with lower costs based on them keeping their actual usage down. i'm not suggesting that this would apply perfectly to the IP transit situation, but it takes more of the relevant factors into account.

2 1

Re: 95th Percentile = Lame (fwd)
by James Thomason 04 Jun '01

04 Jun '01

> No. > > The issue here is "incremental" cost. Once the circuits are all > provisioned, it doesn't matter what you send over them, true. But it's > not the *loops* that cost you money. It's the backbones. It's the > *aggregate* total of the speeds of the *router ports* (which is what > you're charging for, anyway), not the aggregate total of the speeds of > the *loops*, that is the real issue here. > > The telco charges me the same thing for the loop regardless of howmany > timeslots I provision the customer for in the router. I hear what you are saying here. But do you not think that these costs can be quantified, and reduced to a common denominator? Should not the cost of provisioning "excess" bandwidth be part of the BASIS cost you pass on to customers? Should not other networks who currently dump traffic to you "freely" pay that cost as well? In a simplified sane model: My Cost: Circuits c Power p Space s Equipment e Other o ---------------- c+p+s+e+o = C(ost) C + P(remimum) = Cost to Customer C + T(arrif) = Cost to Providers The cost (C) must be paid for every bit that traverses my network, either from customers or "peer" networks. The current non-quantified C is paid for completely by customers - SOMETIMES and MAYBE, since we bill on an average instead of a value. Some customers pay for other customers traffic, and some get traffic for free. Does your stock broker bill you on an average number of shares for a set of transactions? Or does he charge you a per share fee? Are you SURE? > > Since that's true, it's useful to have *some* way to allow the > provisioned bandwidth to float up a little closer to the aggregate > usable bandwidth in my backbone, since it does *in fact* not cost me > anything. > > (Anyone whose provisioned their backbone to 100% of their aggregate > access bandwidth -- in an access network, not a server farm one -- just > doesn't understand the business. *Everyone* bandwidth-surfs. The > billing approaches we're talking about are just a slightly better way > of matching the two numbers.) > > Cheers, > -- jra > -- > Jay R. Ashworth jra(a)baylink.com > Member of the Technical Staff Baylink > The Suncoast Freenet The Things I Think > Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015 > > OS/X: Because making Unix user-friendly was easier than debugging Windows >

1 0

mae-east customer service (Re: A moment of silence)
by Sean Donelan 04 Jun '01

04 Jun '01

On Sun, 03 June 2001, Leo Bicknell wrote: > It appears that MFS finally went and did it, and the mae-east we > all came to know and love has finally been turned off. Please bow > your heads for a moment of silence. Can someone who is paying Worldcom for service at mae-east call mfs/worldcom and ask what the current status is? I understand worldcom doesn't have the best reputation as a customer service driven company, but someone in the organization must know the actual status of mae-east.

1 0

Re: A moment of silence.
by Richard A. Steenbergen 03 Jun '01

03 Jun '01

On Sun, Jun 03, 2001 at 08:48:27PM +0100, Simon Lockhart wrote: > > >It appears that MFS finally went and did it, and the mae-east we > >all came to know and love has finally been turned off. Please bow > >your heads for a moment of silence. > > So what is everyone going to do instead? > > Join MAE-East-ATM? > > Join PAIX-VA? > > Join ISPCondo? (Abovenet's NAP in 8100 Boone) WorldCom wants you to move to MAE-East-ATM, eventually moving everyone to their new facility in Ashburn VA. I think/hope most people will just move to PAIX-VA or Equinix-VA, or both. I tried to think of a good parody of American Pie for this occation, but I didn't want to stretch FDDI to end in a long-I, so I'm just gonna go with: Ding Dong the Wicked Witch is Dead. Now if only they'd kill off ATM too. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0