October 2003 - Test - lists.nanog.org

Re: Sitefinder fan - this guy needs a clue.
by John Neiberger 08 Oct '03

08 Oct '03

>>>> Owen DeLong <owen(a)delong.com> 10/8/03 10:29:15 AM >>> > >On the CNET article that ZDNET seems to have copied lock stock and barrel, >he did actually identify himself as a Verisign VP in the by line. As such, >I think this is ZD's fault, not McLaughlin's. I don't have any love lost >for Verisign, but, I think we need to be very careful to stick to criticisms >that can stick to them. Otherwise, they will divert attention to our false >claims and use them to prove that we are the net.kooks they are trying to >make us out to be. > >Owen ZDNet has fixed the attribution on their article. They now mention before and after the article that McLaughlin is a Verisign VP. John --

1 0

10,000 foot view of DNS/Sitefinder/Verisign
by Howard C. Berkowitz 08 Oct '03

08 Oct '03

After attending the afternoon ICANN Security & Stability Committee meeting, I realized that the issues involved fall into several related but independent dimensions. Shy person that I am *Cough*, I have opinions in all, but I think it's worthwhile simply to be able to explain the Big Picture to media and other folk that aren't immersed in our field. In these notes, I'm trying to maintain neutrality about the issues. I do have strong opinions about most, but I'll post those separately, often dealing with one issue at a time. For those of you new to the media, it's often best to put things into small, related chunks. 1. Governance issues -------------------- Did Verisign have the right, regardless of technical merit, to do what it did without prior warning? I'm simply saying "did they do anything contractually or otherwise legally forbidden", not "was it strongly counter to the assumptions of the Internet" or "were they mean and nasty." The news/political interest here is whether any other group should or could have affected this, or if we need new governance mechanisms. Has this revealed any conflict of interest issues? To what extent should a registry be able to act unilaterally? These points are meant to be examined here in the context of law, regulation and governance, as opposed to the less formal points in #2. 2. Process (slightly different than governance) issues. ------------------------------------------------------ Moving away from the letter of their contracts, what should they have done (if anything) about open comment and forming consensus? This is vaguely making me wonder if they had evidence of WMDs....oops, wrong controversy. Assume they had no requirement for prior discussion. What, if any, requirements did they have for testing and validating their approach, given that a top-level registry is in a unique connectivity position with special privileges. 3. Internet architectural impact (slightly different than effects on innovation and/or effect on existing software). -------------------------------------------------- I think it's reasonable to state that Sitefinder, and changes of "internal" behavior, violates at least the traditional end-to-end and robustness principles. This should be considered in the spirit of the core vs end state discussion in RFC 3439, and the architectural work going into midboxes. A general question here is to what extent is it important that the Internet be consistent with its relatively informal architectural assumptions? Even among the newer technical folk, when teaching, I rarely hear anyone aware of the architecture work---they think "7 layers" is the ultimate answer [1]. [1] I spent over five years of my life in OSI research, development and promotion. We may have had the answer, but, unfortunately, we never could articulate the question. That is a lesson here 4. Is the Internet the Web? Are all Internet users people? ---------------------------------------------------------- I don't think it's unfair to say Sitefinder is web-centric. The current responses may be useful for people who can interact with it. Apparently, there are patches that will help with mail response and even anti-spamming tools. But what of other protocols, especially those intended to run without human intervention? What about failover schemes that employ DNS non-resolution as an indication that it's time to pick an alternate destination? Is the apparent trend to move from "everything over IP" to "everything over HTTP" a good one? _could_ it be a good one in well-defined subsets of the Internet? 5. Effects on innovation ------------------------ Innovation and stifling innovation has come up quite a bit. If one looks at the End-to-End Assumption, the historic perspective is that the "killer apps" appear at the edges and depend on a consistent center (e.g., web and VoIP, the latter with a QoS-consistent center [2]). Development in the core tends to be more evolutionary and subject to discussion (e.g., CIDR). Other development in the core tends to be with the implementations (e.g., faster routers and lines). [2] Remember that the access links to an ISP usually aren't the QoS problem. Once you get to the POP, voice and other delay-critical services can go onto VPNs or other QoS-engineered alternatives to the public Internet. Verisign says Sitefinder is innovative, and let's assume that it is. But, if so, it's an innovation in the core, which is not the "time-proven way". When I speak of time-proven, I certainly don't mean that there isn't innovation -- this message did NOT reach you over a 56 Kbps line between IMPs. Internet Explorer, for example, has a means of dealing with domain typos, but it is contrary to the way Sitefinder does things. IE also does it at the edge. How do we deal with potential commercial wars between the edge and core as far as competition for innovation? 6. Stability ------------ Assume that Sitefinder and the associated mechanisms are ideal. In such a case, users would expect it. Unless a large number of users learn to spel and tipe gud, these instances will be points of heavy traffic. What are the availability requirements to make the service dependable? This includes clustered servers at individual nodes, as well as distributed nodes. There has to be sufficient bandwidth to reach the nodes, and even if the node has adequate connectivity bandwidth, there are subtle congestion issues. It was pointed out that wireless implementers, used to expecting a small error message in their bandwidth-limited edge environments, are less than thrilled about getting a 17K HTML response. Remember, if these concepts prove themselves in .com and .net, users will expect them in all TLDs -- or we get to the generally undesirable situation of different behavior in different domains. Let's assume Verisign has an adequate track record of running reliable servers -- but what would be the requirements for a new operator of .com and .net for people expecting the Sitefinder functionality. In a new TLD, what has to be the support on Day 1? A very different question is whether business models associated with this service are sufficiently robust to be sure it stays present once users expect it.

2 1

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