- NANOG - lists.nanog.org

Re: Verisign's public opinion play (fwd)
by Owen DeLong 08 Oct '03

08 Oct '03

Forwarding by request. Please direct replies to John Fraizer. ------------ Forwarded Message ------------ Date: Wednesday, October 8, 2003 11:41 AM -0400 From: John Fraizer <nanog(a)overkill.enterzone.net> To: Owen DeLong <owen(a)delong.com> Cc: Brian Bruns <bruns(a)2mbit.com>, nanog(a)merit.edu, charles.cooper(a)cnet.com, cook(a)cookreport.com, nanog(a)merit.edu Subject: Re: Verisign's public opinion play Owen, et all: I wrote a piece as soon as I read McLaughlin's PR spewage. I sent it to the addresses I could find at cnet but, I have not geard from them. PS: Owen, I don't have NANOG-post access. Can you echo this to the list for me? Dear Editor, In response to the article presented by Mark McLaughlin on October 6, 2003 at CNET.News.Com, "Innovation and the Internet," I would like to present the following rebuttal. McLaughlin states when a user mistypes a URL and are presented with an error, "That error page can lead to a dead end, with no options on how to get to where you tried to go." I guess we should thank our lucky stars that VeriSign is there to save us from ourselves. After all, none of us are resourceful enough to actually look at the URL we typed and notice that we have made a typo. In the event that we are unsure of the exact domain name, none of us are resourceful enough to consult Google, Yahoo or any one of the numerous other search engines. We will simply sit and stare at the error page and our personal productivity will suddenly screech to a halt. VeriSign to the rescue, right? Not quite. McLaughlin states that someone typos a domain name 20 million times per day and that "people have used [Site Finder] more than 40 million times". VeriSign deployed "Site Finder" on September 15th 2003, and subsequently bowed to overwhelming public pressure to remove the wildcard entries in the .COM and .NET DNS Zones that facilitated their directing "lost" users to their "Site Finder" service on October 4th, 2003. So, according to McLaughlin's own numbers, over the 20-days that "Site Finder" was in service, of the 400 million "typos" that VeriSign redirected to its "Site Finder" service, only 10% of those who were redirected made use of the service. It would seem to me that this would indicate that 90% of the users do not find the "Site Finder" service as useful. McLaughlin goes on to say, "ICANN cast a vote last week for the status quo by forcing VeriSign to shut down the service." This is an inaccurate claim and is obviously worded to incite the public perception that ICANN has forced VeriSign to shut their "Site Finder" service down. Nothing could be further from the truth. ICANN demanded that VeriSign remove the "wildcard" records from the .COM and .NET DNS Zone files. The "Site Finder" service is still operational at http://sitefinder.verisign.com/ and any person who desires to use that service can do so by simply typing that URL into their browser. The difference is that users are not being FORCED to use the "Site Finder" service. This brings us to a very important point - one that VeriSign, with much help from the press, has gone to great lengths to obfuscate. "Wildcard" records in the .COM and .NET DNS Zones are NOT the "Site Finder" service. The wildcard records in question were implemented in the following form: "* IN A [IP address of Site Finder service]" ICANN did not demand that VeriSign shut down it's "Site Finder" service. They simply demanded that VeriSign remove the "wildcard" records from the .COM and .NET TLD DNS Zones. In operation, the existence of this record in the .COM and .NET DNS Zones would cause any typo in the domain portion of a fully qualified domain name to be redirected to an IP address operated by VeriSign on which they had implemented their "Site Finder" service. This "hijacking" of typos has many security, privacy and interoperability implications, all of which VeriSign have failed to address in a satisfactory manner. (1) The "Site Finder" service is subject to "man-in-the-middle" type attacks in which traffic to/from "Site Finder" can be intercepted. For a person using a web browser, this will expose information about the site(s) they are attempting to access. In the case of email, the entire contents of an email message may be captured by a third party. This email may very well contain sensitive information that has now been compromised. Prior to the implementation of "wildcard" records in the .COM and .NET DNS Zones by VeriSign, a simple typo in an email or URL did not expose users to this very probable and easy to implement attack. (2) Anthony F. Lo Cicero, Esq., on behalf of Register.com, outlined several interoperability implications in his letter to Brian Davis, Esq., Chief Litigation Counsel, VeriSign, Inc., dated September 19, 2003. Lo Cicero states, "As VeriSign is well aware, many registrars, including Register.com have long-established business practices of disabling the DNS of recently-expired domain names, as a means of notifying the customers of their need to renew their registrations. Contrary to its public claims, VeriSigns SiteFinder service interferes with these active registrations, hijacking their DNS and pointing them to a monetized search engine." Lo Cicero goes on to say, "Certain other names being redirected by VeriSign to the SiteFinder web site are also active registrations for which the registry fee has been paid. For example, names for which customers have chosen to disable the DNS and registrations that have been seized by Register.com, and for which it has disabled the DNS, all now point to SiteFinder." (3) Dr. Paul Twomey, President and CEO, ICANN, in his letter dated September 22, 2003 states, "Because the VeriSign Site Finder server makes it appear that a non-existent domain exists, the service introduces significant problems to the critical Internet infrastructure. Many other important Internet protocols rely heavily on proper DNS behavior. The impact of VeriSigns Site Finder is unclear with respect to security of the DNS. Site Finder unilaterally precludes the use of a prevalent type of anti-spam filter that uses DNS to validate the domain of legitimate emails. Because VeriSign's servers are authoritative for the .COM and .NET TLDs, the most prevalent of the TLDs, Internet users have little protection against the implication of this flawed system." (4) Web browsers all over the world stopped displaying "page not found" in the local language and character set of the users when given incorrect URLs rooted under the .COM and .NET TLDs. Instead, browsers presented an English language search page from a web server operated by VeriSign. For visually impaired users who make use of computer generated voice software to dictate the contents of web sites to them, the actions of VeriSign present a significant barrier to their enjoyment of the Internet. As stated by the Internet Architecture Board on September 19, 2003, "Even if these were acceptable changes, the new mechanism has poor scaling properties, and unless the operator [VeriSign] chooses to invest significant resources in maintaining a large, robust web server setup, the user experience is going to get even worse: instead of either a local language error message or an English search page, the user is going to get 'attempting to connect...' followed by a long wait." (5) All email addressed to misspelled or nonexistent domains flowed to VeriSign's server where it was bounced back to the sender. This has many ramifications. Operators now have heavier mail handling load than they did under the previous DNS operation where the email would be bounced locally. Operators were dependent on the performance of the bounce server operated by VeriSign. If VeriSign's server slowed or failed, mail that would previously have been bounced by the operators server would queue at the SMTP relay for that relay's queue time before bouncing back to the user. Emails that would have previously bounced back to the user immediately went unnoticed for days while they sat in the SMTP delivery queue. Operators were also dependent on the correct operation of VeriSign's bounce server. VeriSign's bounce server experienced bugs that caused mail that would have previously bounced to not bounce at all and may have been reported to the user as having been delivered when in all actuality, it simply vanished without a trace. In cases where domain owners had misconfigured backup mail exchangers (MX's) with a particular MX pointing to a non-existent domain name, mail that would have previously been eventually delivered bounced. If a user misconfigured their mail client to point to a non-existent domain name, the client would connect to the bounce server and be presented with an error indicating that the recipient address was wrong when in all actuality, this was not the problem. (6) Network printer configuration tools commonly check the validity of the print spooler. With VeriSign's wildcard records in place in the .COM and .NET TLDs, an error that would have been reported early in the configuration process would have only been noticed when printing failed to work. Additionally, it is quite possible that proprietary and confidential information was routed to VeriSign's servers when users attempted to print to misconfigured network printer spools. (7) The wildcards installed in the .COM and .NET TLDs broke several simple spam filtering techniques commonly used on mail servers as well as more complex filtering that checked for the existence of a sending domain to screen out obviously bogus senders. (8) VeriSign intercepted HTTP and SMTP requests that were routed to their server as a result of the wildcards they placed in the .COM and .NET TLDs. The internet is much more than the Web and Email however. FTP, Telnet and SSH, as well as an enormous number of other protocols that are in use on the internet that made connection attempts to a misspelled domain name received at best a TCP reset message and in some cases, simply had their packets dropped with no error. Prior to VeriSign's implementation of the wildcard records in the .NET and .COM TLDs, these attempts would have received DNS error messages. With VeriSign's wildcard scheme in place, these messages were replaced by mysterious connection failures. (9) The response from the VeriSign "Site Finder" service was typically around 17000 bytes of information. Prior to VeriSign's implementation of wildcard records in the .COM and .NET TLDs, the user would have received a response that was typically more than 10 times smaller. In the case of transfer based billing for Internet access (as in the case of most wireless data services) the recipient had to pay significantly more in access charges. McLaughlin states, "ICANN appears to have bought into claims that the Internet has broken or will break. Anyone who has used it in the last three weeks knows that claim to be false. More likely, ICANN caved under the pressure from some in the Internet community for whom this is a technology-religion issue about whether the Internet should be used for these purposes." The claims that ICANN "bought into" are not unfounded or anecdotal. They are documented cases of previously functioning systems and protocols that ceased to function as desired when VeriSign implemented the wildcard records in the .COM and .NET TLDs. VeriSign does NOT OWN .COM and .NET. - They are entrusted with their stewardship. Their actions with respect to adding wildcard records to those Zones, with the purpose of profiting millions of dollars by selling the traffic generated by typos under the thin veil of "offering a service" was not consistent with the terms of their contract. DNS operates much in the same way that the telephone translations database operates. Much in the same manner that you receive a recorded announcement indicating "the number you have dialed is not in service" if you dial a non-existent telephone number, the DNS protocol presents a "no such name" response when a lookup is performed against a non-existent domain name. There would be bloody hell to pay if AT&T, for example, poisoned the telephone translations database and routed all non-existent telephone numbers to an automated "directory assistance" service that featured recorded "commercials" from third parties yet, VeriSign seems to think it is OK to do practically the same thing with the TLD DNS Zones for .COM and .NET, sending all "typos" to their "Site Finder" server, complete with paid advertisements and listings by third parties. VeriSign has spared no expense in their attempts to sway public opinion. They have tried to portray the image that they are being attacked for their generous offering of the "Site Finder" service. It would appear that a staggering number of news outlets have bought into this obvious spin of the facts. I sincerely hope that you will publish this article so that the general public has opportunity to digest the technical FACTS of the matter to draw their own conclusions rather than basing those conclusions on knee-jerk reactions to the fodder being spewed by the Public Relations army at VeriSign. Biography John Fraizer is the President of EnterZone Network Services, LLC. He is also an active member of the Internet Security community. Prior to founding EnterZone, Fraizer worked for Digital Equipment Corporation and Alltel Mobile Communications. Fraizer is also an honorably discharged United States Marine. ---------- End Forwarded Message ----------

