- Test - lists.nanog.org

Re: Sprint peering policy
by Ukyo Kuonji 02 Jul '02

02 Jul '02

>From: Clayton Fiske <clay(a)bloomcounty.org> > >Nor does it cost $0 on top of that $200 to buy transit. But, looking at today's $/bit ratio, peering is not a big of a monetary beneift as it used to be. BAck when you only needed a DS3 to the naps for peering, and transit cost $1200 a megabit, peering was a great cost savines. Today, it is almost a wash, and sometimes more expensive to peer that to just buy transit. When you can arrange transit contracts to be as low as $50 a megabit, and to sit in a PAIX facility costs you $150K for the router, plus $7K a month for rack and power, and monthly costs for your OC-48 into the router... What's the true cost of peering? An OC48 to PAIX, and let's say you serve all your traffic needs from there, and ignore connection charges, or an OC48 to a transit provider at $50 a meg? I'm pretty sure that the peering model does not hold up as well as it should. Now... Do I believe that there is added benefit to peering? Yes, of course, but not nearly what it used to be. If it's a benefit to your customers, and helps increase your number of customers, then it may still be a good thing. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com

9 9

Ebone going off the air (at last)...
by Lars Erik Gullerud 02 Jul '02

02 Jul '02

Yes, I realize this is NANOG and a lot of people here doesn't seem very interested about events over in Europe, but for those who might be interested and have not already seen this: http://nocpeople.org/ebone/broadcast2.html >From what I can see personally, all BGP sessions with Ebone at major peering points in Europe went down in the last two hours, and all their customer interfaces appear to be shut (or in the process of being shut down). SDH and DWDM customer circuits are also being torn down as we speak. Note, this is only the Ebone part of the bankrupt network, not the KPNQwest part. So, guess it's time to finally wave goodbye... -Lars Erik

1 0

RE: Sprint peering policy
by Grant A. Kirkwood 02 Jul '02

02 Jul '02

At 09:54 PM 7/1/2002 -0400, Phil Rosenthal wrote: >My math shows ~500bps per US citizen: >Assuming 150,000,000,000 bits and 280,000,000 citizens. This also assumes US citizens don't sleep. -- Grant A. Kirkwood - grant(at)tnarg.org Fingerprint = D337 48C4 4D00 232D 3444 1D5D 27F6 055A BF0C 4AED

3 2

RE: AOL mail netblocks
by Daniska Tomas 02 Jul '02

02 Jul '02

what the second line is for? if i block all first then why care about rest (which equals to none in such case) :) -- Tomas Daniska systems engineer Tronet Computer Networks Plynarenska 5, 829 75 Bratislava, Slovakia tel: +421 2 58224111, fax: +421 2 58224199 A transistor protected by a fast-acting fuse will protect the fuse by blowing first. > -----Original Message----- > From: Martin Hannigan [mailto:hannigan@fugawi.net] > Sent: 2. júla 2002 14:40 > To: nanog(a)merit.edu > Subject: AOL mail netblocks > > > > > Folks, is there still only a certain block of allowed addresses > that send mail from AOL i.e. block smtp from any any and then allow > 1.2.3.0/24 etc? > > Thanks, > > -M > > > > Regards, > > -- > Martin Hannigan hannigan(a)fugawi.net > Boston, MA http://www.fugawi.net > >

2 1

AOL mail netblocks
by Martin Hannigan 02 Jul '02

02 Jul '02

Folks, is there still only a certain block of allowed addresses that send mail from AOL i.e. block smtp from any any and then allow 1.2.3.0/24 etc? Thanks, -M Regards, -- Martin Hannigan hannigan(a)fugawi.net Boston, MA http://www.fugawi.net

1 0

Speaking of taking down the internet
by blitz 02 Jul '02

02 Jul '02

Just a FYI folks....from one of the hacker lists I'm on... >Speaking of taking down the internet > > > Extra points for only needing to affect one device and having that device > > successfully spread the payload to every other device as a part of it's > > routine network communications. Think you can't cross boundaries between > > different chipsets as implemented by different vendors (i.e. Cisco exploit > > code which wouldn't presumably work on Foundry gear)? Think again. Think > > polymorphic multi-architecture assembly. Think stuff that we were doing for > > fun in a hotel room at Defcon two years ago. > >Heh. That's fucking evil, Dan. That's completely fucking evil. I like it. >The only problem I can see with it is that it'd take a lot of space. >Routers are tight on how much you can fit into 'em, and I think you'd >stand a good chance at setting off an alarm somewhere by adding that much >code. But maybe not... you could even store the code remotely... have your >evil router 'upgrade' it's neighbors. But then you might get caught by an >IDS system. Probability is low on that happening, though. Needle in a >haystack. > >How about using the same plan, except instead of just making the routing >infrastructure go dead, how about spicing it up a little and have it go >after the root DNS servers? Thousands of devices on the backbone stuffing >a DoS down an OC192 circuit at 9.6 Gigs per second would certainly have >folks confused, I'd imagine. Especially if you spoofed the source >addresses. > >Every time they trace the attack back to the other side of yet another >router, it looks like the problem is further away. People would be >completely mystified. Traffic coming from the routers would just look like >traffic coming from something on the other side of the routers. And it >would be... each router would be generating (and routing) a huge attack. >And as pretty much all communication would be down, even if a couple folks >figured it out, they'd have no easy way to spread the word of what was >happening. Although I'm sure it would certainly hit the news. > > > Having said all of that, it's a cool (in the sense of being skillful) > > attack against the Global Data Network, but hardly the easiest. It would > > probably cost lots less overall to just crash something big or something > > that goes boom over at Verisign and/or some places in the EU. I'm sure they > > have plumbing. Computers still don't like water. > >And fiber still doesn't like tractors ;-) Hmmm...? You make the decision if this is relevant...you didn't hear it from me...

