- NANOG - lists.nanog.org

Determining ownership of Internet routing problems
by kenw＠kmsi.net 06 Dec '03

06 Dec '03

I am a little hesitant to post this here, as it comes from the perspective of a user (albeit not a lay user). However, I believe the issue is very much one for service providers. Although it has been previously discussed on comp.protocols.tcp-ip, I have yet to determine whether there is a clear answer, let alone what it is. If I am posting inappropriately, feel free to tell me so. -------------- I had an... "interesting" problem a little while ago. I couldn't reach my mail server, and I couldn't tell who was responsible. The problem appeared to be a routing loop somewhere between my connectivity ISP and my hosting ISP. I talked to the connectivity ISP, and they said the router was outside of their network and run by someone they had no contract with. The hosting ISP said essentially the same thing. Now, I realize that dynamic routing means that there's no real way to predict the path a given packet will take. But I had somehow thought that the contractual arrangements between ISPs and their backbone providers would mean that there must be service agreements between everyone on the path between two points, and that if a link failed, there was a path of contractual responsibility. E.g. [backbone provider] / \ [intermediate A] [intermediate B] / \ [ISP A] [ISP B] where (say) ISP A is the connectivity provider, and ISP B is the hosting provider. So if I can't reach ISP B, either ISP A or B should be able to talk to his upstream provider and get it fixed. Now I'm wondering if that is even a valid assumption. Maybe the truth is more like this: [backbone provider A] [backbone provider B] / \ / \ [intermediate A] [intermediate C] [intermediate B] / \ [ISP A] [ISP B] and if the problems is with intermediate C, I'm probably SOL. Clearly, I would want my ISP to insist that his upstream providers not allow such unreliable topologies to be used. So, my questions are, am I asking too much? Am I misunderstanding the real world of the Internet? And am I posting in the wrong forum? /kenw Ken Wallewein CDP,CNE,MCSE,CCA,CCNA K&M Systems Integration Phone (403)274-7848 Fax (403)275-4535 kenw(a)kmsi.net www.kmsi.net

2 1

Need Contact at RoadRunner
by Tom (UnitedLayer) 06 Dec '03

06 Dec '03

I need to speak with someone at RR about blocking issues. Apparently they've decided to block mail from Apache.org and some of our other customers without any notice to UL. I've followed their instructions and e-mailed the listed addresses, I've waited quite a while (over 24 hours) and have yet to be contacted with information about why we were blocked. UL is very responsive to abuse issues, so this is a little concerning. Please contact me or the NOC. Thank You --- Tom UnitedLayer Office: 415-294-4111 AS23342

8 17

Large Cable ISP Looking for a Roadrunner contact...
by Dan Ellis 05 Dec '03

05 Dec '03

Hello, Could someone from Roadrunner please contact me - you have blocked a large ISP's mail server farm and are not responding to requests to unblock. We received no notification of a block. Thanks --Dan -- Daniel Ellis, CTO, PenTeleData (610)826-9293 "The only way to predict the future is to invent it." --Alan Kay

3 2

Evolution of the U.S. Peering Ecosystem v1.1
by William B. Norton 05 Dec '03

05 Dec '03

Hi all - Thanks to those who provided comments to the last white paper draft of "The Evolution of the U.S. Peering Ecosystem". I've made most of the changes and added the data points as suggested, so I am now ready to send out the document more broadly. Lots of acknowledgements in the acknowledgements section now - Thanks!! In a nutshell, the Evolution of the U.S. Peering Ecosystem introduces the notion of the Internet as a set of Regional Peering Ecosystems, each with its own - Tier 1s (who have access to the entire regional routing table solely through peering relationships), - Tier 2s (broadly all other ISPs), and - Content Providers These players are modelled with characteristics (upstream transit links, peering links, etc.) and their motivations (described as Peering Inclinations (Open, Selective, Restrictive, or No Peering) articulated in Peering Policies) that can predict roughly their behavior in the Peering Ecosystem. The "Evolution" of the U.S. Peering Ecosystem is the result of five forces: 1) The so-called dot.bomb - economic collapse of the telecom sector 2) The emergence of a large scale used equipment market 3) The exponential growth of Kazaa traffic costing eyeball networks $$$$ 4) The failure of @Home - cable companies provide Internet services themselves 5) The rapid decline in transport and transit prices The three major changes roughly are: 1) The Cable companies are peering (with Tier 2s and each other) in a *big* way 2) The Large Network Savvy Content Companies are getting into peering in a *big* way 3) The Large Network Savvy Content Companies are getting their content directly onto the Cable companies eyeball networks by peering relationships. These are significant changes due to the volume of traffic exchanged, the amount of money being saved by avoiding intermediary transit providers, and the performance implications of these direct connections. As promised, if you are interested in this stuff I will gladly send you a copy of the latest draft, v1.1. I'm working on the same exploration for the Asia Pacific Peering Ecosystems (hence the APRICOT Peering Track note I sent out earlier this week). Hope this helps - Bill

2 1

