- Test - lists.nanog.org

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

AS numbers question
by algold＠lambda.lncc.br 07 Jul '96

07 Jul '96

Are there "reserved" AS numbers, the same way there are reserved IP addresses for non-connected networks? Are As numbers considered scarce ? (I think of many small Internet providers asking for AS numbers just to peer BGP with more than one ISP). TIA -- ----------------------------------------------------------------------------- | Alexandre Leib Grojsgold | tel: + 55 21 542-2746 | | LABORATORIO NACIONAL DE COMPUTACAO CIENTIFICA | fax: + 55 21 295-8499 | | 22.290 Rio de Janeiro - RJ - Brasil | | -----------------------------------------------------------------------------

4 3

Interconnecting at MAE-West
by Carl Forsythe 06 Jul '96

06 Jul '96

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 | =====================================================================

6 7

ANNOUNCEMENT: New listserver - ISP-Telco
by Richard Cramer 06 Jul '96

06 Jul '96

Hopefully we will be filling a void. People have asked for a list that would have as its subject: Telco equipment as related to the ISP environment. We hope to deal with a broad subject matter; CSU/DSU configuration, equipment feature comparisons, T-Carrier analyzer tips, lease line procurement, etc, etc, etc. The list is now open for subscriptions. We will take subscriptions for about 3-5 days. This way no one will miss anything and we can also shake out any last minute problems. Postings will be accepted starting July 10th unless notified otherwise. SUBSCRIPTION INFO: Subscribe to: majordomo(a)list.sytex.net, with no subject, and "subscribe isp-telco" in the body of the message. Regards, Dick -- Richard Cramer rcramer(a)sytex.net Phone: 703-425-2515 President Fax: 703-425-4585 Sytex Access Ltd. POB 2385, Fairfax, VA 22031-0385

1 0

re: AGIS Route Flaps Interrupting its Peering?
by Peter Kline, Sr. Network Engineer 05 Jul '96

05 Jul '96

Here's some background: AGIS's router is not colocated at the MAE parking garage, but is in fact colocated at WorldCom in downtown Washington DC. Our bits get from there to the MAE via a DS3, and that DS3 is terminated at each end with a device called a NetEdge, which does the FDDI to DS3 ATM conversion. 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). This third operating state results in some very interesting, possibly misleading, and sometimes damaging behavior. It looks quite similar to the kind of behavior you get when you change the MAC layer device but keep the same ip address at either of the MAE's: ARP caches get inconsistent, and BGP sessions with other routers flop around, leading to routes getting flap dampened by those running the appropriate code. Here's what happened: AGIS's connection to MAE-East experienced one of these kind-of-working problems which resulted in the erratic behavior above. Digex customers wishing to reach AGIS customers called the Digex NOC, and the posting which started this all was made to the Digex internal news group. Similarly, AGIS customers had problems, and we worked with MFS to get the problem resolved (they must have a warehouse full of swapped-out NetEdges at this point). In the interval, a short-on-facts bozo spit into the wind and got us and Digex wet. I'm in private correspondence with Ed Kern to postmortem the situation. Peter At 10:25 AM 7/5/96 -0400, Ed Kern wrote: >> >> One key point is that we have not received any complaints or reports >> of any sort concerning any perceived issues at mae-east from any >> mae-east peers. Digex made no attempt to contact us. We were already >> working with Advantis on the unreachable issue above, but the first we >> heard of the "AGIS attacks mae-east" report was when a Digex customer >> sent us a report similar to that forwarded to all of you by Cook. > >Went into this in the last message...Digex will try and be more >proactive with pointing out Agis flapping prefixes in the future. > > >> An appropriate audience would have been the AGIS noc and the Digex >> noc. I think the Cook approach was inappropriate because the issue >> was purely between Digex and AGIS until Cook distributed it to the >> three widespread mailing lists. > >I agree.. > > >> > How is the report flawed? >> >> I see that Ed Kern has already replied indicating that the report was >> indeed flawed. I don't think that there is anything to be gained by >> going into further detail. > >What I was referring to was the internal circulation here...which I was >under the impression got to external customers....now im not so >sure... > >The internal report was flawed because it relied to much on source >routes and came to some bad conclusions on the internal state of agis. > > >> My key point is that nothing of interest happened. This was a >> non-issue until the misinformation was blasted around the Internet >> technical universe. >> > >I would argue that the external message that got sent around was >misinformation...It was correct information from what the people >could see at the time it was released...(lots of dampened prefixes and >a down peer).. > > >Ed > > > _____________________________________________________________________ Peter Kline Senior Network Engineer| 313-730-5151 AGIS - Internet Backbone Services | _Lucem Diffundo_ Post-Traumatic Success Disorder+ | ///////////////////////////////////////////////////////////////////// You can pretend to care, but you can't pretend to be there.

3 2

Re: Internet access and telco usage patterns
by Hong Chen 05 Jul '96

05 Jul '96

Eric, 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. 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. Hong Aimnet -------- Begin Included Message ------- > At 05:36 PM 7/4/96 -0700, Michael Dillon wrote: > >> > Has anybody looked at the practicality of installing modem pools in each > >> > telco switch location to grab the dialup user's traffic at the IP level > >> > and then route it to their ISP of choice for authentication and further > >> > routing. In other words, an ISP wouldn't buy phone lines, modems and > >> > terminal servers, they would buy IP access ports. > > > >I now find that BC-Tel is offering this service in parts of British > >Columbia. BC-Tel is half owned by GTE. > > Michael, > > Also of possible interest here is that Westel, another telco in British > Columbia started offering this service early 3rd quarter of last year (with > Livingston Portmasters, ISP managed RADIUS authentication, and its own > Internet connection) which pressured to BCTel to offer a similar service. > Eric Woodward. > ejw(a)wedirect.ca. > > -------- End Included Message --------

1 0