1 0

Re: Sprint peering policy
by Andrew Odlyzko 02 Jul '02

02 Jul '02

On Mon, 1 Jul 2002 21:07:06 -0400, Richard A Steenbergen wrote: > It's all so much posturing, just like the people who claim they need OC768 > now or any time in the near future, or the people who sell 1Mbps customers > on the fact that their OC192 links are important. > If there is more than ~150Gbps of traffic total (counting the traffic only > once through the system) going through the US backbones I'd be very > surprised. Several estimates floating around (*) suggest between 60 and 100 PB (petabytes) per month of US backbone traffic, which works out to 180 and 300 Gb/s average traffic. Andrew Odlyzko (*) See my papers at <http://www.dtc.umn.edu/~odlyzko/doc/networks.html>, or a recent (and about to be updated) report from RHK.

2 1

Network Security Requirements draft
by George Jones 02 Jul '02

02 Jul '02

We (UUNET) have an internal document that we've been using for a few years as the basis for tests of security features of equipment to be connected to our backbone. We're interested in making it public so that it can be improved and so that others can use it. You can view the current draft at: http://www.port111.com/docs/draft-jones-netsec-reqs-00.html (HTML) or http://www.port111.com/docs/draft-jones-netsec-reqs-00.txt (text) the overall goal is an improvement in the security features of devices implementing IP. The means that this document tries to provide is a clear definition of security requirements that consumers/operators of networking gear can point to (in RFPs) to say "see, we want security and this is what it means". The current list of requirements is skewed to the needs of large networks (consider the source), but it does provide a means of defining "profiles" for specifying subsets of requirements for different classes of devices (core, edge, ... toasters.). Most of the requirements specify features that are generally implemented today (logging, aaa), though some of the requirements specify highly desirable features that are not implemented in current products (stealthing, monitoring, sampling, etc.) What we're requesting here is feedback network operators and vendors on how to make this document useful in achieving actual improvements in security. Specifically, we're requesting feedback/discussion on: * The requirements listed * Important requirements that are missing * Document structure * How to make it useful. The next step will likely be submission of an Internet draft- c.a. July 2. Input prior to that date stands a much better chance of being included :-) Feel free to reply to me <george(a)uu.net> or reply to the list. Thanks, ---George Jones

3 4

RE: Sprint peering policy
by E.B. Dreger 02 Jul '02

02 Jul '02

EBD> Oversimplifying the model, this works out to ~500 kbps per EBD> US citizen. Allowing for burstiness, I offer 50 GB/mo EBD> transfer as conservative for said bandwidth level. off-list> My math shows ~500bps per US citizen: off-list> Assuming 150,000,000,000 bits and 280,000,000 citizens. Thanks to he who pointed out to me that I cannot correctly work exponents. D'oh! 500 bps and 50 MB/mo using correct math. (I should have questioned any figure that put me at below-average bandwidth usage...) Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist(a)brics.com> To: blacklist(a)brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist(a)brics.com>, or you are likely to be blocked.

1 0

Re: Sprint peering policy
by Miquel van Smoorenburg 02 Jul '02

02 Jul '02

In article <cistron.!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA/zNkI7d3EEmn3+v5DgN/l8KAAAAQAAAADJAemGHjDECnen8+YjBFaQEAAAAA(a)isprime.com>, Phil Rosenthal <pr(a)isprime.com> wrote: >Apples and oranges. Wcom isn't talking about dropping AT&T as a peer, >they just don't want to peer with "Joe Six Pack ISP". Wcom would likely >not peer with most ISPs, and I wouldn't expect them to. They gain >absolutely nothing from it, and the small ISPs gain plenty. Wcom's >costs only increase since they need "more ports". Wcom could peer with "Joe Six Pack ISP" at an exchange if - connection cost is very low (shared ethernet) - they don't peer with Joe's upstream at the same location - they only announce regional routes to Joe - they use hot potato routing everywhere in that case, the peering would just be local/regional, probably all that Joe is after anyway Mike.

6 7