- Test - lists.nanog.org

Re: since it's national pick-on-bob-metcalfe week anyway...
by avg＠ncube.com 09 Jul '96

09 Jul '96

>bob's contribution to what we're doing here is larger than mine, and >perhaps larger than almost anybody's. where would we be without Ethernet? Using some saner technology like today's full-duplex switched "ether"nets. It's like presuming that we'd be in deep trouble w/o benefits of MS-DOS. Not. --vadim

1 0

Finally -- the May 1996 pages are done
by sob＠academ.com 09 Jul '96

09 Jul '96

The NANOG pages are done. I apologize for the running late, but I had an exceedingly busy June. Comments on the pages are welcome. http://www.academ.com/nanog/may1996 -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

Re: AGIS Route Flaps Interrupting its Peering?
by Brett D. Watson 09 Jul '96

09 Jul '96

> On Fri, 5 Jul 1996, Mark Kent wrote: > > > An appropriate audience would have been the AGIS noc and the Digex > > noc. > > Wrong! It's an operations issue and it SHOULD be on NANOG or a global > outages list if such should some day exist. i have to agree, strongly. > > > Could you share your findings? If there was a problem, I think > > > we'd all prefer an explanation rather than a finger shaking for > > > having interest. > > > > My key point is that nothing of interest happened. > > There are hundreds of providers learning how to deal with multihoming and > peering. Anything like this is of interest because people need to know how > to recognize and solve problems to keep the global network running. > > > This was a > > non-issue until the misinformation was blasted around the Internet > > technical universe. > > Yep, no doubt about it. If you create the environment for misinformation > to spread then it WILL spread. However, you can fix this. If timely an > accurate outage information is available from everybody then > misinformation won't spread and where it does manage to propogate it will > merely be static. this is the major problem i had with the large provider i worked for. the corporate motto was "if we have something broken, we don't want *anyone* else to know about it..." "it's none of *their* business if we have routers melting down..." and my favorate response to customers asking for an "outage notification list" was to create the list, not use it for 6 months, and then come up with some generic statements like "we are having technical difficulty, we;re working on it". complete crap in my opinion. it did nothing but insult customers' intelligence. i agree with what michael is saying (i wont' be struck by lightening will i?) 100%. *timely* disclosure of problems like this would avoid misinformation and bring back a small bit of the spirit of the net that was lost some time back.... *cooperation*. -brett

1 0

Re: Ping flooding (fwd)
by Daniel W. McRobb 09 Jul '96

09 Jul '96

> On Mon, 8 Jul 1996, George Eddy wrote: > > > yes, forging a ping attack is pretty easy and can be done from > > anywhere with any source address (of course, who knows where the > > responses will end up), the routing proximity is irrelavant, since the > > source is not looked at (unless filters have been put in place, such > > as what the upstream provider has apparently done). > > > > the only _I can think of_ in tracking it down, would be to backtrack > > the possible paths into the router. either by sniffing the possible > > lines coming into router, or by temporarily disabling icmp echo reqs. > > from all but one incoming line, until you've found the offending line, > > continuing back. > > > > of course this may be impossible in many cases since you probably > > don't have access to the equipment (or cooperation) outside of your > > domain. > > OK. So what if somebody is currently planning a ping battle on the global > Internet, kind of like corewars in the netwrk. Then what? Do the NSP's all > roll over and play dead? > > If I were to crosspost this reply to alt.2600 it wouldn't take long to > happen you know. BTW, I won't be crossposting it there, but you get the > idea, security by obscurity, etc... I'm quite certain that tons of people know about these kinds of attacks and how to implement them (as well as defend against them). alt.2600 can't possibly be so far behind the times as to not know about forging headers and the possibilities, regardless of whether or not it's ICMP traffic we're talking about. Denial of service attacks are very old in theory and in practice. This is not a security by obscurity issue at all. > Is anyone working on tools to help NSP's quickly backtrack this kind of > thing? The problem is not really a technical one. It's administrative. It's much more of a headache to backtrack through 30 routers that aren't in your own network than to backtrack to the ingress to your own network domain and filter it out there (which is the typical response to this kind of thing). Getting everyone in the path to cooperate with backtracking is difficult in many instances, impossible in others. And that doesn't even take into account the cases where an attacker has multiple paths into your network and is using multiple forged source addresses, much less the fact that the attacker can turn off the attack when he/she chooses, thwarting your effort to track them. Typically a denial of service attack is used to leverage an attack on something more interesting than just pure denial of service. So the denial of service often stops once the attacker has managed to get access to what he/she was really looking for (which is not usually something as uninteresting as ICMP echo requests or attempts to consume a lot of resources with such traffic; there are often better means of making someone's leased line and host machines be consumed than sending ICMP messages). Daniel ~~~~~~

2 1

Re: Ping flooding
by George Herbert 09 Jul '96

09 Jul '96

>We are currently undergoing a ping flood attack, though our upstream >provider has filtered icmp from the host so the flood is no longer >affecting our T1 line. > >The system administrator of the site that appears to be flooding us >doesn't believe his site is the source of the attack. He states that he >can't see the icmp packets, though I don't know how he is sniffing his >wire. > >My questions are these: > >Is it possible for someone to forged the source IP address of an icmp >packet? Yes, trivially. >If so, do they have to be in some routing proximity, or can they forge the >source address while they are connected from anywhere in the world? Anywhere that doesn't have outbound source filtering on their net connection... which is almost nobody. Back when I was at UC Berkeley in the late 80s, variations on this scheme were coded up and regularly used to interfere with other people's network game sessions (re-routing xtrek screen updates through Finland, similar stunts). The same basic concept can be done with any source IP addr and any ICMP command (or, basically, any IP data you want too). It is entirely possible that the information the other sysadmin has, that it's not coming from his net, is correct. If so, you have to go to your upstream and start tracing those packets back through the WAN connections to find out where they come from. This is doable but not at all trivial. However, it you see enough evidence to think it's someone trying to take you down maliciously and not just goofing off a bit, it is definitely worth doing the backtrack to find them. This is a classic denial of service attack which is a computer crime in most states and under federal computer crime laws if the attacker is in another state from you. -george william herbert gherbert(a)crl.com

1 0

Re: Internet access and telco usage patterns
by Barney Wolff 08 Jul '96

08 Jul '96

> Date: Mon, 8 Jul 1996 13:30:28 -0700 (PDT) > From: Michael Dillon <michael(a)memra.com> > > On Mon, 8 Jul 1996, Barry James wrote: > > > So, the only "secrets" that are shared are the md5 digest keys used > > between the RADIUS server and TS. > > Not quite. The user must "share" their password with the first RADIUS > client in order for it to be encrypted via MD5 in the first place. There > is a hole here. But there is a solution as well. Not true with CHAP. Nothing knows the user's secret but the user and the eventual auth server. Barney Wolff <barney(a)databus.com>

1 0

Hurricanes redefined!
by Michael Dillon 08 Jul '96

08 Jul '96

The official definition of a hurricane is winds in excess of 5 km/hr for a duration of at least 1 hour. Read all about it at http://www.infoworld.com/cgi-bin/displayNew.pl?/metcalfe/metcalfe.htm Now there is a germ of a good idea here. How about defining a standard terminology for outage events that could be used in a daily Internet weather report. Something that is a little more representative of reality, i.e. in a hurricane all human activity pretty well ceases outside of a small portion of your own home. This would, of course, require an integrated reporting system whereby all NSP's report outages, flaps, etc. to a centralised info gathering place which can then graph them, analyse them, categorize them and pulverise them. Michael Dillon ISP & Internet Consulting Memra Software Inc. Fax: +1-604-546-3049 http://www.memra.com E-mail: michael(a)memra.com

2 1

Re: Internet access and telco usage patterns
by Eric Woodward 08 Jul '96

08 Jul '96

At 10:51 AM 7/5/96 -0700, Hong Chen wrote: >As a matter of fact, it is quite doable. Aimnet developed a roaming >server (check www.aimnet.com) that allows international ISPs to >use each other's network to provide dialup services. A group of >ISPs have joined a consortium GRIC (Global Reach Internet >Consortium) lead by Aimnet. The roaming server is based >on Radius protocol. > >A telco company can install modems and route the authentication to >the specific ISP for authentication. Hong, I looked at this doing this about a year ago but the major stumbling block was that if ISPs share the authentication responsibility using distributed RADIUS, they have the capability of keeping each other's passwords for the user's that used the global access service. Also, a service you likely know about, started up around the same time in Vancouver, where I was living at the time, called GeoAccess (www.globalexpo.com/goeaccess) was going to target this idea much more aggressively than I (and plus I did not feel like competing with him in particular), and decided on the model on centralized authentication, effectivele becoming a worldwide access ISP without purchasing a single modem or terminal server. But even ISPs participating in his "network" can log the entered passwords. Telephone companies might have a problem with the legal ramifications of this "roaming" service. >I just came back from Montreal INet 96 last week and a new roaming >IETF group will be started. We are working on the IETF draft >for the roaming and stay tuned. Please let me know what the name of working group is, and perhaps take this to private email. I would be very interested to know how the password access problem is worked around, or at very least, rationaly pushed aside, and even contribute. Eric Woodward. ejw(a)globecomm.net

3 2

re: AGIS Route Flaps Interrupting its Peering?
by Sean Doran 08 Jul '96

08 Jul '96

| These NetEdges seem to have three different possible operating states: | completely working (which doesn't happen often enough); broken (often, right | out of the box); and kind of working (which happens all too often). That these things work at all under load is nothing short of miraculous. There are plenty of mixed-media-bridging devices that have been tried and which have failed miserably in the past, most notably: -- Magnum 100s (ethernet<->funny framing<->ethernet), which don't meet the standard IFG specification; jam too many back-to-back packets at them, and it will lose most of a burst of traffic. This hurt the old MAE-EAST. -- various ADSUs (FR<->ATM<->FR), which lack buffering and perform SAR too slowly, which delayed the PAC*Bell and Ameritech NAPs for months and some of which still exhibit flakiness under load -- a horrible idea (ethernet<->MFS ATM<->ethernet) which didn't work under load; perhaps a veteran user of these neato little things could explain the failure mode to anyone interested. I remember one service provider who had a national "10Mbps" ethernet backbone who had various horrible problems including the breakdown of the LIS (such that some routers couldn't talk to others), connections going simplex, frame loss and other wonderful things -- another horrible idea (FR<->MFS ATM<->FR) this was pretty neat; some of the problems above plus a brand new problem: the ADSU would strip the FR frame checksum, perform SAR, send the cells, and the ADSU on the opposite end would reassemble the frame and produce a correct FR checksum. All fine and dandy, unless cells arrived out of order, SAR was done wrong, or there was data corruption under load in the DSU or in the network. This interesting technology advanced the state of IS:IS in one vendor's software rather considerably -- mixed-media bridging (NetEdges, FDDI/Ethernet bridges) these break in all sorts of interesting ways. In particular, NetEdges have an annoying habit of confusing FDDI stations in particularly toxic ways, and some FDDI/Ethernet bridges resemble roach motels: frames check in but they don't check out. Essentially, most of these things worked mostly perfectly under low load, but when faced with the kind of traffic one sees at a busy exchange point, most bridging technology has failed in really awkward ways. My advice is that if you can avoid talking to something across a bridge at an exchange point, you should do so. The keep-it-simple principle is a bunch more expensive, but probably not as expensive as a very public failure. Finally, why is it that most vendors never test their products in a serious battlefield environment like an ISP of size medium to huge? These places tend to be excellent worst-case testing grounds. Sean.

4 3

Re: Interconnecting at MAE-West
by jones＠nsipo.arc.nasa.gov 08 Jul '96

08 Jul '96

Hello Carl... You can connect to MAE-West-SanJose by contacting Steve Feldman of MFSdatanet. See webpage for products and services as well. You may be eligible to connect to MAE-West-MoffettField by contacting me. Our business model allows commercial enterprises to connect for a $10,000 one time fee and $2,000/month/FDDIport, with a reservation on a GIGAswitch port when that becomes necessary. Terms are prepayment of initial fee and 6 mos connection. Fee is adjusted up or down at end of 12 mos to ensure that only "cost to NASA Ames" is collected. To do this, you must send to me on business letterhead a Letter Of Intent to collocate equipment at Moffett Field, and sign a Reimbursable Space Act Agreement prior to connecting your data line and your router. The cost for now is the same for a DS1, a DS3 or an OC3c. The Participant is responsible for obtaining an IP address from Bill Manning, manager of Routing Arbiter project, and for making any and all peering agreements with other participants. If this is of interest, please contact me via email. /bill jones, external interface manager --- Forwarded mail from Carl Forsythe <carlf(a)mbay.net> >From nanog-owner(a)merit.edu Fri Jul 5 23:46:25 1996 Return-Path: <nanog-owner(a)merit.edu> Received: Fri, 5 Jul 1996 23:46:25 -0700 (PDT) from merit.edu (RFC1413 sender merit.edu [35.1.1.42]) by nsipo.arc.nasa.gov (8.7.1/1.5) id XAA22764 Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id AAA10516 for nanog-outgoing; Sat, 6 Jul 1996 00:51:12 -0400 (EDT) Received: from otter.mbay.net (carlf(a)otter.mbay.net [206.40.79.2]) by merit.edu (8.7.5/merit-2.0) with ESMTP id AAA10510 for <nanog(a)merit.edu>; Sat, 6 Jul 1996 00:51:06 -0400 (EDT) Received: (from carlf@localhost) by otter.mbay.net (8.7.2/8.6.12) id VAA09613 for nanog(a)merit.edu; Fri, 5 Jul 1996 21:51:00 -0700 From: Carl Forsythe <carlf(a)mbay.net> Message-Id: <199607060451.VAA09613(a)otter.mbay.net> Subject: Interconnecting at MAE-West To: nanog(a)merit.edu Date: Fri, 5 Jul 1996 21:51:00 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-nanog(a)merit.edu Precedence: bulk Could some kind network operator out there, guide me to a FAQ or some other document with regards to interconnecting at MAE-West (or any other MAE). Specifically, some of the things I would like to find out about are probably old hat to most of you, so if you could pass on some of your knowledge, it would be greatly appreciated. Some of the specifics: 1) Requirements for interconnect at MAE-West 2) Cost? 3) Minimum Line Speed 4) Transit? i.e. if the line is for backup purposes only, how can we arrange for transit, etc... 5) Peering agreements etc. So if there is a document or set of documents that have this info in them, if someone could point me in the right direction, I'd surely appreciate it. -Carl Forsythe carlf(a)mbay.net -- ===================================================================== Carl Forsythe |Webmaster Monterey Bay Internet | carlf(a)mbay.net | http://www.mbay.net | ===================================================================== --- End of forwarded message from Carl Forsythe <carlf(a)mbay.net>

1 0