January 1999 - Test - lists.nanog.org

Good work, MCI!
by James Rishaw 26 Jan '99

26 Jan '99

It's now been 7 days one hour since I opened the "critical" priority ticket with MCI security with no callback :-) Three calls to the noc with ticket "18" got nothing but laughs.. "We dont have tickets that low" .. :-p Growing pains? :-( -- jamie rishaw (efnet:gavroche) American Information Systems, Inc. jamie at ais dot net infrastructure engineering

2 1

Re: InterNic Responds
by Dean Anderson 26 Jan '99

26 Jan '99

Interesting. They claim to get 30000 registrations a day, 20000 bogus. That isn't very many. Interesting that they claim the speculators are "spammers spamming their system with bogus and incomplete registrations". Seems like speculation and denial of service are separate things. I smell something from NSI. But, since some people disputed what I and 'half a million' others think about the difficulty and performance limitations of a registration system, I'll "put up" instead. I'll supply the development system that will run on Linux with Oracle 8 (I'll spend the $295 for Oracle/Linux) The devel system will be a dual P233 with Redhat 5.2. (Already have this) This will allow the software to be moved to a Sun with Oracle Enterprise, which has the features required to handle very large tables, replication, etc. It will be able to be a "highly available, commercial quality system". If you are interested in writing code to generate zone files, modify whois/rwhois server to use oracle/odbc, make web pages, send me mail. (I'll write the email parser) I don't think this will take very long, even part time. I expect that the devel system should be able to handle the 30000 registrations per day. --Dean At 05:20 AM 1/26/1999 -0800, Henry Linneweh wrote: >Speculators Inundate InterNIC >http://www.wired.com/news/news/technology/story/17522.html > >Henry R. Linneweh > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

FW: Concert Network Maintance - 8.5 Upgrade Domain 4 (UK)
by Regan, Sharon 26 Jan '99

26 Jan '99

-----Original Message----- From: BrownLJ(a)stentor.ca [mailto:BrownLJ@stentor.ca] Sent: Tuesday, January 26, 1999 1:36 PM To: Regan, Sharon Cc: GreenKB(a)stentor.ca; GodardD(a)stentor.ca; WongR(a)stentor.ca; SavardCR(a)stentor.ca; MenardPA(a)stentor.ca; McfetridgeM(a)stentor.ca; FournierLC(a)stentor.ca; SchroederJP(a)stentor.ca; ShurtliffMJ(a)stentor.ca; LockeMW(a)stentor.ca; WarrenGA(a)stentor.ca; PackmanJ(a)stentor.ca; ReilleyJA(a)stentor.ca; RochfordM(a)stentor.ca; GirardLP(a)stentor.ca; BirdBR(a)stentor.ca; WarrenL(a)stentor.ca Subject: Concert Network Maintance - 8.5 Upgrade Domain 4 (UK) Ms. Regan; On February 12th, 1999, Concert will be upgrading Subnet 4 (UK) to System Software 8.5. This upgrade is to begin at 23:00 GMT (18:00 Eastern) with a maintenance window duration of 10 hours. The initial impact to the Frame Relay network will be minimal; the expected downtime will be less than 45 seconds for most nodes and up to 2 minutes of data interruption for some. There is also a possibility of reroutes, although the chance is small and would be like any other reroute that would occur upon a trunk failure. There is an expectation that approximately 10% of the PVC's will experience failures for which a script will be executed, on each node, to correct the problem. All issues that have been observed with the Subnet 5 (Germany) upgrade have been addressed in this script and it is expected to take approximately 2 hours to complete. The lower the number of PVC's on a node, the quicker the reroute time. The reroutes will be noticeably faster as System Software 8.5 supports trunk based loading. Please note however, by resetting connections throughout the Subnet, each PVC will be impacted twice. This is unfortunate but unavoidable in order to accomplish the upgrade. Regards, Linda J. Brown CCSC - Concert Canada Service Center Concert Change Management 613-781-9382

1 0

Re: Who uses RADB/IRR?
by briand＠spare.de.teleglobe.net 26 Jan '99

26 Jan '99

> DA> I started looking at the RADB, but haven't got ourselves setup yet. Does > DA> anyone actually deny routes which aren't listed in the RADB? I guess what > DA> I'm really asking is how important is it to be in the RADB? Does it get > DA> more important sometime soon? Yes, for peers and customers. Pretty important, at least for international connectivity (which is what we provide). Yes. (See below.) > "Important" is hard to define. People tend to register in the RRs and make > use of the RSes because: > > [1] It's the right thing to do to publish public policy. It's like > signalling before changing lanes. > > [2] It makes life easier on yourself and the community that participates in > configuring off the RRs. [3] One word says it all: scaling. The use of the RADB to register routes and routing policy, permits the automated generation of all types of ACLs, independent of the size of the ACL. Manual methods do *not* scale, and while authentication of the contents of the RADB are questionable, this is addressable and only requires more people to update their maintainer objects (to use more-secure methods). Here is the crux of the argument why anyone would *require* their peers to register: - if you filter your customers by hand, your filters are suspect - if you filter your customers by RADB, not so much - if you don't use the RADB for customer filters, I'm not comfortable trusting your routes blindly, and want to filter you - if you don't filter at all, I *insist* that I filter you - I don't want to build a filter for you, which is orders of magnitude bigger that your filters for your customers, by hand - thus, I want you to use the RADB - but, if you use the RADB, you can automate your customer filters! So, if you use the RADB to build your customers' filters, I *could* consider trusting you, but at that point it is trivial for me to build a filter for you. If you don't, I can't trust you, and can't easily filter, so I won't peer with you. (!!) Teleglobe (ie, us) use the RADB for building ACLs for *all* customers and peers. (Well, obviously not for statically-routed customers, but those are registered from our AS.) If someone doesn't register or maintain their as-macro, for example, we maintain our own IRR, irr.teleglobe.net, and make a private "snap-shot" of this peer's set of AS's, and build a proxy as-macro, which is immediately out-of-date, but is updated periodically, and is a heck of a lot better than running unfiltered. This is the only thing we do that even vaguely resembles manual support for non-registrants. We require that route objects themselves be registered, regardless, in order to accept routing updates. We have no interest in attempting to keep the whole internet proxy-registered on a per-route-object basis! While we currently maintain at least one transit relationship, this will still permit connectivity to be established via such transit providers; once we switch to pure-peering for connectivity, this registration *will* be very important if you want to access any of our customers. We currently represent approximately 15% of the reachable Internet, and our growth rate is greater than that of the general industry, ie. expect this percentage to increase. We don't want to force our policy on anyone else, but we insist on not being forced by others into changing our policy. Our policy is to filter. Our filters use the RADB. Anyone who wants to peer with us, either at NAPs or via private link, must register. If they don't keep the RADB up-to-date, they will at some point announce routes that we filter out. This is their problem, not ours. If anyone wants to register but is concerned about public visibility, an option is to run a private IRR, and permit your BGP peers to query this IRR. However, if you provide transit to anyone, they would need to be registered on either your IRR or a public IRR, and if you get transit from someone, their peers will need access to your info as well. These all point in the direction of public IRR's as the right way to go. > DA> I would also tend to think [based on limited BGP knowledge] that it would > DA> only be a problem if your direct upstream used the RADB or if your upstream > DA> is RADB filtered by their peers. Is this true? Or if *their* upstream is filtered by peers, etc, etc, up to the "tier 1" providers. Of the big tier 1's, I believe Sprint is the only non-registrant of significance (ie numbers of routes in double-digit percent of global table.) If this ever changes, then global reachability could require registration, period. > You forgot the word "exclusive". Many providers in addition to configuring > off the RR also manually configure in (by hand) those who do not have > registered policy in the RRs. I consider this suboptimal administrative > practice but you do what you have to. Refusing to manually update non-registered networks, is a significant lever to "encourage" the other guy to register. If enough people join this effort, *everybody* wins. Be advised, however, that filtering *big* networks takes lots of space in your router configs, and even with "service compress-config", you can hit the wall pretty easily, and eventually need to save configs onto flash or a local TFTP server (and don't forget to change boot buffersize!). However, this is no reason not to filter, it is simply a change in procedure needed while Cisco ships pitifully small NVRAM on their core router products. ;-) > And for those who only do > aspath-based filtering... keep knocking on wood. |8^) For those who do not grasp the subtlety of this last statement: More than once, in recent memory, has a clueless small ISP done the unthinkable of redistributing BGP into an IGP, and back into BGP, thus appearing to announce the entire Internet from their own AS. Allowing these routes without filtering, resulted in major blackholing/meltdown of big pieces of the Internet, notably those ISPs providing transit to the small ISP and its ISP without filtering. Those who do not learn from history are doomed to repeat it. Those who do not learn from history are doomed to repeat it. Those who do not learn from history are doomed to repeat it. In case anyone is concerned about operational impact of filtering: The filtering we discuss here is filtering routing updates, not filtering of packets. Routing updates generally represent a negligible load, and filtering is inexpensive in this regard. The only times where routing updates are a big load, is the *precise* time when you really want to be filtering out the updates, eg the redistribution situation above. Brian Dickson Teleglobe

