- Test - lists.nanog.org

Fixing "clueless ISPs" etc etc etc, typical NANOG topic answered decisively
by Sean Doran 03 Oct '96

03 Oct '96

I thought this would bring a bright moment to everyone's Thursday. Sean. ------- Start of forwarded message ------- From: James Chellis <jchellis(a)well.com> Newsgroups: alt.internet.guru Subject: Internet Certification Date: 2 Oct 1996 05:19:04 GMT Organization: The WELL Message-ID: <52su08$28j(a)filth.well.com> Microsoft and Novell recently began looking into certification for Internet expertise. Microsoft decided to integrate material related to the Internet into existing MCP programs. Novell took a different approach; they created a new certification called the Novell Internet Professional. Do you see a value in Internet certification? Would you want to be certified in this area? What should the subject matter focus upon (since the Internet is so vast and quickly changing)? Are Microsoft, Novell,and Netscape the right companies to do this, or would a more neutral third party be more appropriate? Just a few questions I'm curious about. Please feel free to reply to this list or to me personally. Thanks. James ------- End of forwarded message -------

4 3

Re: GES (jvnc.net) as the purveyor of bad routing advertisements
by salo＠msc.edu 03 Oct '96

03 Oct '96

> Date: Wed, 2 Oct 1996 20:17:51 -0400 (EDT) > From: Gordon Cook <cook(a)netaxs.com> > To: nanog(a)merit.edu > Subject: GES (jvnc.net) as the purveyor of bad routing advertisements > [...] > I believe that there is ample evidence that the folk at Princeton have to > be very aware of the nature of their provider. Yet I have seen no signs > that Princeton is ready to pull up its stakes. > [...] This begs the question of, if Princeton did "pull up its stakes," where it would replant them. o How should Princeton, for example, measure the "quality" of its NSP? How can Princeton be assured that another NSP would be "better?" o Do you have any measurements which provide an indication of the relative quality of the major NSPs? o Do you have a ranking of the quality of the major NSPs based on, (in the absence of quantitative evidence), informal evidence? o Do you think the work of the IPPM group is likely to help? Why or why not? -tjs

2 1

Re: Fixing "clueless ISPs" etc etc etc, typical NANOG topic answered decisively
by Justin W. Newton 03 Oct '96

03 Oct '96

At 06:06 AM 10/3/96 -0700, Sean Doran wrote: > >I thought this would bring a bright moment to everyone's Thursday. > > Sean. > >------- Start of forwarded message ------- >From: James Chellis <jchellis(a)well.com> >Newsgroups: alt.internet.guru >Subject: Internet Certification >Date: 2 Oct 1996 05:19:04 GMT >Organization: The WELL >Message-ID: <52su08$28j(a)filth.well.com> > >Microsoft and Novell recently began looking into >certification for Internet expertise. Microsoft decided to >integrate material related to the Internet into existing >MCP programs. Novell took a different approach; they >created a new certification called the Novell Internet >Professional. Gee I wonder If they will come up with a side certification Packet Layer Engineer. The we could all go out and become NIP PLE's. Justin Newton Internet Architect Erol's Internet Services

1 0

Re: New Denial of Service Attack on Panix
by Paul Ferguson 03 Oct '96

03 Oct '96

At 11:52 PM 10/2/96 -0400, Dima Volodin wrote: > >I.e. a single compromised host in the "permitted prefix filter range" >can cause as much trouble as the current attacks. Granted, it's a bit >easier to track down a host like this, but eliminating the majority of >compromisable hosts is even more difficult than global implementation of >the cited document. The bitter irony is that non-implementation of this >draft will most probably corelate with presence of compromisable hosts. > Well, that's true, but it's a different facet of the same problem. The draft only attempts to solve what it is that we can solve be ingress filtering. Solutions using firewalls or proxy devices which defat this type of attack are a Good Thing, but if everyone does ingress filtering, a large percentage of this problem disappear. - paul >Thus host-(and firewall-)based solutions are at least as important as >the ingress filtering. > >As of the evidence of these attacks - they were evident long before the >current talking. > >Dima

2 1

Network World
by Hank Nussbacher 03 Oct '96

03 Oct '96

Network World has a 2 part in depth article about the infrastructure of the Internet as a sort of "health" report in Sep 16 issue (part 1). Many people in NANOG quoted. Not a bad article except for ... "Carriers are beginning to mandate use of Complex Inter Domain Routing address blocks, which are analogous to area codes..." Those that have an acct on www.nwfusion.com can find it at #9603. Hank

1 0

Re: New Denial of Service Attack on Panix
by Paul Ferguson 03 Oct '96

