July 1997 - Test - lists.nanog.org

what's up, AlterNIC?
by kevin brintnall 14 Jul '97

14 Jul '97

so i hit www.internic.net today, looking for contact information for a customer of mine, and lo and behold, it's some AlterNIC crap! come to find out, my name server has incorrect information for www.internic.net: piglet [~] ? nslookup www.internic.net Server: mixer.visi.com Address: 204.73.178.1 Non-authoritative answer: Name: www.internic.net Address: 207.51.48.15 according to my cache dump, this information came from AlterNIC. $ORIGIN INTERNIC.net. www 146598 IN A 207.51.48.15 ;Cr=addtnl [204.94.42.2] piglet [~] ? nslookup 204.94.42.2 Server: mixer.visi.com Address: 204.73.178.1 Name: aragorn.alternic.net Address: 204.94.42.2 piglet [~] ? whois 204.94.42 ATC dba ALTERNIC.NET (NETBLK-SEANET02-ALTERNIC01) SEANET02-ALTERNIC01 204.94.42.0 - 204.94.42.255 i do not have ANY AlterNIC hints in my root cache. why is AlterNIC poisoning my nameserver? kevin brintnall <kbrint(a)visi.com> network engineer, vector internet E3979560EF3E00B7 36D422A3C0F3741C

6 6

Domain Name NASA.COM
by jamie＠intuition.iagnet.net 13 Jul '97

13 Jul '97