3 2

InterNic Responds
by Henry Linneweh 26 Jan '99

26 Jan '99

Speculators Inundate InterNIC http://www.wired.com/news/news/technology/story/17522.html Henry R. Linneweh

1 0

RE: SMURF amplifiers
by David Alejandro Hernandez Alonso 26 Jan '99

26 Jan '99

Also check http://www.netscan.org David. --- David Alejandro Hernandez Alonso INFOSEL Network Operations Center Tel.- +01 52-8 318-8777 dhernand(a)infosel.com.mx PGP Key/ID 1024/0xF6172E65 Fingerprint: 0016 CD82 63C8 47D2 841B AD36 8E29 DDF7 -----Original Message----- From: Martin, Christian [SMTP:CMartin@mercury.balink.com] Sent: Lunes 25 de Enero de 1999 2:57 PM To: 'Alex P. Rudnev'; 'nanog(a)merit.edu' Subject: RE: SMURF amplifiers www.powertech.no/smurf > -----Original Message----- > From: Alex P. Rudnev [mailto:alex@Relcom.EU.net] > Sent: Monday, January 25, 1999 10:55 AM > To: nanog(a)merit.edu > Subject: SMURF amplifiers > > > Hi > > Someone here have collected the list of smurf amplifiers? I > have got a > list used by the working hacker (and can send this list by > e-mail) if you > need more addresses into your collection. > > Alex. > > Aleksei Roudnev, Network Operations Center, Relcom, Moscow > (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 > 095) 230-41-41, N 13729 (pager) > (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax) > > --- David Alejandro Hernandez Alonso INFOSEL Network Operations Center Tel.- +01 52-8 318-8777 dhernand(a)infosel.com.mx PGP Key/ID 1024/0xF6172E65 Fingerprint: 0016 CD82 63C8 47D2 841B AD36 8E29 DDF7

