December 2003 - Test - lists.nanog.org

IP Address Management Software Again
by Brennan_Murphy＠NAI.com 08 Dec '03

08 Dec '03

Hi, I'm evaluating IP address management software. Looking for the following: 1) Pointers to online reviews. 2) Views on what is the absolute best package out there. 3) Views on useful free software if it's worth considering. 4) Contact info of sales persons of commerical software. 5) Insights on processes followed to manage addressing. 6) Also specifically looking for software that aids in re-IP-ing portions of a network. 7) Strong views on particular packages that drove you nuts. (offline emails may be best) If I get enough info together, I'll post a follow-up compilation email. I've looked at past threads on NANOG concerning this topic and see only bits/pieces of what I am looking for. Hoping to obtain a more comprehensive set of data. Thanks! -BM

3 2

AOL rejecting mail from IP's w/o reverse DNS ?
by Christopher X. Candreva 07 Dec '03

07 Dec '03

Since I'm 99% sure the idea (or stupidity thereof :-) of blocking SMTP servers without reverse DNS came up here in this discussion, I just ran a manual queue run to clean out a queue, and saw this come up: ... Connecting to mailin-04.mx.aol.com. via esmtp...220-rly-xn05.mx.aol.com ESMTP mail_relay_in-xn5.9; Wed, 03 Dec 2003 09:59:55 -0500 220-America Online (AOL) and its affiliated companies do not 220- authorize the use of its proprietary computers and computer 220- networks to accept, transmit, or distribute unsolicited bulk 220- e-mail sent from the internet. Effective immediately: AOL 220- may no longer accept connections from IP addresses which 220 have no reverse-DNS (PTR record) assigned. >>> EHLO westnet.com I don't know if this is new -- I don't recall seeing it before, but it doesn't say they WILL refuse, just they may. If they do start blocking -- this WILL be an operational issue. ========================================================== Chris Candreva -- chris(a)westnet.com -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/

18 38

Explanation on recently noticed increase of udp 1026-1031 traffic
by william＠elan.net 07 Dec '03

07 Dec '03

The original notice about all this I received came through dshield announce. I followed up the information and thereafter came upon the message on the popadstop website, its rather interesting how they claim they did not intend their software to send a "pop-ad" advertisement of that same software (to random other systems) that is supposedly supposed to block such ads. Of course this was all just a "test" before they start selling their anti-spam software (which would probably act like a mail worm in advertising itself)... http://isc.sans.org/diary.html?date=2003-12-04 "Handlers Diary December 4th 2003 Updated December 5th 2003 06:39 EDT PopAdStop.com Scanning Component For over a week, we had been tracking an increase in port 1026-1031 UDP traffic. More detailed investigation revealed a component in this traffic with the following characteristics: (*) The payload consisted of two zero bytes (*) A large number of sources participated in these scans (*) the scans came from valid IPs, and the source port did not appear to be crafted This is different from most popup spam sent to this port. Most popup spam is sent by only a small number of sources. And usually uses a fixed source port. While popup spam in itself is not any more dangerous then e-mail spam, and more of an annoyance, the large number of sources hinted to the fact that it is likely sent from unsuspecting exploited systems ("Zombies"). The connection with popup spam was made later, by allowing a honeypot to respond to the two byte probe. The result was an ad sent by the probing host. ... The advertised site, "www.popadstop.com" does offer a program for download, which promises to stop future popup spam. We downloaded the application, and installed it in an isolated lab network. During install, the application checks for updates by requesting: www.neweststuff.com/versinfo.dat. Recent version of the application do not show any further outbound traffic. However, earlier version of the application did start to send the typical two zero bytes and popup spam. Summary An earlier version of the software distributed by PopAdStuff did actively scan and send popup spam from unsuspecting user's system." http://www.popadstop.com "NewestStuff.com LLC Official Statement PopAdStop has been discontinued... PopAdStop was a free product, and better than some similar products that others have sold for up to $40 in the past. The offering included a Messenger popup blocker, as well as a separately downloadable free web popup blocker. Free products or services are apparently not always appreciated... Bug report: Multiple indepentant reports indicate that the first few versions *MAY* have been affected by a modular advertisment component that had been accidentally inserted into the first version, apparently. This may possibly have caused PopAdStop to advertise itself from a few systems (providing a new form of Internet 'word of mouth' advertising, providing much greater distribution of PopAdStop in a much shorter time than we intended, and *MUCH* greater cost to *US*, because so many people downloaded PopAdStop from our website!!!), but was not part of the design. This possible bug was fixed ON ALL AFFECTED SYSTEMS with an automatic update, and no longer occurs. Very embarrassing indeed. Please accept our appologies if you experienced anything like this, but please do not slander us for it!!! The resulting public backlash and slander caused by this suspected bug seriously reduced our ability to use PopAdStop as a marketing tool for our SpamBurner product, and turned PopAdStop into nothing more than a huge waste of our time... Valuable lesson from the PopAdStop project: Do not let the same programmer develop two different pieces of software at the same time, and probably giving stuff away for free is a bad idea too..."

1 0

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