- Test - lists.nanog.org

Re: routing meltdown
by Sean Doran 11 Aug '95

11 Aug '95

>in fact it happens all the time Not generally in Big Internets, although I'd love to know anyone who has been playing with feeding congestion info into their IGPs or whatever, just out of curiosity. Moreover, even where it does happen now, it happens in the middle on a hop-by-hop basis, and not on an end-to-end basis. The latter course introduces all sorts of really interesting problems into something that I thought was nuked as a bad idea a long time ago... Sean. P.S.: I seem to have misplaced my copy of Radia Perlman's _Bridges and Routers_. Does anyone have the ISBN handy?

1 0

Re: routing meltdown
by scharf＠vix.com 11 Aug '95

11 Aug '95

jon(a)branch.com (Jon Zeeff) wrote > Perhaps "policies, procedures & data" is a better word than "protocols" used > in the generic sense. > > I want to route things differently based on the time of day, whether > or not a particular network is seeing heavy traffic, and what my > horoscope said today. I can implement this much more easily on a > workstation where I have source code than I can convince Cisco to > implement it. > > > So, it seems that using route servers would have no impact wrt to removing > > "complex routing protocols from routers". Making routing decisions based on horoscopes doesn't bother me. Making routing decisions based on load is somewhere between silly and scary. If you only cook yourself then it's silly, if you cook others it's scary. In my dusty past I played with a digital simulation of an analog computer, and remember trying to build various damped circuits. Then you hooked up the signal generator, and about 8 times out of 10, some part of the circuit went to rail (this means you blew it.) The idea of positive feedback loops in the internet routing/traffic fabric seems unimaginable for someone who had trouble taming 10 opamps with a known input signal. It's easy to look at what exists and see it is suboptimal. I would venture it is impossible to build an automatic system that would not display catastrohic actions under certain stresses. Jerry

3 2

Re: routing meltdown
by Curtis Villamizar 11 Aug '95

11 Aug '95

Yakov, > So, it seems that using route servers would have no impact wrt to removing > "complex routing protocols from routers". There is at least one large Internet service provider who has talked (internally) about doing things like removing routing protocols entirely from commercial routers that forward very well but route very poorly. It was even suggested at one point that maybe we could open a telnet session and feed the router "ip ro net mask hext-hop" and "no ip ro net mask hext-hop" commands as a means to control it, but though giving it routing using a single BGP connection and third party routes was a cleaner approach. Probably the only thing that kept us from doing that was the poor cache performance and buffering problems (didn't really forward all that well under real network conditions). Curtis They don't build them like they used to. They never did. :-) True for arbitrary values of "they".

1 0

Re: routing meltdown
by Sean Doran 11 Aug '95

11 Aug '95

What you want is something that isn't the Internet or even a hop-by-hop destination-based connectionless packet network, but rather something akin to X.25 or ATM. Sean.

1 0

Re: i don't think i can sell this...
by Sean Donelan 11 Aug '95

11 Aug '95

>Ok, so how much is internic.net worth? Do I hear $50,000? ;) Sorry, I wasn't going to comment, until this... I wondered about this too, since I couldn't find a trade mark registration for InterNIC. Turns out AT&T (the quiet half of the InterNIC) registered the *service mark* InterNIC. Network Solutions registered the domain name internic.net (with themselves?). Is it possible to design a more complex system? Supposedly AT&T is negotiating with the National Science Foundation over the service mark "InterNIC." One plan is for AT&T to assign the mark to NSF. Whether this would prevent future squabbling over the mark "InterNIC," I don't know. Personally, I'm not sure who's lawyers would scare me more in court. The United States, or Ma Bell? Before you can sell internic.net, first you have to figure out who it belongs too. If you don't believe me, I have a bridge in Brooklyn for sale. I'll go back to lurking now. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

i don't think i can sell this...
by Paul A Vixie 11 Aug '95

11 Aug '95