1 0

Last mile through roadrunner for YOUR customers?
by Drew Weaver 08 Oct '03

08 Oct '03

Has anyone ever had any luck getting an agreement with Road Runner to use them as last mile for your customers? I've noticed a handful of companies that are currently doing this with them, but when you contact Road Runner they act like they don't know what you're talking about (probably because they don't??) Anyway Im just wondering from a technical standpoint if anyone has done this and how it is done. Thanks, -Drew

1 0

Draft agenda - subject to change
by Susan Harris 08 Oct '03

08 Oct '03

Draft Agenda NANOG 29 Oct. 19-21, Chicago Sunday Tutorials ---------------- 1:30 - 3:00 p.m. Implementing a Secure Network Infrastructure (Part I) Merike Kaeo 1:30 - 3:00 p.m. Harvest BGP Troubleshooting Philip Smith, Cisco 3:00 - 3:30 p.m. BREAK 3:30 - 5:00 p.m. Deploying IP Anycast Kevin Miller, CMU 3:30 - 5:00 p.m. Implementing a Secure Network (Part II) 5:00 - 7:30 p.m. Dinner 7:30 - 9:00 p.m. MPLS Applications Overview Ina Minei, Juniper 7:30 - 9:00 p.m. Implementing a Secure Network (Part III) Monday, October 20 ------------------ 9:00 a.m. Welcome, Introductions Susan Harris, Merit; Ray Plzak, ARIN; Jordan Lowe, Server Central 9:15 a.m. Verisign's Wildcard Record: Effects and Responses Mark Kosters and Matt Larson, Verisign; Suzanne Woolf, ISC 9:45 a.m. Update on Anomalous DNS Behavior Duane Wessels, Packet Pushers 10:30 a.m. BREAK 11:00 p.m. Panel: Watching Your Router Configurations and Detecting Those Exciting Little Changes Randy Bush, IIJ, moderator Henry Kilmer, Terrapin Communications; John Heasley, Verio Danny McPherson, Arbor 11:45 a.m. Building a Web of Trust Joe Abley, ISC 12:00 p.m. LUNCH (on your own) 1:30 p.m. The Relationship Between Network Security and Spam Carl Hutzler and Ron da Silva, AOL Time Warner 2:00 p.m. Panel: Simple Router Security, What Every ISP Router Engineer Should Know and Practice Randy Bush, IIJ, moderator; Rob Thomas, Cisco/Team Cymru; Neal Ziring, NSA; George Jones, MITRE 3:00 p.m. AOL Backbone OSPF-ISIS Migration Vijay Gill and John Warner, AOL Time Warner 3:30 p.m. BREAK 4:00 p.m. Research Forum Internet Service Differentiation Using Transport Options: The Case for Policy-aware Congestion Control Panos Gevros, University of Cambridge Passive Internet Health Monitoring With BGP Kenneth McGrath, Dartmouth How to Compute Accurate Traffic Matrices for Your Network in Seconds Yin Zhang, Matthew Roughan, Albert Greenberg, David Donoho, Nick Duffield, and Carsten Lund, AT&T AutoFocus: A Tool for Automatic Traffic Analysis Cristian Estan, UCSD 7:30 - 9 p.m. ISP Security and NSP-SEC BOF IV Barry Raveendran Greene, Cisco Merike Kaeo, moderators PGP Key Party - Joe Abley, ISC Tuesday, October 21 ------------------- 9:00 a.m. GBIC Interface Standards Support in the Telecommunications Industry Dave Wodelet, Shaw Communications 9:30 a.m. A Systematic Approach to BGP Configuration Checking Nick Feamster and Hari Balakrishnan, MIT 10:00 a.m. BGP: Good MEDs Gone Bad! Danny McPherson, Arbor 10:30 a.m. BREAK 11:00 a.m. Flawed Routers Flood University of Wisconsin Internet Time Server Dave Plonka, University of Wisconsin - Madison 11:20 a.m. Student Desktop TV: Safe and Secure Video Over IP Tim Ward, Northwestern University 11:40 a.m. The Blaster Worm: The View From 10,000 Feet Jose Nazario, Arbor 12:00 p.m. LUNCH (on your own) 1:30 p.m. An Overview of the Global IPv6 Routing Table Cathy Wittbrodt 2:00 p.m. It's a Surprise 2:30 p.m. Stress Testing to Validate Router Readiness for Deployment Shankar Rao, Qwest; Scott Poretsky, Quarry 3:00 p.m. Fast IP Convergence Clarence Filsfils, Cisco 3:30 p.m. Adjourn Susan Harris, Merit