2 1

aads renumbering rumor and implications
by Randy Bush 26 Jan '99

26 Jan '99

i am told that aads seems to be planning to renumber, seemingly as there is some service charge for the address space they do not wish to pay. please correct/confirm. should this be true and a real issue, o will folk be happy renumbering at larger exchanges? o does anyone see why the exchange address space needs to be globally routable? randy

12 14

The .COM People...
by Bryan A. Ignatow 25 Jan '99

25 Jan '99

-----BEGIN PGP SIGNED MESSAGE----- Did anyone else receive the 4 sheet, color, advertisement from NSI (The .COM People) customized in three places with a domain name that you should register with them? Did anyone else's say that you should hurry up and register the domain name for your company before someone else does? Did anyone else get one for a domain that was already registered (and shows up in whois)? Did anyone else get this at their home address rather than their work address? Does anyone else think that NSI should have run their list of domains they were sending out against their database and remove the ones that were already registered? Just wondering... - --- Bryan A. Ignatow Sr. Technical Analyst ignatow(a)sprintparanet.com Sprint Paranet (Intranet Only) http://general.srv.paranet.com/~baignato -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.0.2 iQEVAwUBNqyIq9nHymeMoGNHAQEeZAf/YXGQbVtUA3phe/bFNPnmQlkkSVxLDBdu /FHZZwajxZtrriVP/yIhLkuy3Rohk2r7Z9k7JoZA+aEf5kDYBDHjrdLZ2uOuzUrO D2bBeuobzPpY/ro3Ip/rnQJRW27/U4T7DCo4AhLYxf554EEBMILCpfiXh8/hprf0 ISv67HSR2W+nfkrANS9sVcbY4/9pRXgbmhW9zhpx12+bxEpo63mGbiWvXRwTLfIV UHb2eystLyfnK7R4IFHA5CpGXObry8kmbXPt0Itery8X0R7Gd/yCosfXcF5gqwIm y9qMvj8gJpwAvNtVMzMWw544fvE6tb5wWmspUfvXqfORhjl0gUUGqA== =ROU6 -----END PGP SIGNATURE-----

2 1

Re: Incompetance abounds at the InterNIC
by Dean Anderson 25 Jan '99

25 Jan '99

