- Test - lists.nanog.org

RE: Current street prices for US Internet Transit
by William B. Norton 18 Aug '04

18 Aug '04

First - As for whether the US Transit market is healthy or unhealthy... I am not privy to the ISP calculations that demonstrate financial viability at these prices, so I can only go on the sentiments expressed by folks that have done the analysis for their companies and have shared their views with me or my colleagues. Having said that...It certainly appears that the majors can't make money in this transit market, and they would probably say that the bottom feeders are greasing the skids to financial ruin for this industry. At 08:50 PM 8/16/2004 -0700, Michel Py wrote: >The really interesting question IMHO is this: does said content company >also peers, or just buys transit? I read in Bill Norton's papers that a >content company is a good candidate to peer with large tier-2s. Well, it is the *large* network-savvy Content Guys that I see peering quite a bit of their traffic. For these guys the motivation seems to be the performance benefits (it is all about pages coming up fast, end user behavior stuff), but the financial savings isn't far behind. FOr these guys the savings are still in the millions per annum. And these are the guys that do enough volume to negotiate transit prices in the teens. > > The Cost of Internet Transit in.. > > Commit AU SG JP HK USA > > 1 Mbps $720 $625 $490 $185 $125 > > 10 Mbps $410 $350 $150 $100 $80 > > 100 Mbps $325 $210 $110 $80 $45 > > 1000 Mbps $305 $115 $50 $50 $30 > >Someone mentioned that this was comparing apples to oranges. Indeed it >is, <stuff deleted> I would disagree that these are apples and oranges comparisons - these are real prices (normalized to USD) for transit that someone in the country would pay to access the big 'I' Internet. The Peering Coordinators I spoke with that have expanded into these markets did point out that each Peering Ecosystem differs - I think I documented about 10 differences in the Asia Pacific Peering Guidebook - but, ultimately, they will need to buy transit in that market. So these numbers are useful for budgeting for network expansion into Asia. I would also share that the local loop prices in these other markets vary widely ; an OC-3 local loop in Singapore may be twice the cost of a distance insensitive OC-3 local loop in Hong Kong. To that end, the business cases for peering will be quite different. Bill

5 4

New list: ddos-fighter
by Nicolas FISCHBACH 17 Aug '04

17 Aug '04

Hi all, We would like to announce a new mailing-list: ddos-fighter(a)securite.org This list has been created to enable owners and users of DDoS detection and mitigation devices (*) at ISPs/NSPs to discuss architecture and deployment, share tips, filtering templates, experience and operational models, etc. To subscribe send a mail specifying: who you are (ASN/company, position/job desc., Internet security references - if any) and which product(s) [detection and mitigation] you use AND are willing to discuss/share experience on (no lurkers, no marketing, no sales, etc) to: ddos-fighter-subscribe(a)securite.org We may ask you to "prove" that you actually own and operate such devices. If you have any question or feedback: nico(a)securite.org This list is not for real-time DDoS mitigation and inter-SP coordination, for this please see nsp-sec: http://puck.nether.net/mailman/listinfo/nsp-security Most of the nsp-sec charter applies to this list too. Also, note that the list is currently not "public" (as opposed to cisco-nsp or juniper-nsp for example). (*) Arbor Peakflow, Cisco(/Riverhead) Guard, Mazu Profiler/ Enforcer, TopLayer IPS, Captus IPS, TippingPoint Unity, etc. Things like ACLs and blackholing don't count :) Nico. -- Nicolas FISCHBACH (nico(a)securite.org) <http://www.securite.org/nico/> Senior Manager - IP Engineering/Security - COLT Telecom Securite.Org Team - http://www.securite.org/

2 1

Re: Summary with further Question: Domain Name System protection
by sthaug＠nethelp.no 17 Aug '04

17 Aug '04

> > this should be pushed to > > the router. don't waste CPU cycles > > on the Nameserver. > > Hosts tend to be a faster writeoff cycle than routers in companies I've > worked at, therefore getting the benefit of moores law about 25% faster > than the routers. Turn on firewalling in the host. If you have a choice between access lists on a software forwarding based router and firewall on a host, this may be a good choice. If your routers have hardware forwarding, I'd go for the router every time... Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

2 1

Re: SYN flood attacks? [Virus Checked]
by Brent_OKeeffe＠asc.aon.com 17 Aug '04

17 Aug '04

I think I also heard about some new email worm that takes advantage users that open attachments... (Sorry, just HAD to jump on that bandwagon) Brent Richard A Steenbergen <ras(a)e-gerbil.net> Sent by: owner-nanog(a)merit.edu 08/17/2004 02:41 PM To: jgraun(a)comcast.net cc: nanog(a)merit.edu Subject: Re: SYN flood atacks? [Virus Checked] On Tue, Aug 17, 2004 at 06:28:55PM +0000, jgraun(a)comcast.net wrote: > I have been hearing rumors about some SYN flood atacks on the Internet > today. Anybody hear anything? Interesting coincidence, I just heard a rumor about someone receiving spam today. Perhaps the are connected. It might even be a conspiracy. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

1 0

SYN flood atacks?
by jgraun＠comcast.net 17 Aug '04

17 Aug '04

I have been hearing rumors about some SYN flood atacks on the Internet today. Anybody hear anything? Thanks Jason

3 2

Re: Summary with further Question: Domain Name System protection
by sthaug＠nethelp.no 17 Aug '04

17 Aug '04