...but something tells me i'd better let y'all know that there's a new internet business in "town"... ------- Forwarded Message Date: Thu, 10 Aug 1995 14:04:35 -0700 Message-Id: <199508102104.OAA09891(a)gonzo.wolfe.net> From: domains(a)WOLFE.net Apparently-To: paul(a)VIX.COM Dear Paul Vixie <paul(a)VIX.COM>: We would like to take this opportunity to invite you to participate in a new domain name marketplace service. As you are affiliated with CIX.NET, we would like to know if you are interested in selling all legal rights to this registration. In the event that you do, please reply to this message as indicated below. This also applies to domains that you may wish to purchase from another party. On September 1st you will be able to access the url http://gonzo.wolfe.net/~domains to trade domain names with other registrants. You will be given further instructions at that time to complete your transactions. The fee for this service is a 10% per domain transfer fee. Should you choose to commit to selling your domain, you agree that for a period of 120 days that if you sell the domain on your own (apart from this service), that you agree to pay a 10% fee for any transfer charge you receive. Instructions: For each domain you would like to sell, change the price after the name to your selling price. If you are not interested in selling a domain, delete it from the list, or leave the price as $0.00. All members of this list must be within the area below enclosed by '*' marks. *************************************************************************** CIX.NET $0.00 *************************************************************************** If you would like to make an offer or receive pricing on another domain, make a list of the same form as above, with the domain name(s) you are interested in followed by your offer. All members of this list must be within the area below enclosed by the '$' marks. $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ There is no charge or obligation to ask for a price or make an offer. Simply reply to this email and check back at the above url on September 1st. Thank you for your time. AMS, domains(a)gonzo.wolfe.net ------- End of Forwarded Message

2 1

Re: i don't think i can sell this...
by lear＠yeager.corp.sgi.com 11 Aug '95

11 Aug '95

That is rich! -- Eliot Lear [lear(a)sgi.com]

4 3

Re> Re: ATM thruput
by Dave Reese 10 Aug '95

10 Aug '95

Sean, Actually we are experimenting with ATM, and have been for about 12 months now. We have 5 sites throughout California inter-connected with ATM for distance education projects and we are now expanding this trial to include IP traffic. Three more sites will be added soon. We are using NewBridge 36150 ATM switches with their JPEG video cards to provide VCR-quality full motion two-way video for the Library Sciences Masters Degree program between Northern and Southern California. At CSU, Hayward there is a scanning electron microscope which broadcasts its images through this network as well. The microscope can be controlled remotely at the viewing site through IP access. We recently added ATM/OC-3 processors to our cisco 7000 series routers to provide IP access. SGI workstations and servers with ATM NIC cards are interconnected to the cisco and NewBridge equipment through FORE switches at some of the sites. Thank you for your inquiry, Dave Reese Director, Networking & Computing Services California State University ------ From: Sean Doran, Thu, Aug 10, 1995 ------ [quoting entire message] >d Hm, been experimenting with ATM at CalState again, eh? Sean. ------------------ RFC822 Header Follows ------------------ Received: by ml.calstate.edu with SMTP;10 Aug 1995 16:08:05 -0700 Received: by calstate.edu (5.57/Ultrix-4.1/CSUnet 1.2) id AA03753; Thu, 10 Aug 95 16:08:02 -0700 Received: from cesium.clock.org (cesium.clock.org [17.255.4.43]) by merit.edu (8.6.12/merit-2.0) with SMTP id SAA15353 for <nanog(a)merit.edu>; Thu, 10 Aug 1995 18:11:53 -0400 Received: by cesium.clock.org id <5811>; Thu, 10 Aug 1995 15:11:31 -0700 From: Sean Doran <smd(a)cesium.clock.org> To: dsiegel(a)net99.net, jim(a)calstate.edu Subject: Re: ATM thruput Cc: nanog(a)merit.edu, pushp(a)cerf.net Message-Id: <95Aug10.151131pdt.5811(a)cesium.clock.org> Date: Thu, 10 Aug 1995 15:11:27 -0700

1 0

Re: ATM thruput
by Sean Doran 10 Aug '95

10 Aug '95

[quoting entire message] >d Hm, been experimenting with ATM at CalState again, eh? Sean.

1 0

CERT Vendor-Initiated Bulletin VB-95:06 - Cisco
by CERT Bulletin 10 Aug '95

10 Aug '95

