- Test - lists.nanog.org

RE: engineering --> ddos and flooding
by Richard A. Steenbergen 04 Jun '01

04 Jun '01

On Mon, Jun 04, 2001 at 02:08:52PM -0400, Matt Zito wrote: > > > Sorry but IMESHO null routing a /32 during a DoS attacck > > doesn't exactly > > strike me as engineering. It is more like dealing with the attack in > > real-time. To mean engineering would mean desinging networks > > to be resistant to DDoS and flooding in the first plsce. Giving the customer the option to have their announced prefix null routed internally is a powerful value add that fits in right along side giving them other controls like preference and prepending. Usually this is passed as a community tag, and good networks give their customers these controls. > > To that end no NSP should ever allow spoofed IP addresses outside of > > their network. (not just RFC 1918 addresses but valid IPs that don't > > belong to that NSP) This guarantees nothing. > > Two NSPs should rate limit DoS traffic (ICMP & SYNs) within their > > networks in such a way that it can never DoS a T-1 (or E-1 if you are > > not in the US). [note: I'm not sure if ciso's are up for this workload > > since I primarily work with Juniper.] Bad plan. Then a single t1 worth of attack can effectively stop all icmp or syns from passing through. > Rate-limiting ICMP is not so difficult - rate-limiting SYNs is > basically useless. Syn floods work not because the amount of traffic > they do, but because they fill up state tables or make them so > horribly inefficient as to make the box cease responding on that port. > Given that, say, a linux box has a default queue depth of 128, I can > send 128 spoofed SYNs at a rate of one a second, and in two minutes > that box will stop responding. The larger you make the queue, the > longer it will stand up to a slow SYN attack, but the more costly each > incoming SYN and SYN+ACK becomes, as the data structures become more > and more unwieldy. Wrong, and very much out of date. I didn't write all this down to waste my breath... http://www.e-gerbil.net/ras/projects/dos/dos.txt -- 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

A little assist please..
by Rich Sena 04 Jun '01

04 Jun '01

Am preparing a second round set of qustions for some participants in an RFP that we are conducting for a bandwidth expansion project. Looking for some specific fodder so that I can personalize the questions to each participant - rather than the usual 'what is your over-subscription rate' etc... The second rounders are: C&W Verizon Sprint AT&T Qwest Yipes InterNAP Genuity What we are requesting in this RFP is DS3 and OC3 pricing in 2 locations Boston and MacLean, VA. We were looking at flat and tiered rates.. What I want to structure the questions around is... 1 - Subscription (over and under) and upgrade ratio's 2 - Current capacity and hot points 3 - Outage response 4 - Customer issue responsiveness 5 - Time to delivery I have all of these answers from the marketting staff of each of the second rounders - however I hate lies. Please help with some truthful lighting on these issues - real blue water experience - happy and horror stories - some good fodder that I can carve some specific questions for each specfic participant from. TIA Summarized to list if deemed appropriate... -- Rich Sena - ras(a)thick.net ThickNET Consulting "On the way to understanding; you understand, and forget."

2 1

Asset/Inventory tracking
by Jake L 04 Jun '01

04 Jun '01

I would like to compile a list of software tools used to track deployed or inventoried network infrastructure. If you have any experience using the tools, I would appreciate any comments. In addition, it would be helpful to know what providers are using such tools and to what extent. Server hardware/software tracking tools are also of interest, so any insight on that topic would also be appreciated. Please respond off of the list and I will forward the compiled results to nanog. Thanks in advance, Jake _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com

1 0

Telco provisioning
by Jeremiah Kristal 04 Jun '01

04 Jun '01

I am working to roll out a smallish private network and have run into the usual problems with end-user circuit provisioning. As it has been several years since I've done this, I am not entirely familiar with all the agents/facilitators/resellers that are operating in each RBOC's region. I generally use Extel or Cortel in Verizon territory, mostly because of inertia and laziness. I know that there are similar companies in other regions of the country and would appreciate it if folks could share their experiences good and bad with me. If you really feel a particular rep is noteworthy, please name names. I am looking for companies that can order circuits from at least the local RBOC, and are able to deal with minor inter-carrier connection issues. Familiarity with Qwest's ordering procedures is a plus, but certainly not a requirement. Please send the information to me directly and I will summarize the results for the list. Thanks in advance. Jeremiah

1 0

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

04 Jun '01

On Sun, Jun 03, 2001 at 07:42:13PM -0700, David Klindt wrote: > > > 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? > > It is NOT that the each bit has the same cost - it is the cost of > maintaining enough EXTRA bandwidth so that the downstreams do not > bounce up against the ceiling. That amount is basically covered by > using the 95 rule. But peak vs non-peak has little to do with 95th percentile. Assuming that every day's traffic patterns are the same (which is rarely true, there is almost always a weekend/sunday difference), 95th percentile removes the top 1 hour 12 minutes from each day's peak. This is more then enough time to piss off your customers if they all hit the peak together and congest your network. If you really wanted to motivate customers to not all burst above what you have provisioned, you would charge them a "bursting fee". Personally I am of the philosophy that it is easier to build your network right. With the availability of cheap dark fiber, cheap wdm gear, and "carrier neutral exchange points" like PAIX and Equinix, the problem of "Oh crap my OC12 is full during peak times, it will be another 6 months before the telco can get me another one and it will double my operating costs" can be worked around. If you build a good network which is really scaleable, bursting costs you nothing. If you can pass the savings on to customers, while giving them a solid network, you will get more customers who WANT to push traffic. Pushing traffic leads to billing, which leads to money (usually). -- 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)

3 2

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