Ok, I thought I would stay out of this. It must be off topic. "Pay-First" isn't a simple solution. I'll explain why. First, what do speculators do? They register a domain and watch the news for companies or products that might be able to use the domain. If they find such a target company, they pay for the domain and try to sell it to the target. If not, they let the payment slip. Perhaps in 30 days, they re-register the domain if it still looks attractive. Second, the current system evolved because of the requirements to reject duplicates, and immediately notify the registrant about a duplicate and allow registrations to go forward before "the check clears". Duplicates might come in seconds after the first registation. Thing are done on the "internet" time scale vs. the "telco" time scale. Third, the idea that it only takes minutes or a few days to process a payment is wrong. It takes up to eleven business days to clear a check. A week to mail, and a week to process is not unreasonable, which quickly adds up to about 30 days. Credit card payments can take 60 days to clear, since they can be refuted when it appears on your bill. So, with that in mind lets look at what it would take to implement the "pay first" idea. To make sure that payment is received, all registrations would have to wait until the check cleared, or the credit card charge wasn't refuted. That means you might wait 30 to 60 days for the registation. That would be unacceptable. No one wants to wait until the check clears. Also note that this restriction doesn't affect speculation at all. Speculators don't care if the domain can't be registered for 30 days. They want 30 days to decide whether to keep it or not. But what net user wants to wait 30 days for a registration? Probably very few. Ok, so we rule that out. Lets say we modify that a bit, and give the first registrant the domain right away, and then if payment doesn't clear in 30 days, you revoke it. The second registrant is notified immediately of a conflict. (You might recognize this as the current system) This delay can be used by speculators to speculate on useful domains. So we aren't quite happy with this. Lets modify this a bit further, and say we keep a queue of registrants. If the first registrant doesn't pay, it goes to the second registrant. Now the second registrant would have to wait 30 days to know whether they get the domain or not. In that time, they probably would change their mind and select a new name which can be registered right away. So they might not want it in 30 days. The third registrant would have to wait 60 days. Now NSI has the expensive logistical overhead of keeping track of this queue for each registration. Have speculators been limited? No. Speculators can still form chains of organizations to make multiple registrations of the same domain. This would work very well unless someone got in the middle of this chain. This is probably even better for speculators, since now they can "reserve" a domain for as long as they want, merely be creating a chain of companies to register the domain many times. Lawyers are good a creating a chain of companies. So, is it possible to have immediate notification of duplications, registration before payment completes, and still reject speculation? It doesn't appear so. I'll go on record here that in my opinion, speculation is a unavoidable "feature" of the system, which may be somewhat undesirable but one that cannot be removed. The reason it cannot be removed is because of the delay involved in completing the financial transaction, and the possibility that such transactions can be terminated. We can't change the banking system to prevent domainname speculation. Further, there are legit activities the look very much like speculation. I don't know how many of you have been involved with startups, but I have advised a few. Its a very hectic time as the principals try to select and register a name. Figure out trademark conflicts, etc. Often the business idea, image, and focus change greatly during this initial period. They typical register a dozen domains or more. Some are rejected. Others they get. Once they select one that they got, they usually don't want the others. My point is that there is a lot of legitimate "register, cancel-no pay" activities. It is precisely these same activities that speculators use for speculation. While speculation may produce some additional load on NSI, there was also a time when people only bought and sold stock with the intention of buying or selling a company, rather than speculating about its future stock value. So speculators produce tremendous load on stock exchanges. However, in doing so, they now provide much of the capital to finance business. I don't expect domain speculators to become the equivalent of stock speculators, but they really aren't any different from speculators in land, bonds, currency, grain, or anything else. They are part of the market system. Speculators in other areas don't enjoy the gratitude of the "regular users" of those areas either. Farmers generally hate land speculators. But they realize they have to live with that. So I think the solution is to build a system that scales well to millions of transactions per day, regardless of the ultimate purpose for those registrations. The per transaction cost becomes trivial, and the cost of speculation is likewise minimized. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

5 4

RE: SMURF amplifiers
by Martin, Christian 25 Jan '99

25 Jan '99

www.powertech.no/smurf > -----Original Message----- > From: Alex P. Rudnev [mailto:alex@Relcom.EU.net] > Sent: Monday, January 25, 1999 10:55 AM > To: nanog(a)merit.edu > Subject: SMURF amplifiers > > > Hi > > Someone here have collected the list of smurf amplifiers? I > have got a > list used by the working hacker (and can send this list by > e-mail) if you > need more addresses into your collection. > > Alex. > > Aleksei Roudnev, Network Operations Center, Relcom, Moscow > (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 > 095) 230-41-41, N 13729 (pager) > (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax) > >

1 0