CERT Vendor-Initiated Bulletin VB-95:06 August 10, 1995 Topic: Vulnerability in Cisco's IOS software Source: Cisco Systems To aid in the wide distribution of essential security information, the CERT Coordination Center is forwarding the following information from Cisco Systems. NOTE THAT THIS IS NOT NEW INFORMATION; CISCO RELEASED THIS ADVISORY TO THE PUBLIC IN JUNE 1995. If you have already seen this and are certain that you have correctly configured your routers, you do not need to take any further action. However, if you have not seen this Cisco Security Advisory or are not certain that your routers are configured correctly, we urge you to review this bulletin and check the configuration of your router. Cisco contact information is included in the forwarded text below; please contact them if you have any questions or need further information. ========================FORWARDED TEXT STARTS HERE============================ Cisco Security Advisory Thu Jun 1 16:27:08 PDT 1995 ------------------------------------------------------------------------------ The following describes a vulnerability in Cisco's IOS software when the 'established' keyword is used in extended IP access control lists. This bug can, under very specific circumstances and only with certain IP host implementations, allow unauthorized packets to circumvent a filtering router. This vulnerability is present in the following IOS software versions: 10.3(1) through 10.3(2) 10.2(1) through 10.2(5) 10.0(1) through 10.0(9) ...and all previous versions of Cisco software. If you are running any of these IOS versions on a product that uses IP extended access lists, and you are using the 'established' keyword in these lists, then Cisco strongly recommends that you take immediate action to remove the vulnerability. You can determine what version of IOS you are running by issuing the following command: show version The recommended action is to upgrade to a more recent version of IOS, or take one of the immediate workaround actions described below. The vulnerability is fixed by in the following official software releases: 10.0(10) or later 10.2(6) or later 10.3(3) or later (For reference, the Cisco update identifier for this fix is "CSCdi34061".) Customers may obtain software upgrades without going through the Cisco's Technical Assistance Center (TAC) via the Cisco Information Online (CIO) service. Instructions for downloading are available at the end of this message. You may also contact your Cisco distributor or contact Cisco's TAC for more information. The TAC can be reached by phone at 800-553-2447, by e-Mail at tac(a)cisco.com or via the World Wide Web at http://www.cisco.com (for registered CIO users only). In Europe, you can contact the TAC by phone at 32-2-778-42-42 or via e-Mail to euro-tac(a)cisco.com. ------------------------------------------------------------------------------ Details 1. Description A bug in Cisco's extended IP access list implementation can, under very specific circumstances, allow a user to bypass IP packet filtering. This may permit unintended IP traffic to pass through your firewall setup. To determine if you are vulnerable, look through your configuration. The configuration can be displayed by enabling and then entering the command "write term". If you see an access list line using a list number in the range of 100 through 199 that permits or denies TCP traffic and contains the word 'established' near the end of the line, you may be vulnerable. An example line might look like: In IOS 10.3: access-list 100 permit tcp any any established In IOS 10.2 or earlier: access-list 100 permit tcp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 established If you do not meet this test, then you are not vulnerable. You do not need to do anything. 2. Workaround The following actions will remove the vulnerability: o Rewrite the access list parameters so the 'established' keyword is not necessary. This does not simply mean that you may remove the 'established' keyword, but rather that you will need to re-design your access lists to provide similar functionality without using the established mechanism. or o Disable the interfaces to which the access list is applied using the 'shutdown' interface subcommand. Example: router(config)#interface ethernet 0 router(config-if)#shutdown 3. Solution Obtain and install the appropriate release of IOS software as described above. For assistance, contact Cisco's TAC. 4. Technical Comments This problem is caused by an obscure but common design flaw that we believe exists in many router/firewall vendor's packet filtering implementations. Owners of non-Cisco hardware who use IP packet filtering features similar to Cisco's "extended access lists" as part of a firewall system may wish to contact their vendor to confirm that this vulnerability does not exist in their system. (Technical discussions about the problem have already occurred in the appropriate forum.) This vulnerability can only be exploited with certain IP host implementations (we do not have information on which implementations are susceptible). Cisco suggests that all routers configured to filter IP packets based upon the 'established' mechanism be upgraded. ------------------------------------------------------------------------------ Software Upgrades Software upgrades may be obtained via any of the following mechanisms: * World Wide Web (WWW): For registered CIO users please open a URL to: http://cio.cisco.com/kobayashi/Library_root.shtml and select the version of software to download. For non-registered users open a URL to: http://cio.cisco.com/public/library/spc_req.shtml When prompted for a code, please enter: certjun2 for a list of available files to download. * FTP: ftp cio.cisco.com and at the initial (username) prompt, enter: certjun2 At the password prompt, enter your e-mail address. Then: get README.certjun2 This file contains a list of files available that close this vulnerability. Please examine this list to determine which files you need and then download them. * Character-based "CIO Classic": For access, the following connection options are offered: o telnet: cio.cisco.com o Dial-up modem: In Europe: +33 1 64 46 40 82 In the US: (408) 526 8070 Settings: vt100, N81, up to 14.4Kbps Enter either as a guest or registered user and navigate to the topic: Software Updates Special Files At the prompt for a code, please enter: certjun2 A list of files will be displayed for you to select and download. ------------------------------------------------------------------------------ =========================FORWARDED TEXT ENDS HERE============================= CERT publications, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from info.cert.org. CERT advisories and bulletins are also posted on the USENET newsgroup comp.security.announce. If you would like to have future advisories and bulletins mailed to you or to a mail exploder at your site, please send mail to cert-advisory-request(a)cert.org. If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise that the e-mail be encrypted. The CERT Coordination Center can support a shared DES key, PGP (public key available via anonymous FTP on info.cert.org) or PEM (contact CERT staff for details). Internet email: cert(a)cert.org Telephone: +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. Fax: +1 412-268-6989 CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 USA CERT is a service mark of Carnegie Mellon University.

1 0