- Test - lists.nanog.org

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

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

02 Oct '96

>But you're talking about getting connections to 3 exchange points and >the "stuff" in between. I would say costs might be roughly even. That is exactly what I am talking about. The cost of getting the connection to a meet point is minimal.. the people and equipment are costs. That is why if a small provider gets a connection to a single meet point no one wants to peer with them, they don't have the engineer, monitoring, and maintenance. >But what about when you add in the network engineering, monitoring, >and maintenance you need when you run your own network? Have you >checked out market price on clueful network people who dance with >BGP? The cost comparison might look different then... > I know the cost very well. My Cisco Rep is loving it too. We are still rolling out of our network and finding the right people with true knowledge of this business is hard to find. I am trying to find good IP backbone people now and am having a hard time, especially in the Washington, DC area. All the good ones are already taken in this area. It's really becoming a chosen few that "really" know this business and know it well enough to build a living, breathing network from the ground up. Eric

1 0

Peering versus Transit
by William Allen Simpson 02 Oct '96

02 Oct '96

It has appeared to me for some time (and I've mentioned it before) that peering "restrictions" have gotten completely out of hand. I believe this is because terminology and agreements for "peering" and "transit" have become ill defined. I can see no justification under any circumstances why any provider would refuse to peer with another at an established exchange point for exchanging their _own_ customers' traffic! But note: this should not mean transit to others who are not customers of the provider, or to other exchange points around the world. I firmly believe that this is where the current model has gone awry. Worse, the current technology used at the exchange points could encourage abuse. What is to stop anyone connected to an exchange from simply dumping packets anonymously at the link level into the various inter-exchange providers' routers and getting free transit? Instead of negotiating with other providers for inter-exchange transit, I advocate that each attachment to an exchange negotiate with the exchange _operator_ for transit to other exchanges, and the exchange negotiate with inter-exchange providers for the aggregate. Separating the peering from transit provides greater clarity in agreements, with opportunity for better quality monitoring and control, while promoting greater redundancy in the Internet mesh, and greater competition in the inter-exchange transit market. ---- Until this happens, in the case in point, I would recommend that Wonderland (an org, not a net?) has no _transit_ peering to offer Sprint "in kind", as Sprint likely already has enough transit agreements to reach those same exchanges. Wonderland might have better spent its $5M+ per annum obtaining service from an existing trans-atlantic provider, or cooperating with another provider to join multiple links under existing transit agreements with Sprint and others, thereby reducing the trans-atlantic congestion. > From: Peter Galbavy <peter(a)wonderland.org> > > Besides, most of the major providers previously based the bulk of > > their peering 'requirements' on how many DS3s you had. Now most > > 'major' providers seem to have gone cold turkey. MCI, Sprint, and > > UUNET told me they won't peer with *anyone* new. > > But seriously, lets face it, DS3's are "cheap" and these people > want more customes no freeloaders. Like us, who are paying $5M+ a > year for a trans-atlantic DS3 and Sprint are very insistant that > we build a US network based on DS3s to peer with them, even with > the obvious fact that we have no US customers and have already paid > for a connection which in reality should be matched by the large > US carriers, rather than taking the piss once you have this > investment. I only mention Sprint, since the others you mention > are a tad more sensible, but still slow, while Sprint are in a > glacier. > WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

15 29

Re: Peering versus Transit
by Vadim Antonov 02 Oct '96

02 Oct '96

Sanjay Dani(maillists) <indus(a)professionals.com> wrote: > Heh. That's an example of how stupid technology is being > preserved by stupid legistlation. The laws regarding POTS are > generally legal fixes for techincal problems (like inability > to block annoying calls). >Forgotten the syn flood attack so quickly? Heard of IP spoofing? How long did it take for OS vendors to come up with fixes? A week. And for how long telcos can't do anything about annoying calls? A hundred years. That only confirms my point. >That does not make your one sided arguments stand any more than >they did. Goes to prove experience does not necessarily equate >insight into all aspects of the business. You have a stake in >perpetuating the status quo. Me in changing it because it >doesn't make sense. Sorry, to me what you tell does not make sense. If you want to change things you need to come up with something which actually works and build it. Then you'll get all the stake and will be as interested in perpetuating status quo. (BTW, hey, Sprint, where's my stake?) >No, it is beginning to suck. Have you checked reliability >of the backbones lately? I started a company to _do_ something about it, ok? >Sigh.. old hats like you have a >hard time realizing that old models have to, and will, >change. I suspect that i'm younger. I simply have better tuned B.S. detectors. Reading Pravda helps to learn that things often aren't what they appear to be. >PS. This is my last email on this topic. Thank you very much. --vadim

3 2