03 Oct '96

At 05:32 PM 10/2/96 -0400, Dima Volodin wrote: > >Anyway, filtering packets with SRC addresses known to generate >ICMP_UNREACH at the earliest possible stage might be a good idea. > Well, this is what we [collectively] have been talking about doing as a 'best current practice' since the attacks became evident. Also, see: [snip] A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Network Ingress Filtering Author(s) : P. Ferguson Filename : draft-ferguson-ingress-filtering-00.txt Pages : 6 Date : 10/01/1996 Recent occurrences of various Denial of Service attacks which have employed forged source addresses have proven to be a troublesome issue for Internet Service Providers and the Internet community overall. This paper discusses a simple, effective and straightforward method for using ingress traffic filtering to deny attacks which use "invalid" source addresses; prefixes which are not being legitimately advertized to the Internet via a particular service provider gateway. [snip] Once the document is revised to an acceptable [rough consensus] draft, I'd like to see it become published as a BCP. - paul

2 1

Re: Peering versus Transit
by Eric D. Madison 03 Oct '96

03 Oct '96

Peering is becoming a real touchy issue. Most of the larger providers don't really want to peer with anyone else because they can't really handle the extra traffic, or they are afraid of peering with a company that doesn't have the technical staff that is truly knowledgable about backbone routing. With the major peering points getting more accessable to smaller providers, this becomes even more evident. And to be truthful, it can be understood. Their have been quite a ISP's get temporarily shutdown at one of the MAE's because of "errors" in routing procedures. No names mentioned, but for example about changing peering requirements. One of the larger providers said they required three meet points + 2-3 private interconnects at DS-3 or higher... when we said that we could do that by the end of November, they said, "Really?.. that is going to cost both companies a large sum in hardware and DS-3 local loop fees." They changed their requirements to be just three meet points. If you look at the monthly cost of buying a DS-3 from MCI, Sprint, UUNet, AGIS, or PSI, it is much cheaper to get a connection to a MAE, and trying to get peering. Eric At 10:07 PM 9/30/96 -2900, you wrote: > > Sean, > > It almost makes one think the evil telcos are plotting a new > service/product that would be damaged by legacy contracts, eh? > > -alan > internet engineer for the enquirer? > >> >> >These days peering agreements are business deals. >> >> They have always been business deals. I'm just amazed as some of the >> lengths some providers go to justify what should be a plain-old >> business decision. If you don't intend to peer with another provider, >> just say so. The only providers I tend to get really peeved at are >> the ones that keep changing their stories. >> >> AGIS told me in January '96 that their peering agreement was being >> revised by their lawyers and they would send it as soon as it was >> ready. Since I hadn't heard from AGIS in a while, I sent another >> note to AGIS and was told they now require DS3 connections to four >> exchange points. No idea what happened to that peering agreement >> from January. >> >> MCI told me in February '96 that their peering agreement as >> on hold pending review by their lawyers and they would let me know >> when it was ready. The last response I've received from MCI is the >> person in charge of peering had changed. No word from the new guy. >> And MCI took their peering policies off their web page. No idea >> what happened to MCI's policies in the mean time. >> >> Since March of 1995 (yes '95) I've gone through three product managers >> for Sprintlink who have told me their peering agreement is on the way, >> under legal review, on hold, or being revised. DRA met Sprint's peering >> 'requirements' a couple of times now. But by the time I hear back from >> their product manager du jure, they've changed their requirements again. >> >> I'm puzzled why these providers seem to have new peers show up at the >> same time they are telling me new peerings are on 'hold.' Should I >> start taking this personally? If you don't intend to peer with other >> providers, why not say so? Why go through the trouble of making >> peering questionaires and listing peering requirements, when you are >> just going to come up with a new excuse if you don't want to peer >> with the other provider. >> >> >They happen to >> >be business deals that have $0 attached to them for all sorts >> >of reasons Sean D et al explained far more eloquently than I could, >> >but they are still business agreements. Just like any other contract, >> >be in breach at your peril. >> >> Breach of contract is a civil matter, not criminal. If you have a >> peering agreement that says thou shalt not next-hop third-party routes, >> and they do, you get to terminate the agreement and/or sue the other >> provider, not arrest them. >> >> People seem to be very quick to call things they don't like illegal. >> Not all misrouted packets are the result of illegal activities, most >> of them are just misrouted packets. MCI didn't plan to send me packets >> across mae-east, they just happened to believe some bad routing information. >> >> If you are going to start arresting people simply because packets are >> misrouted, big providers misroute a lot more packets than little providers >> simply due to size. This is a dangerous game to start playing because >> it can easily blow up in your face. >> >> >Which leaves the case where you send traffic to say ISP X >> >*without* any form of peering agreement with ISP X. Contracts >> >with the IXP should prevent this from happening. If you >> >try this, I hope they filter your MAC address. >> >> Some IXPs do this, but the operators aren't always able to keep up with >> the changing arrangements of the various providers and end up blackholing >> a bunch of traffic every so often for varying lengths of time. The routing >> protocols have problems dealing with networks which don't have the 'shared- >> fate' property. >> >> Most other IXP contracts are silent about relationships between ISPs. >> -- >> Sean Donelan, Data Research Associates, Inc, St. Louis, MO >> Affiliation given for identification not representation >> > > >-- >Alan Hannan >Not Employed Networking, Ltd. >email: alan(a)mindvision.com. >phone: 402/488-0238 > > ________________________________________________________ Eric D. Madison - Senior Network Engineer ACSI - Advanced Data Servics - ATM/IP Backbone NOC - 800-291-7889 - noc(a)acsi.net

4 4

GES (jvnc.net) as the purveyor of bad routing advertisements
by Gordon Cook 03 Oct '96

03 Oct '96

COOK: I am going to resurrect the bad advertisement thread because I have some additional knowledge of the subject that I hope will be constructive to share with the Nanog community. After Mat Petach's posts I have done some further research. The 'evil ISP' was jvnc.net also known as GES. I have known these people and their subsequent history in some considerable detail since I joined the staff of the JVNC supercomputer center in September 1987. I had a free account there (in return for my newsletter) from the summer of 1992 until midsummer of this year. From November 1994 until April 17 1996 I used it for all my email activity. In mid April of 1996 a routing problem appeared that made it unusable for me and I switched my email and base of operations to net access. One highly significant thing that has not been said is that this "evil ISP" is the one that Princeton University depends on for its connectivity to the internet. JVNCnet is (was?) one of the NSFnet regionals and has been getting inter regional connectivity money from NSF in order to use MCI to connect Princeton to the rest of the Internet. As Mat Petach wrote, this is not the first time *HE* has had trouble. It is not the first time that many other people have had trouble either. JVNC has lost quite a few major corporate connections over the last 2 or 3 years. And one day early last month Princeton University lost its internet connectivity at roughly 10 AM. It wasn't restored until roughly 6 PM the same day. Less than a week later it suffered a second multi hour outage. I believe that there is ample evidence that the folk at Princeton have to be very aware of the nature of their provider. Yet I have seen no signs that Princeton is ready to pull up its stakes. Yesterday afternoon, I called Ira Fuch's office. (Ira is VP of computing and telecom at princeton if I have his title right.) I told his secretary my concerns indicating I was contemplating going public with them shortly and saying that I'd like to communicate with Ira to get his take on the matter. I called up today at 3:30 pm EST and was told that Ira had no comment on my call nor on the email from this thread that I sent him. I have also called Sergio Heker, the GES CEO and asked his secretary to ask him to call me.... Leaving with her a summary of the reasons for my call. An hour later I received a call from an old acquaintance who happened to be visiting Sergio who apparently didn't feel up to calling me. We talked for an hour and as a result of that conversation I see no reason to change my assessment. An assessment which also has as part of its foundation a continuous input of email messages from various sources describing developments there over the past 6 months. On September 28 matthew petach wrote: I'm going to ask the rest of the NANOG community for their thoughts/opinions on a problem that's been plaguing us periodically that we haven't been able to find a satisfactory solution for yet. There's an ISP back on the East Coast that has been periodically advertising more specific routes for /24's out of our CIDR blocks and black-holing the traffic within their network. We've called all the listed numbers for their technical, admin, billing, and any other contacts we can find, and haven't been able to reach a human; we've left messages of various levels of nastyness, from very sugary on up to vaguely threatening. In every case, including the current one, it's been more than 24 hours, and they still haven't made any response to the problem; in fact, I just got paged by our NOC early this morning informing me they've stolen another one of our /24's. COOK: Matthew tends to assume in his remarks that the "evil ISP" knew what it was doing when it 'stole' his routing announcements. I have evidence that says that is probably not true. In mid April of this year when I would use the 56 kbs connection from my house to log into net access and telnet from there to tigger.jvnc.net to read email, the response from tigger slowed to about 300 baud and I would see several periods an hour where for up to 3 minutes I'd get no echo to my screen of what I was trying to type or read. Traceroutes showed my RETURN traffic was coming by way of the CIX. My connection had become unusable. I did a lot of frantic inquiry and found out that the placement of an AS path filter on the JVNC golden gate router would solve my problem. Calling their NOC, I asked for the filter to be installed and was told that only the net manager could approve such a request. Making multiple calls on April 17 I was told that my request was "under consideration." I spoke that evening to several recent employees and was told that it would probably stay under consideration until hell froze over because there was no one who wanted to touch the routing configs made by a now ex- employee during the transition to MCI in the May- June 1995 time period. Why, because there was no one there who had the knowledge to put things back together if anything broke. Consequently I suspect that the bad routing advertisements may result not from any purposeful action but rather from ignorance. On the basis of further investigation I have also ascertained that staffing has become really stretched and another possibility for the non response to complaints is that the voice mail and email may never have gotten through. Staff turnover at GES between the summer of 92 and 93 was 100%. I have had recent estimates that the current turnover rate may be close to 100% every 6 months. The history of the privatization and spin off of GES from Princeton is in itself an interesting story. One with which I am VERY familiar having been informed of a number of events in 1992 as they were happening and talking directly with people involved on both sides of the story. Unfortunately since that history is now more than 4 years old, none of my sources are willing to go on record and I doubt that I'll be doing any write up of it. Still the situation is that GES (JVNC) is suffering from enormous problems and has been suffering for quite a while. These problems are well known to industry insiders but much less well known to the Nanog community at large. Without clear knowledge of the situation at GES that has been causing these experiences for members of the network community, they are likely to be repeated again and again. With a clearer view of the situation, those involved may be able to decide on the most rational courses of action to take. ************************************************************************ The COOK Report on Internet For subsc. pricing & more than 431 Greenway Ave, Ewing, NJ 08618 USA ten megabytes of free material (609) 882-2572 (phone & fax) visit http://pobox.com/cook/ Internet: cook(a)cookreport.com For case study of MercerNet & TIIAP induced harm to local community http://pobox.com/cook/mercernet.html ************************************************************************

1 0

ATM v/s SONET
by Bharat Ranjan 02 Oct '96

02 Oct '96

> >Vendors such as Fore are starting to offer OC-3c/12/c and OC-48c (future) >interfaces on their ATM switches. Using these interfaces, the switches can be >connected together in a ringlike fashion. A service offered when connected in >a ring is called Fast Failover Recovery, or something along that line. This >service provides functionality that is identical to SONET >protection-switching. Basically, bandwidth is reserved around the ring for >protection scenarios. When the ATM switches detect failure (fiber cut, node >failure, etc.), they recreate the VP around the opposite direction of the >ring using the reserved bandwidth. This is done at the ATM level, versus the >physical level for SONET. As expected, the switchover time is in seconds >versus the milliseconds for SONET. > >For networks that carry data that is not sensitive to this increased >switchover time, does it make sense to use SONET at all? The question comes >down to why do you need a SONET ring when then same functionality and speed >is provided by the ATM ring? mm mm sssss nnnnnn * Bharat Ranjan * m m m s nnnnnnn * Network Engineer * m m m sssss nn nn * MSN Network Services * m m s nn nn * (206)-936-0471 * m m sssss nn nn * bharatr(a)microsoft.com * ******************************************************* * The opinions/ideas in this memo are not necessarily * * those of Microsoft Corp. * ******************************************************* > > > >

1 0

Need hints on proper default route selection
by Curtis Generous 02 Oct '96

02 Oct '96

We have a WAN that is multihomed with 2 NSP's (as customers, not peers). Small routers with limited memory; full iBGP mesh; BGP routes not redistributed into IGP. Our routing policy had been: [] Point default to NSP #1 [] Take internal routes from NSP #2 [] Have a second, lower pref default to NSP #2 Recently, we have been bitten by failures on our 10mbit link to NSP #1 (default) where the ethernet-lookalike link between us became uni-directional (common netedges failure mode). This failure was not detected by the router hardware so the bulk of our traffic continued to send the data out that interface and into a black hole. To get around this failure mode, we got NSP #1 to also send us their internal routes and we changed our candidate default-network to point to one of their well-known annoucements instead of the directly attached interface. So our new policy had been for quite a while: [] Take internal routes from NSP #1 [] Select an annoucement as candidate default net from NSP #1. [] Take internal routes from NSP #2 [] Select an annoucement as alternate candidate default net to NSP #2. The problem we have been experiencing now is that both NSP #1 and NSP #2 have been undergoing some major internal restructuring, causing daily change/loss of candidate net annoucements, or change in aggregation boundaries, etc..... making it a daily exercise at selecting proper candidate route selection. Can anyone provide an alternate or better strategy on how to deal with this? tia, --curtis

3 2