Here we go with the InterNIC. I've been a longstanding cheerleader for the NIC, but I have to put all of that aside on this one. Today, without notice, the InterNIC turned "off" the domain name NASA.COM, a domain which had been registered now for over two years. In the letter that follows, the InterNIC claims that the registration of NASA.COM violates the Space Act of 1958. The Space Act of 1958, which is found at http://www.hq.nasa.gov/office/pao/History/amendact.html , states: ------------------------------------------------------------------------------- Sec. 310. (a) No person may...knowingly use...the letters 'NASA'...as a firm business name in a manner reasonably calculated to convey the impression that such firm or bueinss has some connection with, endorsement of or authorization from, the National Aeronautics and Space Administration...or...use (the NASA ackronym)...with any product or service being offered...to convey (endorsement or affiliation with the National Aeronautics and Space Administration). (b) Whenever it appears to the Attorney General that any person is engaged in an act or practice which constitutes or will constitute (a violation of the above), the Attorney General may initiate a civil proceeding in a district court of the United States to enjoin such act or practice. ------------------------------------------------------------------------------- Clearly NASA.COM and its content (which had nothing to do with space) was not violating the Space Act of 1958. I'm extremely disappointed. The action taken by the InterNIC also violates their own dispute policy, found at ftp://rs.internic.net/policy/internic/internic-domain-6.txt . Revision 02, effective Sept 9 1996, quoted: ------------------------------------------------------------------------------- - Second-level domain names are registered on a first-come, first-serve basis. ------------------------------------------------------------------------------- .. NASA.GOV was registered on Jan 7, 1986. NASA decided at that time that GOV was the most appropriate domain name, and chose NOT to register NASA.COM. This was over nine years ago. .. NASA.COM was registered on June 25, 1995 - over two years ago. A domain name existed for over two years, and after ONE DAY the InterNIC pulls the plug. No dispute policy. No questions. domain policy paraphrased: ------------------------------------------------------------------------------- 4. Revocation. Registrant agrees that Network Solutions shall have the right in its sole discrection to revoke a Domain Name from registration UPON THIRTY DAYS PRIOR WRITTEN NOTICE, OR AT SUCH TIME AS ORDERED BY A COURT... ------------------------------------------------------------------------------- .. Again, NSI violating its own policy. ------------------------------------------------------------------------------- 5. Third Party Dispute Initiation. Registrant acknowledges and agrees that Network Solutions CANNOT ACT AS AN ARBITER OF DISPUTES ... ------------------------------------------------------------------------------- .. (except when they feel like making exceptions). .. NSI also states throughout section 6 of the dispute policy that it will request information and wait 30 days upon any formal complaint. The letters that NSI received were dated July 10 and 11, respectively. They didn't even *bother* to ask. The slide at http://rs.internic.net/presentations/dont/dcisoc/tsld015.html clearly states that a domain name has value and that the policy buys time for dispute resolution. The InterNIC played Judge, Jury and Executioner in this highly irrational and ill-thought move. I welcome comments. Here is the letter sent from Dave Graves. Dave Graves' title is listed as "Contracts Administrator" in NSI's IPO filing. It is listed as "Business Manager" in "THE" 1995 press release announcing the $50 annual fee. > ---------- Forwarded message ---------- > Date: Fri, 11 Jul 1997 16:24:34 -0400 > From: "Graves, Dave" <GravesD(a)US-Herndon-NSI.mail.SAIC.com> > To: "'operations(a)host.net'" <operations(a)host.net>, > "'hostmaster(a)host.net'" <hostmaster(a)host.net> > Subject: Domain Name NASA.COM > > July 11, 1997 > > > SENT VIA EMAIL operations(a)host.net <mailto:operations@host.net> AND > hostmaster(a)host.net > AND FEDERAL EXPRESS > > The Epicenter Network > 1344 Broadway, Suite 211 > Hewlett, NY 11557 > > SUBJECT:Domain Name NASA.COM > > Dear Domain Name Registrant: > > Network Solutions, Inc. (Network Solutions) is in receipt of a July 10, > 1997, notice from the National Aeronautics and Space Administration > (NASA) regarding your registration of the domain name NASA.COM. NASA > has alleged that Network Solutions is "aiding and abetting this > registrant to maintain [your] domain name registration", and has > demanded that Network Solutions "cease and desist allowing the > registration of the Internet domain name NASA.COM." A copy of NASA's > letter is enclosed for your information. > > As the registrar of domain names, Network Solutions has neither the > knowledge of, nor the authority or responsibility to police the content > of registrants' web sites. Accordingly, Network Solutions has no > comment upon, nor does it consider relevant, NASA's demand as it > pertains to the content of your web site. > > Network Solutions is seriously concerned, however, that The National > Aeronautics and Space Act of 1958, as amended, clearly prohibits the > knowing use of the letters "NASA" in connection with a product or > service "in a manner reasonably calculated to convey the impression that > such product or service has the authorization, support, sponsorship, or > endorsement of [NASA] which does not in fact exist." The enclosed > letter clearly sets forth NASA's opinion that the registration and use > of the domain name NASA.COM, without the authority or approval of NASA, > constitutes a violation of United Stated federal law. See 42 U.S.C. > 2459(b). > > In addition, Network Solutions is in receipt of a July 11, 1997, letter > from the Federal Trade Commission (FTC) regarding your registration of > the domain name NASA.COM. The FTC holds the opinion that the "continued > registration and use of NASA.COM . . . in [its] current format is likely > to mislead consumers in violation of the Federal Trade Commission Act." > It is also the FTC's opinion that "it is inappropriate and perhaps > unlawful for [Network] Solutions to continue to provide domain-name > assistance to [the registrant], knowing that current use of [this name] > likely violates federal law." A copy of the FTC's letter is enclosed > for your information. > > Network Solutions neither violates federal statues, nor acts in any > manner which does, or creates the appearance that Network Solutions aids > and abets such violations. Accordingly, in response to the notice > provided in the enclosed letters and upon advice of counsel, Network > Solutions is immediately deactivating the domain name NASA.COM. > > Sincerely, > > > David M. Graves > Internet Business Manager > > Enclosures (with Federal Express only) > > Cc:Philip Sbarbaro, Esq. (w/o enclosures) > Alan Kennedy, Esq. (w/o enclosures) > Paul Luehr, Esq. (w/o enclosures) -- jamie g.k. rishaw dal/efnet:gavroche Internet Access Group 'whois JGR2' for PGP keyID/Fingerprint __ Network Operations/TSD DID:216.902.5455 FAX:216.623.3566 \/ 800.637.4IAGx5455 "The machine's fine. It just doesn't work." -dan(a)nic.net

