October 2003 - Test - lists.nanog.org

Re: Some very strange network behaviors
by Gregory Hicks 07 Oct '03

07 Oct '03

> Date: Thu, 11 Sep 2003 13:35:37 -0700 > From: Crist Clark <crist.clark(a)globalstar.com> > > Mike Lewinski wrote: > > [...snip...] > OS's IP stack is misbehaving badly, Zone Alarm should not see the traffic > on the LAN that does not have his MAC address on it. > > How would a switch/router be deciding that these other IP addresses > should go to his PC's NIC (MAC address)? Unless the switch got confused when the MAC address changed as it did...? Then the switch would go into "broadcast" or "flood" mode where every packet is delivered to evey port because the switch doesn't know where to send it. Regards, Gregory Hicks > -- > Crist J. Clark crist.clark(a)globalstar.com > Globalstar Communications (408) 933-4387 --------------------------------------------------------------------- Gregory Hicks | Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3479 San Jose, CA 95134 | Internet: ghicks(a)cadence.com Never attribute to malice that which is adequately explained by ignorance or stupidity. Asking the wrong questions is the leading cause of wrong answers "The best we can hope for concerning the people at large is that they be properly armed." --Alexander Hamilton

4 3

AS5384 routing table is not propagating
by Henry Linneweh 07 Oct '03

07 Oct '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 AS5384 routing table is not propagating very good here and I see at least 50 instances of that I was checking it for a peer trying to get a better route result - -Henry R Linneweh -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 - not licensed for commercial use: www.pgp.com iQA/AwUBP4KhwsiimYc7OT3DEQLIEgCfTONrpI/K1AlnimGvDlnX79kDS44An2ZB K0Wyt2xT8YNeHNEzxXgKjc7T =tRS8 -----END PGP SIGNATURE-----

1 0

Re: Verisign's public opinion play
by Michael.Dillon＠radianz.com 07 Oct '03

07 Oct '03

>I know personally I would love to put out a paper, but I have no idea where >to begin. If you don't have the time to write a paper then sit down and write a case study about your own experiences that could be published in a trade magazine or your local newspaper. Submit it to your favorite publications, then if none of them print it, resubmit it as a letter to the editor. In general, a case study is easier to write up that a paper and it can be used later as raw material by people who are doing research for a more detailed paper. --Michael Dillon

1 0

Re: sitefinder technical discussions
by Michael.Dillon＠radianz.com 07 Oct '03

07 Oct '03

>Having been involved in the community internet for as long as I have, I >want to wretch. I'd think Mark would be one of those, as well. Whether he does or doesn't want to retch, Mark does need a job and he happens to have one currently at Verisign as do a number of other skilled technical people. Things would be different if people on this list would actively recruit these Verisign technical people and hire them away, but does anyone really care enough to put their money where there mouth is? It wouldn't be the first time that a company was gutted by hiring away its brightest and best. --Michael Dillon

1 0

Re: sitefinder technical discussions
by Michael.Dillon＠radianz.com 07 Oct '03

07 Oct '03

>In the interest in gaining more community review and comment, a discussion >list has been setup to discuss factually-based technical issues >and solutions surrounding the operational impact of wildcards in >top-level domains on Internet applications. If anyone wants to follow this via the web archives, it is at http://lists.elistx.com/archives/sitefinder-tech-discuss/ --Michael Dillon

1 0

Re: Verisign's public opinion play
by George William Herbert 07 Oct '03

07 Oct '03

One soundbite which just came to me: "What if the company which has the Yosemete restaraunt consession put up a 300 foot rig and drilled for oil behind the kitchen?" -george william herbert gherbert(a)retro.com

1 0

An Open Letter of corrections to Mark McLaughlin's Innovation and the Internet
by Owen DeLong 07 Oct '03

07 Oct '03

