June 2001 - Test - lists.nanog.org

RE: engineering --> ddos and flooding
by Matt Zito 04 Jun '01

04 Jun '01

> -----Original Message----- > From: Richard A. Steenbergen [mailto:ras@e-gerbil.net] > Sent: Monday, June 04, 2001 3:09 PM > To: Matt Zito > Cc: Paul Johnson; nanog(a)merit.edu > Subject: RE: engineering --> ddos and flooding > > 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 > Well, what I said is inaccurate for SOME operating systems. A default linux box today still has a 128-syn queue. Unless you enable syn cookies, you're screwed - I haven't checked BSD or Solaris for slow-syn behavior recently. Syn cookies also aren't a magic bullet - you lose TCP options that some people really want/need. And rate-limiting SYN is still a bad idea - if you rate-limit to a certain bandwidth, either your server will not be able to handle the incoming syns and will stop responding, or legitimate incoming traffic will hit the floor because the queue on the router is full (or approaching full and RED is invoked) and legitimate incoming requests will be dropped. This might be okay for places where one server performs many functions - i.e. the box is still available on other ports, but in larger infrastructures, a box generally has one purpose, and if its purposed port is down, the box might as well be turned off. So, I prefer solutions that negotiate the connection before passing it back to the host - like (insert basically any firewall product here). Some do it better than others, of course - the netscreen 100, 500, and 1000 seem much better than anything else the field has to offer. Thanks, Matt

2 1

C&W Peering
by Moe Allen 04 Jun '01

04 Jun '01

Affective this morning Cable & Wireless started de-peering with PSINET. More when I receive a reply from: peering.admin(a)cwusa.com Morris Allen VidcomNet, Inc.

1 0

Re: engineering --> ddos and flooding
by Paul Johnson 04 Jun '01

04 Jun '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. 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) e.e if I'm have a circut from C&W nd I try to spoof a packet eith a source address of 216.35.172.135 it should be dropped as close to the edge of C&W's network as possible. note on RFC 1918 addresses: These should never get past customer edge routers IMESHO. 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.] Three NSPs should lock down their gear so it can't be used for DoS amplification. I mean a clueless customer getting burned is one thing but we should expect & demand more from NSPs. [note: my primary responsiblity in life is security not networking.I know just enough networking to be dangerous and annoying to our Networking dept. :-) ] On Mon, 4 Jun 2001, Geoff Zinderdine wrote: > > Assuming not adding the extra connection, this means that upstream > > prefix filtering, so that one can't mistakenly inject 255 /24s > > rather than a single /16, would go out the window. Now think about > > /32s and what the routing tables will start to look like. Now > > onsider that the upstream would also want to send to its upstream > > Tier-1 the NULLROUTE /32 as well so that his bandwidth is not eaten > > up as well and we have asituation whereby routing table size will > > triple in size every year. > > This is a stop gap measure for customer networks. Those null routed > /32s are not meant to be permanently advertised, they are meant to > free the customer's pipe from smurf/fraggle until the SP can do > something about it. What would be the point of permanently > blackholing a host on your network? One more problem...what if your mail/web server is the target of the attack you have just taken that resource effectively off-line. No need to continue the DoS you've done the work of the attacker. > I would imagine that most tier 1's are going to filter anything longer > than a /24 whether you advertise it or not. The question isn't about > route table size, it is whether your SP will go the extra mile to give > you a proactive option to deal with attack and has someone clueful to > implement it that will take responsibility for it (not that it is > hard). > > This is a very limited measure that only helps in a very particular > situation for a small subset of customer networks. I think it is a > very useful tool for that particular situation... it is not meant as a > principle that SP networks should apply to their upstream as well. Paul Johnson Ratoath, Co. Meath Republic of Ireland - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: pgpenvelope - http://www.uiuc.edu/ph/www/ftobin/resources.html iD8DBQE7G7QUEn8vUhkIGTURAuuFAJ0Ub5lBQWG4r/WisSOTaOPNPm0/nACg8fY3 qcEayLo0vyDGlVDSFbWMKlE= =K9Xz - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: pgpenvelope - http://www.uiuc.edu/ph/www/ftobin/resources.html iD8DBQE7G7VeEn8vUhkIGTURAkd3AJ48V+C40i0noy+kij4xi470yly6WwCfT1UX o9Eq24paIFAJsSAU7JvuqNw= =D2SE -----END PGP SIGNATURE-----

4 3

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