12 13

Re: Internet Backbone Index
by garyz＠savvis.com 13 Jul '97

13 Jul '97

Sean, we only have 805 Mbps of possible bandwidth to other networks. I not sure what you mean by a better engineered network. If you only have a routed network, not sure this is the best way to engineer a network today. Switch technology can do alot of good things. The model does fall apart if you say you are only going to buy from these three to five, but it does not fall apart if you watch your traffic and you buy from whom your traffic is going to. The idea is not to engineer poor peering in the MAEs and NAPs with a bunch of networks. Buy and manage from the networks you are going to and you will engineer a better product. I still think that if you really looked at a normal NSP traffic that the bulk of it is with 5 to 8 networks. I some what agree with some of what you say, that a peer could be a good thing if it is private and not in a shared peering in the MAEs and NAPs. You talk about engineering good networks, why then use something that is unmanaged and uses poor technology and poor engineer designs in a MAE or NAP? Where is most of the packet lost on the internet? MAEs and NAPs. Where does most of the latency come from? Routers. MAEs and NAPs are yesterdays ideas that everyone who has bought into the concept now has to live with it, they did not build the business around the fact they had to pay and manage to provide good service. The time is almost upon us that you pay for what you get on the internet and you must pay for the bandwidth that you use, not what you can over subscribe until your customer begin to leave. This is a tough model, few will make it. Some day the internet will use measurements, such as QOS and customer will be willing to pay for those who have engineered their networks to provide QOS. I only have one more question for you; how many router hops, on your network, from New York to Los Angeles? If it is more than 1, then tell me what your latency is from end to end. Let's compare, shall we. Gary Zimmerman V.P. of Network Engineering Savvis Communications Corp. email: garyz(a)savvis.com http://www.savvis.com Office: 314.719.2423 Address: 7777 Bonhomme Suite 1000 St. Louis, MO 63105 ---------- > From: Sean Donelan <SEAN(a)SDG.DRA.COM> > To: nanog(a)merit.edu > Subject: Re: Internet Backbone Index > Date: Wednesday, July 09, 1997 5:45 PM > > >SAVVIS. Fortunately Our target markets are not just libraries and other > >information providers, it's EVERYONE that needs a T1 and above connection > >to the Internet. How many cities are you in Sean, where are DRA's POPs for > >customers to access? How much bandwidth does DRA have to get these > >customer to other network? Let's compare bandwidth shall we. > > DRA tries to do one thing well, rather than a lot of things not so well. > > Like all things, the correct answer is "It depends." If you are interested > in the DRA network geography, a pretty picture of the DRA North American POPs > is at <http://dranet.dra.com/dranet.html>. BTW, all those locations are up, > operational, and have DRA owned and operated equipment in place. DRA's > international offices are located in Montreal Canada, Paris France, and > Melbourne Australia. The primary NOC is in St. Louis, MO and backup NOC > operates out of Monterey, CA. > > Since DRA also has a lot of private connections (in the old NSFNET AUP days > these were called 'backdoor' connections) calculating total bandwidth is a > bit confusing. If you follow the AGIS bandwidth counting method, DRA has > about 268 Mbps of possible bandwidth to other networks through public and > private inter-connects, although DRA doesn't have any single link faster > than 45 Mbps. However, bandwidth is rarely the problem. I've found a > well engineered 56Kbps connection outperformed a DS3 port into a poorly > engineered network. > > >When 80 to 90 percent of the Internet traffic is to MCI, SPRINT and UUNET > >then our model is the right way to build this, not to try and see how many > >peering agreements one can get. > > Except the model falls apart if 50% percent of the your Internet traffic > isn't just to MCI, Sprint and UUNET, as in DRA's case. If you want to > get anywhere off the commercial beaten path, like many of our customers > do, things quickly get very bad if you stick with just those three > providers. Most of our backdoor connections exist exactly for that reason. > > Look at the KEYNOTE test sites. Although it might appear heavly weighted > towards MCI, SPRINT, and UUNET (23 out of 35 sites), the network is never > so simple. It works well as long as you are in a US city going to another > US city. But looking at the Bell Canada graph, things don't work as well. > Hint: If you are trying to reach a Canadian audience, don't put your web > server in a US city. We've had a private 'backboor' connection to the > University of Toronto for years for precisely this reason. > > Further, about half the Keynote test sites seemed to have alternate > connections. I couldn't figure out the numbers until I started doing > traceroutes, and then things started making more sense. You'll discover the > best route isn't always through MCI, Sprint or UUNET. Those little exchange > points can make a difference. > > St. Louis, MO MCI 207.230.62.16 Cybercon/Internet 1st > $ traceroute 207.230.62.16 > traceroute to 207.230.62.16 (207.230.62.16), 30 hops max, 38 byte packets > 1 StLouis22-e3.dra.net (192.65.218.2) 200 ms 10 ms 0 ms > 2 stlouix.starnet.net (198.32.132.12) 10 ms 20 ms 0 ms > 3 e0-1-2.starnet2.starnet.net (199.217.255.97) 70 ms 10 ms 10 ms > 4 router.cybercon.com (199.217.252.58) 10 ms 20 ms 10 ms > 5 207.230.62.16 (207.230.62.16) 20 ms 10 ms 10 ms > > It is amusing to look at AGIS's chart in the Boardwatch directory. The > graph dramatically demostrates how badly AGIS's tough-line peering policy > hurt it in this test. Refusing to peer with CRL or Goodnet wouldn't have > changed CRL's or Goodnet's performance very much, but it does appear to > hurt AGIS's performance. Maybe Sprint and MCI might want to re-think their > peering policies also. On the other hand, I've never heard of CompuServe > turning down an opportunity to inter-connect their network with other > networks. > > I'm a pragmatic person. DRA has connections to several exchange points, > and has many more private 'backdoor' connections to other networks. DRA > even buys (gasp) service from a few other providers, and also sells service > to a few other providers. All work well, customers are happy, and DRA is > profitable. Let's compare balance sheets shall we? > -- > Sean Donelan, Data Research Associates, Inc, St. Louis, MO > Affiliation given for identification not representation