While I realize that your Perspectives area is a place where various people are allowed to submit editorials, your publication of this particular very skewed piece without checking some of the stated facts within it does not meet CNet's usual standard of journalism. In addition to Mr. McLaughlin's errors or omissions of fact, he makes a number of misleading statements and outright incorrect implications. As such, I will simply address the article paragraph by paragraph, beginning with the bold paragraph being considered paragraph 1. Paragraph 1: It's not about whether innovation should be encouraged. I think if you were to survey the opponents of Verisign's maneuver, you would find that each and every one of them would say they are in strong support of innovation on the internet. What Verisign did was not innovation. It was a move to line their pockets with significant additional revenue while simultaneously abusing their monopoly position in control of a resource contracted to them to manage in the public trust. They do not OWN the domains that they modified, instead, they are entrusted with the management of said domains (namely .NET and .COM). None of Verisigns competitors is in a position to place wildcard records in these zones, so, Verisign also was abusing it's position of public trust to gain unfair advantage over competitors. Paragraph 2: The error page simply indicates that they URL they typed involved the name of a host which did not exist. Verisign ignored the fact that DNS does not only effect web services. While it is true that some may say that this is an improvement for web browsers, it creates significant problems for other applications. More on this below. Paragraph 3: Site finder is not about improving the user experience. If it were, Verisign would have solicited public input prior to inflicting this change on a critical are of internet infrastructure. Verisign is now launching this PR campaign to try and make ICANN look like the bad guys for finally saying no to Verisign's repeated abuses of their position. Site finder is about profits for Verisign. In fact, substantial profits on the order of Millions of dollars per day. This is why they were so reluctant to take it down in spite of a polite request from ICANN. ICANN had to point out that Verisign was in violation of several clauses of their contract and threaten them with legal action to get them to comply. Paragraph 4: Similar services were tested in a manner which did not break existing infrastructure for non-web oriented applications which were well known on the internet. Verisign didn't do any testing, they simply unleashed this on the two most popular top level domains without review, notice, or even a heads up to the operational community. In fact, the first notification to the NANOG (North American Network Operators Group) mailing list by Verisign came several hours after the debate had already started. Verisign's site finder service didn't trigger debate because they hadn't been tried for .com and .net, it triggered debate because it disrupted services, constituted a change which was not subjected to appropriate public review beforehand, and, represented a cavalier and mistaken attitude by Verisign that these top level domains were theirs to manage however they saw fit. These domains have a long history on the internet, and, they have always been considered a public-trust type of resource. The contract to Verisign to manage these domains clearly calls for Verisign to manage them in the public interest. This was Verisign managing the domain in their own interest, the public be damned. While it is true that during the three weeks it took to get Verisign to fix their abomination, DNS continued to function for most visible levels, the internet continued to route packets, and, most things functioned as before, that does not mean that their change did not break things. As an example, prior to Verisign's change, if I sent an email to user(a)noexist.com intending to send it to user(a)exists.com, I would get an answer back immediately saying "noexist.com" does not exist. After Verisign's change, their mail rejector would either simply drop my mail in a black hole, or, when it was too busy, fail to respond for long periods of time. Either way, since I don't get an error message, I don't know that my mail didn't get through. Another problem comes from anti-spam utilities which depend on being able to determine if a domain name being used in mail exists or not. Verisign rendered it virtually impossible, because, under their proposed system, all domains exist in DNS. They essentially eliminated a vital and useful error message from the internet, instead choosing to make everyone use their error handler. Without going through the IETF and RFC processes, this is an unacceptable move on their part. Of course, IETF would never approve such an action and Verisign knows it. Further, if a domain expired or was accidentally removed, most software is designed to deal with NXDOMAIN responses (the error code returned prior to Verisign's actions) in a manner that allows this to be resolved without serious consequences. With Verisign's change, however, it becomes fatal. Imagine if you are looking for CNET.COM, but, due to a clerical error, CNET.COM has been removed from the DNS. Now, instead of getting an error saying that the site could not be located, you get Verisign. All your mail for CNET.COM, instead of getting queued and waiting for it to reappear for several days now instantly disappears into a black hole. I would think, if you were CNET.COM, in this case, you would be upset. Paragraph 5: ICANN bought into the claims that very specific things were broken by Verisign's actions. Those claims are true. The effort of Verisign to deceive the public into believing that this is not true and that ICANN caved under pressure from zealots and purists is a grossly inaccurate characterization of what happened. The pressure came from the operational community, the research community, and, end users. Sure, for some, technical purity and religion may be an issue. For most, we were far more upset that real applications in real use for real economic purposes were being interrupted or hampered by this unannounced, unprecedented, and, unacceptable change. Paragraph 6: This vocal minority is the MAJORITY of the people actually keeping bits flowing on the internet. It is, admittedly, not the majority of users of the internet, but, it does represent the majority of internet service providers. It represents the connectivity of the majority of users on the internet. Most end users don't even know what DNS is, let alone what happens when it is changed. It's not about resentment of use for commercial purpose. I'm sure there are people out there that think the internet shouldn't be used for commercial purposes. The majority of the outcry, however, came from people trying to make a living out of keeping the internet running for commercial purposes. Mr. McLaghlin and Verisign seem, instead, to have ignored the fact that there's more to the ineternet that matters to our economy than just Web Browsing. Paragraph 7: They can disagree with purists all they want. The problem is that here they are disagreeing with the actual operators of the internet who are not trying to hold the internet back, but, keep it functioning. Paragraph 8: Throughout that history, the debate has been held in public and actions and changes to standards on the internet have been based on a combination of rough consensus and running code through a public process known as the IETF (Internet Engineering Task Force). Verisign did not subject these changes to any form of review outside of Verisign. There was no community input or review. If there had been, the community would have rejected this before it started, because it had real operational impact, and, because it had Verisign abusing public trust to line their pockets. Fierce debate is good. Verisign tried to avoid debate all together by launching this without the required reviews beforehand. Verisign has a long history of doing this. Paragraph 9: This is the one paragraph with significant truth in it. The result of this debate will have far reaching implications for the future of the internet. Do we send a clear message to Verisign that their role as agent of the public trust does not involve making whatever changes to critical infrastructure they feel are in their best interests? Do we allow Verisign to continue down the road that they have repeatedly attempted where it is as if they think they own all rights to these TLDs which were entrusted to them to manage by contract from ICANN. ICANN is a non-profit public benefit corporation charged with managing this part of the internet infrastructure. They contracted out this specific duty to Verisign with some reasonably strict rules about how they can do it. Verisign, in spite of this, has repeatedly ignored those rules in it's own interest. If ICANN allows this to continue, it will, indeed, change the face of the internet significantly. Mr. McLaughlin may think that's a good thing, as he will surely profit heavily from it. I doubt that it will improve things for internet users or operators, however. Paragraph 10: The internet already has a process for doing that. It's called the IETF. If this didn't happen in IETF, we wouldn't have HTTP, IPSEC, or, even DNS. Almost every protocol in use today on the internet was developed through the IETF process. Many improvements to protocols (BGP is currently on version 4, for example) have also come through the IETF and the related RFC process. The significant test is not whether the internet can do this (it already has), but, whether the internet can control the contractors entrusted with the management of items in the interest of the public. If not, ICANN will need to find an alternative. That will be difficult and painful. Paragraph 11: Noone is discouraged from exploring the bounds of the internet. Verisign is discouraged from BREAKING existing functionality in the name of lining their pockets. There are lots of places on the internet to experiment with new tools. The two most populated top level domains in the DNS tree are _NOT_ the right place to experiment. You wouldn't want a rocket scientist developing new fuels at your kid's elementary school, would you? Well, what Verisign has done is equivalent to that. They decided without warning to conduct their experiment in production instead of a laboratory. Paragraph 12: This paragraph cannot stand without the lies from the previous paragraphs. Paragraph 13: Verisign did not spend hundreds of millions of dollars to fortify the two root servers alone. Also, a number of other root servers withstood the attack as well. This whole paragraph is specious and misleading. In fact, Verisign has one of the worst track records for errors of any DNS provider in history. The technical community is less concerned about what will happen without Verisign than they are about what Verisign will do to the internet. Paragraph 14: The decisions made in this debate will not be about innovation. They will be about theft and hijacking. Will Verisign be allowed to hijack non-existant domain names to their own purpose and profit? Will they be allowed to continue to make arbitrary changes to services which are considered critical infrastructure by a large portion of the Internet community? Will ICANN stand up and say "no more" to Verisign's abuse of their position under the ICAN and USDOC contracts? These are the decisions that will be made around this issue. Innovation is safe and secure in the IETF. I will agree that there are problems to be solved in the IETF process, but, Verisign's actions won't even touch those, let alone make any positive contribution. Paragraph 15: The decisions made over the next months and years will determine whether the namespace remains a consistent and well-ordered hierarchy, or, whether the distaste for Verisign and the lack of action by ICANN to stop them becomes so distasteful to enough network operators that the authority of ICANN is usurped and the namespace becomes fragmented. That would be bad for everyone. Biography: Owen DeLong is a Network Architecht for a Mountain View based communications firm. He has held positions ranging from Systems Administrator to Senior Backbone Engineer at ISPs ranging from very small to very large. He has designed and built networks from dialup to OC-192. He has been an active participant in the Internet Operational Community and NANOG for more than a decade. Owen DeLong owen(a)delong.com