1 0

RE: Transit and Paid Peering Exchanges
by Freedman David 08 Oct '03

08 Oct '03

As far as I remember Band-X (http://www.band-x.com) do this. Dave. -----Original Message----- From: Daniel Golding To: Dennis Jewth Cc: nanog(a)merit.edu Sent: 08/10/03 10:11 Subject: Re: Transit and Paid Peering Exchanges Dennis, I'm not really looking at normal exchanges where some participants offer transit or partial transit. I'm looking at exchange fabrics specifically set up for the purpose of selling services, be they transit, partial transit, or paid peering. Most of these exchanges have web based administration, route servers, flow accounting, or some other combination of services. A good example is Equinix's Equinix Direct. Equinix maintains a series of exchange fabrics that are primarily for settlement free peering, but also has exchange fabrics set up, specifically, for buyers and sellers of services. Telehouse in NYC was doing something like this, as well. I'm not sure how far it has progressed. Thanks, Dan > From: "Dennis Jewth" <Dennis.Jewth(a)xchangepoint.net> > Date: Wed, 8 Oct 2003 10:03:41 +0100 > To: "Daniel Golding" <dgolding(a)burtongroup.com> > Cc: <nanog(a)merit.edu> > Subject: Re: Transit and Paid Peering Exchanges > > Hi Daniel > > Really you need to reword that as exchanges used for peering and transit > provision/delivery, over which some networks may be paying for peering > sessions. > > We run a MAN in London connecting 7 co-lo's (including THouse North) that is > used as the > delivery platform for transit from the Carriers to ISPs and hosting > companies. We are also a peering point. > > Paid peering is more common in the US. In Europe some of the larger networks > are talking about offering paid peering (and there may be already few doing > it). It's to > get that info out in the open from those doing it that's harder (hence your > mail > to Nanog, no doubt). > > Are you looking at partial transit as well? > > Dennis Jewth > XchangePoint Europe > www.xchangepoint.net > > > ----- Original Message ----- > From: "Daniel Golding" <dgolding(a)burtongroup.com> > To: <nanog(a)merit.edu> > Sent: Wednesday, October 08, 2003 9:31 AM > Subject: Transit and Paid Peering Exchanges > > >> >> >> Doing some research.... >> >> Anyone have a list of Transit and Paid Peering exchange fabrics? >> >> I am interested in both US and EU locations, particularly in interesting >> sites like 111 8th Ave (NYC), Telehouse North (London) and other major > telco >> hotel type facilities. >> >> I'll summarize for the list and repost. >> >> Thanks, >> -- >> Daniel Golding >> >> > > > ________________________________________________________________________ > This email has been scanned for all viruses by the MessageLabs Email > Security System. For more information on a proactive email security > service working around the clock, around the globe, visit > http://www.messagelabs.com > ________________________________________________________________________ > -- Email Disclaimer can be viewed at: http://www.netscalibur.co.uk/email.html --

2 1

A RR Wildcards and Stability
by Daniel Karrenberg 08 Oct '03

08 Oct '03

The comittee should realise that the question Verisign poses about observed adverse effects, while interesting, is not as pertinent as it seems at first sight. John Klensin put it very well yesterday in a rigorous way. I'll offer a less rigorous but more graphical analogy: A contractor drills large holes in the central structural parts of a building to allow installation of their innovative garbage disposal. Civil engineers question the effects this has on the building's stability. The contractor's defense is: "Well it is still standing! How much work did those tenants really have patching up the holes to reduce the air drafts and stop the crackling noises?" Daniel

3 2

Re: South America NOG ?
by Eric Kuhnke 08 Oct '03

08 Oct '03

Whoever is running the mailing list server linked from enred.org ( http://mailman.reacciun.ve/mailman/listinfo/enredo ) should update their Apache very soon... http://www.securiteam.com/exploits/5JP0G204KG.html The requested URL /pipermail/directorio-enred/ was not found on this server. Apache/1.3.17 Server at <mailto:hostmaster@reacciun.ve>mailman.reacciun.ve Port 80 >And you can find them at http://www.enred.org >The mailing list link is in the upper right hand corner. > >--Michael Dillon

1 0

Sitefinder study released
by Michael.Dillon＠radianz.com 08 Oct '03

08 Oct '03

Now this is the kind of thing that we need to combat Verisign. http://cyber.law.harvard.edu/tlds/sitefinder/ The data presented here exhaustively shows that Verisign's whole business model is flawed because they don't really control this "diversion" of traffic and ISPs can and will block the diversions at source with DNS patches and routing. This particular paper puts pressure the companies that are paying Verisign for the Sitefinder service. We still need more papers that describe the negative technical impacts of sitefinder and we need those papers to be published somewhere, not just on the NANOG mailing list. At minimum, you should send copies to both ICANN and to the Berkman Center (read the above paper for a URL). --Michael Dillon

1 0

Re: South America NOG ?
by Michael.Dillon＠radianz.com 08 Oct '03

08 Oct '03

>foro de redes has been going on since '91. the mailing list is >enredo. And you can find them at http://www.enred.org The mailing list link is in the upper right hand corner. --Michael Dillon

1 0

Re: Transit and Paid Peering Exchanges
by Daniel Golding 08 Oct '03

08 Oct '03

Dennis, I'm not really looking at normal exchanges where some participants offer transit or partial transit. I'm looking at exchange fabrics specifically set up for the purpose of selling services, be they transit, partial transit, or paid peering. Most of these exchanges have web based administration, route servers, flow accounting, or some other combination of services. A good example is Equinix's Equinix Direct. Equinix maintains a series of exchange fabrics that are primarily for settlement free peering, but also has exchange fabrics set up, specifically, for buyers and sellers of services. Telehouse in NYC was doing something like this, as well. I'm not sure how far it has progressed. Thanks, Dan > From: "Dennis Jewth" <Dennis.Jewth(a)xchangepoint.net> > Date: Wed, 8 Oct 2003 10:03:41 +0100 > To: "Daniel Golding" <dgolding(a)burtongroup.com> > Cc: <nanog(a)merit.edu> > Subject: Re: Transit and Paid Peering Exchanges > > Hi Daniel > > Really you need to reword that as exchanges used for peering and transit > provision/delivery, over which some networks may be paying for peering > sessions. > > We run a MAN in London connecting 7 co-lo's (including THouse North) that is > used as the > delivery platform for transit from the Carriers to ISPs and hosting > companies. We are also a peering point. > > Paid peering is more common in the US. In Europe some of the larger networks > are talking about offering paid peering (and there may be already few doing > it). It's to > get that info out in the open from those doing it that's harder (hence your > mail > to Nanog, no doubt). > > Are you looking at partial transit as well? > > Dennis Jewth > XchangePoint Europe > www.xchangepoint.net > > > ----- Original Message ----- > From: "Daniel Golding" <dgolding(a)burtongroup.com> > To: <nanog(a)merit.edu> > Sent: Wednesday, October 08, 2003 9:31 AM > Subject: Transit and Paid Peering Exchanges > > >> >> >> Doing some research.... >> >> Anyone have a list of Transit and Paid Peering exchange fabrics? >> >> I am interested in both US and EU locations, particularly in interesting >> sites like 111 8th Ave (NYC), Telehouse North (London) and other major > telco >> hotel type facilities. >> >> I'll summarize for the list and repost. >> >> Thanks, >> -- >> Daniel Golding >> >> > > > ________________________________________________________________________ > This email has been scanned for all viruses by the MessageLabs Email > Security System. For more information on a proactive email security > service working around the clock, around the globe, visit > http://www.messagelabs.com > ________________________________________________________________________ >

1 0

Re: kooky BGP tricks
by E.B. Dreger 08 Oct '03

08 Oct '03

DG> Date: Wed, 08 Oct 2003 09:31:45 +0200 DG> From: Daniel Golding DG> 1) In a way, its fraudulent If not mutually agreed in advance between 65000 and 65100, yes. This is analogous to announcing more specifics from another provider's space. DG> 2) Some folks do BGP traffic engineering tricks using AS path. Other folks DG> do measurement stuff using AS-Path. Therefore, wrong AS paths are bad. True. Seeing "1239 $smallprovider 701" would be a bit bizarre, pretending for a moment that 1239 accepted "$smallprovider 701". DG> 3) Hacks are unscalable. This is a hack. In a sense. In another sense, it's like 65000 sending 65100 partial routes... except it's actually a subset of 65000 doing the talking. I should have been more clear in my post. I originally was addressing the issue of $smallprovider peering with a transit AS when $smallprovider's upstream wouldn't. Ghetto multihoming was a poorly-added afterthought, and probably muddled the question. :-/ DG> Why doesn�t AS65100 just advertise the routes as "65100 65100 i" or "65100 DG> i"? What is gained by doing "65100 65000 I" other than ensuring that if the DG> link between $downstream and AS65000 goes down, then $downstream becomes DG> unreachable from AS65000 due to BGP loop detection? I've always seen inconsistent origin ASNs as "evil". They work, but are generally frowned upon... perhaps it is the lesser of evils, though. DG> If I were AS65000, I might be disposed to complain to AS65100's upstream or DG> to the large community about 65100 stealing my AS. I would suspect some evil Again, I meant to indicate 65000 and 65100 agreed in advance. DG> intent. Also, if $downstream cant afford $500 for an AS, what makes anyone DG> think they can afford to pay either upstream? Very true. And ASNs are still plentiful; running out is far enough down the road not to worry... 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 _________________________________________________________________ DO NOT send mail to the following addresses : blacklist(a)brics.com -or- alfra(a)intc.net -or- curbjmp(a)intc.net Sending mail to spambait addresses is a great way to get blocked.

1 0