RE: Large Cable ISP Looking for a Roadrunner contact...
by Dan Ellis 05 Dec '03

05 Dec '03

As per their bounceback instructions, tried removal(a)security.rr.com, it appears still blocked. -- Daniel Ellis, CTO, PenTeleData (610)826-9293 "The only way to predict the future is to invent it." --Alan Kay -----Original Message----- From: Suresh Ramasubramanian [mailto:suresh@outblaze.com] Sent: Friday, December 05, 2003 6:13 PM To: Dan Ellis Cc: nanog(a)merit.edu Subject: Re: Large Cable ISP Looking for a Roadrunner contact... Dan Ellis writes on 12/5/2003 6:05 PM: > Could someone from Roadrunner please contact me - you have blocked a > large ISP's mail server farm and are not responding to requests to > unblock. We received no notification of a block. > > Thanks > > --Dan > Doesn't spamblock(a)security.rr.com work? srs > -- > > Daniel Ellis, CTO, PenTeleData > > (610)826-9293 > > "The only way to predict the future is to invent it." > > --Alan Kay > -- srs (postmaster|suresh)(a)outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations

1 0

Peering BOF VII at NANOG 30 in Miami
by William B. Norton 05 Dec '03

05 Dec '03

Hi again - We have approval to run the Peering BOF again at the upcoming NANOG 30 in Miami ! Appropriate attire (Hawaiian Shirts) is required ;-) So, now my job is to draft Peering Coordinators to stand up, introduce themselves, say a few words about their peering requirements, why you should peer with them, etc. in order to facilitate peering. While you introduce yourself I will have a screen behind you that has the answers to the questions below. At the end of the BOF we break for beers and, if history is any indication, peering coordinators meet each other, exchange cards and get some direct peering going. BTW - This time we may add an agenda topic, perhaps a brief debate "Tier 1 Peering Policies: Defensible?". Taking the Affirmative will be _______, taking the Negative will be ______. (Both TBD, debaters being secretly solicited) Bill --------------- For Peering Coordinators participating in Peering Personals --------------- The Peering BOF focuses on meeting other Peering Coordinators using a methodology we call "Peering Personals." We solicit Peering Coordinators (before the meeting), asking them to characterize their networks and peering policies in general ways ("content heavy" or "access (eyeball) -heavy," "Multiple Points Required" or "Will Peer anywhere," "Peering with Content OK," etc.). From the answers we will select a set of ISP Peering Coordinators to present a 2-3 minute description of their network, what they look for in a peer, etc., allowing the audience to put a face with the name of the ISP. At the end of the Peering BOF, Peering Coordinators will have time to speak with Peering Coordinators of ISPs they seek to interconnect with. The expectation is that these interactions will lead to the Peering Negotiations stage, the first step towards a more fully meshed and therefore resilient Internet. If you are a Peering Coordinator and wish to participate in this BOF, please fill out the following form and e-mail it to wbn(a)umich.edu with Subject: Peering BOF VII We will only be able to accommodate maybe 20 peering coordinators this time so please RSVP early! --------------------------------------------- clip here ------------------------------------------ Name: Title: Company: AS#: Check each that applies: ___ We are an ISP (sell access to the Internet) -- OR -- ___ We are a Non-ISP (content company, etc.) ___ We are generally more Content-Heavy -- OR -- ___ We are generally more Access-Heavy ___ Peering with Content Players or Content Heavy ISPs is OK by us ___ We generally require peering in multiple locations ___ We will peer with anyone in any single location ___ We have huge volumes of traffic (lots of users and/or lots of content) (huge: > 1 Gbps total outbound traffic to peers and transit providers) ___ We have a global network ___ We require Contracts for Peering List all Current Peering Locations: 1) 2) 3) : List all Planned (3-6 mos) Peering Locations: 1) 2) 3) : Privacy Notice: This information is made available only to me, William B. Norton, as an individual, and will be used only for facilitating the BOF and making up the screen behind the speakers. People in the audience are certainly welcome to jot down information presented at the BOF, but the information will not be made available in any other form to anyone. Hopefully this clarifies things and will avoid the controversy of the past. To give you an idea of previous Peering BOFs please see ------------------------------------------------------------------------------- Peering BOF VI, NANOG 27, Phoenix, February 2003. http://www.nanog.org/mtg-0302/norton.html Peering BOF V. NANOG 25, Toronto, June 2002. http://www.nanog.org/mtg-0206/norton.html Peering BOF IV. NANOG 23, Oakland, October 2001. http://www.nanog.org/mtg-0110/norton.html Peering BOF III. NANOG 20, Washington, DC, October 2000. http://www.nanog.org/mtg-0010/peering.html Peering BOF II. . NANOG 19, Albuquerque, June 2000 http://www.nanog.org/mtg-0006/peering.html Peering BOF I. NANOG 17, Montreal, Oct 1999 http://www.nanog.org/mtg-9910/peering.html

1 0

Does your Certifying Authority have a clue who you are? Do they care?
by Bob Beck 05 Dec '03