1 0

Trying to subscribe to Sitefinder list
by Howard C. Berkowitz 07 Oct '03

07 Oct '03

Well, I've been trying. I got a double opt-in that gave me a deadline to respond of 5AM Wednesday. I replied. No confirmation. Tried to post (crossposted to NANOG). Got error message telling me I was not yet on the list. Of course, with the apparent assumption the Internet is the Web, the first directions were to use a browser. Another option was to respond with a token in the message, a common enough procedure for mailing lists. I didn't read the fine print well enough. The first time, I discovered that the token had "confirm no" in it. Removed "no". Reread instructions. Just removing wasn't enough. Had to edit it to "confirm yes". Is there something wrong with the user friendliness of this picture, assuming that people actually use something other than a web browser, shocking as that might be for a m-a-i-l-i-n-g l-i-s-t? grrrr.

3 2

Architectural issues involving Sitefinder & related functions
by Howard C. Berkowitz 07 Oct '03

07 Oct '03

(since I haven't gotten back my enrollment confirmation, it seemed appropriate to crosspost this to NANOG. While I will address Sitefinder, there are broader architectural and operational issues). Let me assume, for the sake of this discussion, that Sitefinder is an ideal tool for the Web user, helping with the problem of not-quite-correct URLs. Given that, I'll stipulate in this discussion that the implementation of Sitefinder, along with the .com and .net wildcards that lead to it for unresolved domains, is a true benefit for the Web user. The Internet, however, is more than the World-Wide Web. It seems only logical to be able to discuss Sitefinder in two contexts: 1. Where it becomes the default, as with the recent Verisign wildcards 2. Where it is reached in some other manner. My architectural concern is defining a way in which context #1 serves the _non-Web_ services of the Internet. If DNS were purely an information service for Web users, the architectural conflict would go away, and only commercial and policy issues remain. I would hope that within the scope of the Sitefinder discussion list, or alternatively in another forum, is an approach to reconciling the IP-level DNS such that it continues to serve non-Web applications. Is there disagreement that Sitefinder provides no functionality to SMTP trying to deliver to an unresolved domain? To a user who mistypes the name of an FTP site and does not intend to use a Web browser? What about failover schemes for non-HTTP cooperative research across the Internet, where the inability to resolve a host name (assume that cached records have a zero lifetime) triggers selection of an alternate server? Seriously, technical people at Verisign may have thought about this and actually have suggestions. They may be very good ones, but, judging on the reactions to the Sitefinder deployment, it might be well to discuss them in open technical forums before a change is made. I'm really not trying to make it a matter of personalities, but there have been public statements by Verisign executives that such a process inhibits innovation. If Verisign policy is that as operator of .com and .net, it has the right to make unilateral changes, I think that needs to be clear to all concerned. I recognize that a number of independent parties suggest that the ICANN contract does not explicitly prohibit such unilateral action. Ironically, I worked with the original founders of Network Solutions, and almost was a principal back when it was a couple of rooms in McLean. Gary Desler, the founder and a fine engineer, always used to say "there is no technical solution to a management problem". In the current context, I simply want to know the rules for the playing field.

1 0

Comcast - Atlanta?
by Ian Wilson 07 Oct '03

07 Oct '03

Could someone with a clue from Comcast in the Atlanta, GA area please send me an email off-list? Thanks; Ian -- Ian Wilson IWCG.net Ian()iwcg!net PO Box 304 . Ada, Ohio 45810 The authors at Microsoft were nice enough to credit LSD in their latest security bulletin. It's nice to see that they're finally admitting that they were on LSD when they wrote their code.

1 0