> What I'm not sure about ACL on router is, how to > survive DNS server under DoS/DDos attack. We suffered > from DoS attack last year, and we found the source IPs > of that attack locate in our customers IP address > blocks. ACL on router could only filter those traffic > not meaningful to DNS server, but how about those DDoS > attacking packets? Your router can presumably rate limit the traffic towards the name server to a level the name server can handle. On the name server you can perform further rate limiting on an IP address basis, with for instance FreeBSD ipfw. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

Re: Summary with further Question: Domain Name System protection
by sthaug＠nethelp.no 17 Aug '04

17 Aug '04

> 1. ISPs use firewall to protect their DNS server; Depends. You don't normally need a full fledged (stateful) firewall. Normal (stateless) router access lists are just fine. > 2. ACL on router may be a good solution for protecting > DNS servers, the policy could be "only pass those > packets, whose originate from incustomers' IP address > blocks and destinate to UDP port 53 of DNS server"; In general, allow only relevant traffic. That may be a bit more than just UDP port 53: You really want to allow TCP based DNS queries also, and your name server probably needs SSH, NTP and similar. > 5. 'bogon'in BIND configuration could be used to > filter requests from RFC1918 address; Better to do it on the router. > 6. Firewall may become bottleneck of DNS server farm > in situation of DoS attack or situation of high > session rate; Routers with hardware based access lists. No problem. > b) Is there any public available performance > evaluation on Nominum's product? See Brad Knowles' tests: http://www.ripe.net/ripe/meetings/archive/ripe-44/presentations/ripe44-dns-… We currently have the Nominum CNS on trial here, and we are very impressed. It performs much better than BIND 8/9 - our measurements show even greater differences than Brad Knowles' tests. Example: One server running BIND 9 shows more than 30% CPU usage during peak hours, but only 2-3% with Nominum CNS. We also have the issue that BIND 9 seems to start *failing* when it reaches a certain cache size (as in: Some queries are either not answered at all, or they are answered with SERVFAIL). Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

2 1

Re: Verisign vs. ICANN
by Paul Vixie 17 Aug '04

17 Aug '04

> Anything I/we can do to help the cause? not at the moment. i'm not a defendant, just a named co-conspirator.

15 23

RE: Current street prices for US Internet Transit
by Michel Py 17 Aug '04

17 Aug '04

> William B. Norton wrote: > Three said that these transit prices were TOO LOW, in > one case they paid about double these numbers. It was > interesting that these three were a content company, The really interesting question IMHO is this: does said content company also peers, or just buys transit? I read in Bill Norton's papers that a content company is a good candidate to peer with large tier-2s. And, an even more interesting question is: if said content company does peer, what kind of price would they be available to negotiate with their transit if they stopped peering and stick to transit-only? > Given the adjustment, I thought you might be interested > in how the U.S. transit prices compare against a handful > of other Peering Ecosystems: > The Cost of Internet Transit in.. > Commit AU SG JP HK USA > 1 Mbps $720 $625 $490 $185 $125 > 10 Mbps $410 $350 $150 $100 $80 > 100 Mbps $325 $210 $110 $80 $45 > 1000 Mbps $305 $115 $50 $50 $30 Someone mentioned that this was comparing apples to oranges. Indeed it is, but nevertheless remains extremely interesting as related to a thread we had earlier about regional differences in P2P. The way I see things, we are greatly unequal depending on where we live. However, I have theorized the following thoughts that I would like to run by the list: <me puts the asbestos suit on> No matter where you leave, the deal you get as a hard-core swapper (remember, we're talking about P2P now) is about what it costs to buy or build transit in bulk. The operator/provider makes no profit out of hardcore swappers, just tries not to loose money. In other words: in Australia, an unlimited and unmetered megabit residential link will cost hundreds of dollars, which is about the transit cost. In California, I pay $36.99/mo for 2.5 mpbs unlimited unmetered, which is also about the transit cost. </me puts the asbestos suit on> > one can pick up a used 7500 series router equipment > now for about $9K ! The configuration was with an OC-3, > and FastE for peering, for about 25% of the new cost Sounds like a lot of money to me for a 7500; if this is the eBay cost only it's more around $3.5k I would say. For $9k one could get a 12008. OTOH if it includes re-licensing and some support it sounds about right. > Deepak Jain wrote: > Other than packet buffer depths and some theoretical ACL > limits, is there any reason why a 7600 network would be > worse than a 12000 built one? <me owns a few Cisco shares> There is one: Cisco wants you to buy 12000s. Don't expect them to make it easy to run the same network on 7600s :-) </me owns a few Cisco shares> That being said, what you mention is probably why you find 12000s for peanuts on eBay..... > Patrick W Gilmore wrote: > and I honestly do not believe that every network is > selling below cost. No, but there are enough to do it that the other ones are not too far behind. Economics 101: low prices mean there is more supply than demand, which also means that either the demand has to grow or the supply diminish. A common strategy is to sell at loss to capture a better/significant market share, which will ensure that the taxpayer and shareholders will pay the bankruptcy bill, as the disruptions caused by disappearance of a large fish are even more costly. Michel.

1 0

New IANA IPv6 allocation for RIPE NCC (2001:4600::/23)
by Doug Barton 17 Aug '04

17 Aug '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, This is to inform you that the IANA has allocated the following one (1) IPv6 /23 block to the RIPE NCC: 2001:4600::/23 RIPE NCC For a full list of IANA IPv4 allocations please see: <http://www.iana.org/assignments/ipv4-address-space> - -- Doug Barton General Manager, Internet Assigned Numbers Authority -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBIVY/wtDPyTesBYwRAi8/AJ44TNst0AM4xqOHDXZcmo+rCqOP1QCbBR0g zhtl1VzZ7/2W7luxyN/b/NU= =5pBC -----END PGP SIGNATURE-----

1 1