- NANOG - lists.nanog.org

Next NANOG meeting
by Susan Harris 04 Jun '01

04 Jun '01

Hi everyone - I'm pleased to announce that the next NANOG meeting will be held October 21-23 in Oakland CA, and will be hosted by Cisco. You'll find more information in the NANOG23 Call for Presentations: http://www.nanog.org/mtg-0110/call23.html http://www.nanog.org/mtg-0110/call23.pdf Registration begins in early August. See you this fall! --Susan Harris

1 0

95th Percentile again (was RE: C&W Peering Problem?)
by Richard A. Steenbergen 04 Jun '01

04 Jun '01

On Sat, Jun 02, 2001 at 05:19:16PM -0500, Albert Meyer wrote: > > I almost got caught by this one a few months ago. I was fixing to sign > a contract with Exodus for a 100bT circuit when I noticed some > funny-looking language and asked some probing questions, and then > realized that I had to double their quoted rates before comparing them > to everyone else. This moved them from the front of the pack back to > UU-land. > > UUNet is another story. They not only charge significantly more than > everyone else, but they calculate 95th percentile on the higher of > incoming and outgoing rather than the average. When I asked my > salesperson why she couldn't give me a competitive rate, she said > "Because we're UUNet." She seemed pretty taken aback when I explained Exodus is the worst on billing bit for bit. The way I read the Exodus 95th percentile document (though I still havn't gotten it confirmed by a person who actually knew what they were talking about), they bill for the MAXIMIUM 95th percentile, on both inbound AND outbound. 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. But a significant portion of other networks will bill for the AVERAGE under the 95th percentile. I think the MAXIMIUM is unclear to a lot of people, especially the sales people if you try to get a straight answer out of them. When most people refer to the UUNet "95th percentile", this is what they mean. You take traffic samples, line them up in order, lop off the top 5%, and whatever the number is for the sample right under that is what gets multiplied by the cost per mbit. This means that if you push 1Mbps for 25 days and 10Mbps for 5 days you will pay 10 * $$$ per mbit. Average means you will pay 2.5 * $$$ per mbit (((1 * 25) + (10 * 5)) / 30), obviously a major difference. A LOT of sales people are misleading or utterly clueless about this, and a lot of providers actually WILL bill you for the AVERAGE under the 95th percentile (though if you think about it the 95th percentile makes little sense if you average it, it was designed to extract the maximium amount of money while not making people utterly afraid to burst higher). Moral of the story, check for those words "AND" vs "OR", and "MAXIMIUM" vs "AVERAGE", ask for their boss and check it again, and then get it in writing. :P -- 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)

18 55

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