10 16

Re: Internet Backbone Index
by Scott Bradner 13 Jul '97

13 Jul '97

> Doesnt an IP Switch have lower latency and higher pps? well, since many of the backbone routers have been able to fill their pipes for quite a while what difference would the "higher pps" make? If you are already limited by the wire... as far as latency goes, a rather slow router has a few hundred micro seconds processing latency - and a "level 3 switch" might have half that but even if it had 0 latency (kinda hard to do but for the sake of argument) you would only save a few hundred microseconds per hop it would take rather many hops to equal one transit latency on most networks - and could not be found in the interupt-to-application latency on the reciveing end. buffering, which is common between switches & routers, has a far larger impact. Scott

1 0

RE: Internet Backbone Index
by Rodney Joffe 13 Jul '97

13 Jul '97

Heh..... To throw more oil on this fire, here's what one of our customers is using to beat us over the head with! http://www.internetweather.com Rodney Joffe Chief Technology Officer Genuity Inc., a Bechtel company http://www.genuity.net

1 0

Re: NSPs and filters
by Vadim Antonov 13 Jul '97

13 Jul '97

Daniel Senie <dts(a)proteon.com> wrote: >Would you care to explain just exactly WHY a CAM type architecture could >not filter packets WHILE BEING RECEIVED from a given type of wire? This >is NOT an unsolveable problem. Perhaps you've been blinded by the >current architecture of the equipment you've invested in to date. I didn't say this problem is not "solveable". I said that the solution is known, but to my knowledge nobody implemented or plans to implement it in hardware (and for several good reasons, too). --vadim

1 0

Re: NSPs and filters
by Vadim Antonov 13 Jul '97

13 Jul '97