05 Dec '03

So, an interesting thing happened to me yesterday. I run OpenBSD's https.openbsd.org site. Of course, we have an SSL Site certificate for this site. When we first started the site, (about 6 years ago) we got a site certificate from Thawte. Back in these days they were based in South Africa, and had a Canadian Legal firm to verify who we were. So of course, Theo had to fax them some stuff, as did I. etc. etc. The whole process was rather painful, particularly since "OpenBSD" isn't a company, so we couldn't exactly send incorporation documents and the like. Nevertheless, supposedly this is to provide some sort of protection for people - that "OpenBSD" really is who it claims to be. So, time comes to renew the certificate again, and give Thawte their bi-yearly sum to keep our server cert alive. Every other year, the renewal process has been automatic, They already have our documentation on file so presumably they can and do check this. This year, they know nothing, They have been bought by verisign and they want new documentation. The conversation went something like this: <"What happened to our previously sent documentation?" >"It's in a warehouse in Canada, because we changed how we do things" <"Why can't you get it from there - We're a multinational volunteer organization, coming up with any sort of stuff like this is a pain" >"Well, we can't". <"So you've lost it?" >"No, we know where it is, it's in the Warehouse" <"Well, you can't get it because you don't know where it is in the Warehouse" >"Yes, so what can you send us?" <"Are you going to get the documents from Canada?" >"Yes, but we're not sure when or how?" So the long and the short of it is, our CA has *LOST* the documents showing who we are, and wants new ones. Had someone previously filed fraudulent documents to obtain an ssl certificate, they wouldn't have copies of those. So, the real question is, what good does it do to send supporting documentation to these services, if all they do is lose them? Is this really providing anyone with any security, or is this really just a thinly veiled revenue generation procedure. If they can't even produce the documentation used to support a certificate they've issued, then why the heck ask for, and charge money for this in the first place? Of course my certificate is good for X years, not to protect me from my cert being exposed, but just to get more money after X years. Certificate revocation? Who actually uses that, for real, in a manner that any widespread public apps (i.e. web browsers) will pay attention to? Needless to say, any real confidence I (used to) have in Thawte (back when it made Mark Shuttleworth enough money to buy a ride on the space station) is really no more. (And no, I never really did have any confidence in https, because of the human engineering issues) Anyway, we got a new cert from a provider that only cares about domain ownership, which works fine. The real question is, between the fact that the web browsers makes it so easy for knuckle dragging apes to accept any certificate out there anyway, and if the CA's aren't doing anything to speak of with the "Supporting Documentation", Who are we kidding that there's any real point (security wise) to this exercise? Time for a new protocol that just stores the public key the first time like SSH, and the user maintains their own list? Really, is that any less secure than this ongoing nonsense from a practical perspective? (Other than there's no way for CA's to make money off of it?) -Bob

10 17

Always renew your domain names
by Mike Hyde 05 Dec '03

05 Dec '03

Looks like someone forgot to renew there domain name and another party decided to do it for them, with some slight changes: host 206.108.102.93 93.102.108.206.in-addr.arpa domain name pointer bells-network-has-lots-of-security-holes-to-exploit.bell-nexxia.net

6 6

New Statistics Format Released
by Ginny Listman 05 Dec '03

05 Dec '03

ARIN has been working along with APNIC, LACNIC and RIPE NCC to provide number resource statistics in a unified format and location. The following changes will be made to the existing statistics reporting: - Addition of IPv6 allocations - Report generated daily - Summary lines are included - Reports are signed with GPG key - MD5 hash is provided for verification - Minor changes in format We understand that many researchers have scripts that pull these reports on a regular basis and/or perform analysis based on the current format. To facilitate the change and acceptance of the new format, ARIN will run the old and new format from now until January 5, 2004. We have also included a README file in the directory defining the new format. During this time period the location of the stats will be: Current format: ftp://ftp.arin.net/pub/stats/arin/latest New format: ftp://ftp.arin.net/pub/stats/arin/new/delegated-arin-latest On and after January 5, 2004, the only set of stats will be located at: ftp://ftp.arin.net/pub/stats/arin/latest Comments concerning the publicly released statistics can be addressed on the ARIN DBWG mailing list. A mailing list description and subscription information can be found: http://www.arin.net/mailing_lists/index.html Ginny Listman Director of Engineering ARIN

1 0

Re: Does your Certifying Authority have a clue who you are? Do they care?
by Michael.Dillon＠radianz.com 05 Dec '03

05 Dec '03

> So the long and the short of it is, our CA has *LOST* the >documents showing who we are, and wants new ones. Wow! Have you contacted http://www.geotrust.com about this? I'm sure they would fly people out to Calgary to personally inspect your identity at no charge just for a chance to use your story in the marketing. Check what they're saying about Verisign on their website. The bumbling fools at Verisign are not the only choice for SSL certs. The security ecology demands diversity and competition so that there are always plenty of watchers watching the watchers. --Michael Dillon

1 0