randy> So, at POP X, I take in maybe 100 prefixes, with maybe 1000 randy> at some POPs. How do I build and maintain that filter list, alan(a)mindvision.com (Alan Hannan) wrote: > The same way you build and maintain routing filter lists for the > prefixes you take in. Bzzt. Routing filter lists are applied to routing updates. Packet filter lists are applied to packets. Big difference. 1000-entry packet filter will slow any existing router down to crawl, and practically all future boxes won't do any better. --vadim

3 2

Re: NSPs and filters
by ice9 13 Jul '97

13 Jul '97

On Fri, 11 Jul 1997, Jon Lewis wrote: > Why is it that the NSPs I've encountered refuse to do any sort of sanity > filtering on their customer connections? i.e. If UUNet knows that FDT has > only 205.229.48/20 and 208.215.0/20, why should they let me send traffic > through their network with random source addresses? > > FDT has been the target of forged source address UDP attacks for the past > 2 days. It's all being stopped at our router that takes our UUNet T1, but > the extra T1 traffic is causing UUNet's usually unreliable network to be > even less reliable, and we've lost connectivity to UUNet several times > this evening. Its not feasible to filter packets on customer gateway routers. When you impose a packet filter on a GW router customer interface, all packets destined to that customer have to be matched to an access-list and then forwarded down the pipe or dropped. This increases the load on the router CPU, because it is used to switching the packets. Now you have to analyze each packet which takes up CPU time. This is not a nice thing to do to a router, especially while the router is trying to keep up with 50 other customers... And if more than 1 customer wants this type of service, you start really feeling the load. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ice9(a)paranoia.com http://www.paranoia.com/~ice9 My opinion may not reflect that of any living person, but its the only one that counts!! main() {for(;;fork());} =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

7 8

More on ingress filtering
by Daniel Senie 13 Jul '97

13 Jul '97

I'd encourage folks to read the draft that Paul Fergusen and I have written on this subject. We talk about some things that COULD be implemented that would greatly help with source address problems. One of these would be a change to your remote access servers, and would be quite straightforward for vendors to implement: For DIALUP users, provide an option (would need to be per user) to require the packets arriving from that dialup user have the IP address that was assigned by the RAS server when the user dialed up. At modem or ISDN speeds, the packet rate is QUITE low, and this filtering should NOT be a CPU overhead problem. A SINGLE compare of a 32 bit integer is ALL we're talking about here. The reason to make this configurable per-user is to allow dialups by remote routers that are routing separate nets or subnets behind them. In those cases, a more complex filter would be desirable, but perhaps somewhat less necessary. It is my suspicion that a vast majority of the intentional source IP address trouble comes from dialup users who can leap from provider to provider. Filtering should be done as close to the actual customers as possible. I do understand the difficulty with the present core routing equipment when trying to filter large amounts of traffic, but that doesn't apply to routers at the periphery of the net. As someone else suggested, even if some of the core networks can't do all of their own filtering, they COULD add that as a requirement for those networks that are fed from them, and they from their downstreams, etc. until the T1 line, or 56K leased line, or dialup modem line at the periphery IS FILTERED. Daniel Senie OpenROUTE Networks, Inc. -- ------------------------------------------------------- Daniel Senie dts(a)openroute.com OpenROUTE Networks, Inc. http://www.openroute.com/ 508-898-2800

1 0

Re: NSPs and filters
by Vadim Antonov 13 Jul '97

13 Jul '97

randy(a)psg.com (Randy Bush) wrote: >So, at POP X, I take in maybe 100 prefixes, with maybe 1000 at some POPs. >How do I build and maintain that filter list, and how long does it take each >packet to get through it with a router that also does real routing? That can be done, and is relatively easy. Not in cisco's or any other hardware-assisted box, though (figuring out why is left as an excercise to the reader :) My estimate is that the total filtering overhead is at about 2.5% for a "software" router. And, yes, i do plan to implement that kind of filtering. --vadim PS. Hint: i described the technique for doing that in a mailing list, year ago.

1 0