- Test - lists.nanog.org

Re: CIDR deployment
by avg＠titan.sprintlink.net 17 Mar '94

17 Mar '94

>P.S. Believe me, you wouldn't want to send back net unreachables for all >the bogon destination networks that we see. cisco won't send more than one unreacheable a second :-) Still, peering with ICM may be a good idea; there is no reason to bounce packets off ENSS... --vadim

2 1

Re: CIDR deployment
by Elise Gerich 17 Mar '94

17 Mar '94

Whoops - it's been a long day. If AS690 points default, that does not solve this problem...... --Elise > > > One of the reasons that we have continued with default is that some folks > will loose connectivity to nets behind ASs such as NSI which don't point > default. Jeff had sent a note indicating that you all were almost ready > to deploy something which would address this. Has that been done? I > wouldn't want to stop pointing default to AS1133 if a set of folks will > loose connectivity to the Pacific Rim. > --Elise

1 0

Re: CIDR deployment
by Erik-Jan Bos 17 Mar '94

17 Mar '94

Yakov, > >I know, it's not ideal, but then again I think there is some urgency > >in getting CIDR really off the ground by now... > > I think this should be *strongly* encouraged. We should clearly steer > away from search for an "ideal" solution, and rather focus on pragmatic > considerations. Agreed. I am trying to do some "structured pragmatic testing" now. SURFnet currently is announcing 192.87.108/22. Two out of the four Cs in this blocks are also explicitly annonced (192.87.108.0 and 192.87.110.0, these are production nets). I currently have a box (my personal laytoy) running in 192.87.111.0 and on the SURFnet backbone this network is routed. You can try to reach my box (192.87.111.59) doing pings or traceroutes (only), I leave it on tonight, but please be gentle to the laptoy :-). I am currently trying to ping to lots of regionals out there and making a list out of the results. I hope to publish something for real on this tomorrow. Here is a first glance: NET ASN REGIONAL COUNTRY RESULT ------------ -------- -------------------- ------------- --------- 133.11.0.0 AS372(?) NSN-AMES-AS(?) Japan Unreach 128.250.0.0 AS372(?) NSN-AMES-AS(?) Australia Unreach 192.36.125.0 AS1653 SUNET Sweden Reach 130.59.0.0 AS559 SWITCH Switzerland Reach (*) 130.43.0.0 AS714 APPLE-ENGINEERING-AS US Reach (*) Path from mentioned network to laptoy is though Washington2.Dante.net and icm-dc-1-E0.icp.net. __ Erik-Jan.

6 7

Re: CIDR deployment
by avg＠titan.sprintlink.net 17 Mar '94

17 Mar '94

>Would someone in NSI care to coment about routing? Are you folks carrying >a default to your FIX-W router or what? NSI -- you may want to start peering with ICM-FIX-W and default to it. It has all the routes and does not depend on any databases. --vadim

2 1

Re: CIDR deployment
by Erik-Jan Bos 17 Mar '94

17 Mar '94

Dennis, > > NET ASN REGIONAL COUNTRY RESULT > > ------------ -------- -------------------- ------------- --------- > > 133.11.0.0 AS372(?) NSN-AMES-AS(?) Japan Unreach > > 128.250.0.0 AS372(?) NSN-AMES-AS(?) Australia Unreach > > This is not actually NSI's problem, it is caused by the fact that the > NSFnet has not been configured to accept 192.87.111/22 and hence is > not carrying it. The confusing part is that connectivity through > there to most places still works because the NSFnet has a default > route pointing at Washington2.Dante.net, which runs without route > filters. What this breaks, however, is that since NASA doesn't default > to anyone they won't be able to reach anything which isn't explicitly > announced to them, but we don't have the route to send to them. Right. The request for sending a NACR for 192.87.108/22 (not 111!) was issued today, but I was too quick, it has to be processed of course :-). I'll consider this when I publish more results tomorrow. > At the current state of the art, then, you really need to have the > aggregate configured into the NSFnet database before this will work > well. We should also consider pulling the default route from > the backbone, it is in principle no longer needed and causes no end > of confusion about where the problems are occurring. And removes the function of IGC (Internet Garbage Collector) from the Washington.date.net box. __ Erik-Jan.

1 0

CERT Advisory - SunOS /usr/ucb/rdist Vulnerability
by CERT Advisory 17 Mar '94

17 Mar '94

============================================================================= CA-94:04 CERT Advisory March 17, 1994 SunOS /usr/ucb/rdist Vulnerability ============================================================================= The CERT Coordination Center has received information concerning a vulnerability in /usr/ucb/rdist in Sun Microsystems, Inc. SunOS 4.1.1, 4.1.2, 4.1.3, and 4.1.3c on all sun3 and sun4 architectures. SunOS 4.1.3_U1, Solaris 2.x, and Solbourne's 4.1B and 4.1C are not vulnerable. This is a Sun specific Advisory. Please reference CERT Advisory CA-91:20 "/usr/ucb/rdist Vulnerability" for general information regarding other vendors. A vendor status file pub/cert_advisories/rdist-patch-status is available via anonymous FTP from info.cert.org. This vulnerability is being actively exploited; please review CERT Advisory CA-94:01 "Ongoing Network Monitoring Attacks." Patches can be obtained from local Sun Answer Centers worldwide as well as through anonymous FTP from ftp.uu.net in the /systems/sun/sun-dist directory. In Europe, these patches are available from ftp.eu.net in the /sun/fixes directory. Information concerning specific patches is outlined below. Please note that Sun sometimes updates patch files. If you find that the checksum is different, please contact Sun. ----------------------------------------------------------------------------- I. Description A security vulnerability exists in /usr/ucb/rdist that can be used to gain unauthorized privileges. Under some circumstances /usr/ucb/rdist can be used to create setuid root programs. II. Impact This vulnerability allows a local user to gain root access. III. Solution A. If rdist is not being used, change the permissions on the file. # chmod 700 /usr/ucb/rdist B. Obtain and install the appropriate patches according to the instructions included with the patches. Module Patch ID Filename ---------- --------- --------------- rdist 100383-06 100383-06.tar.Z BSD Checksum = 58984 121 System V Checksum = 9125 241 MD5 Checksum = f8f78ddab19af5efabb9bd66fc8f5c1a --------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in Forum of Incident Response and Security Teams (FIRST). Internet E-mail: cert(a)cert.org Telephone: 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. CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Past advisories, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from info.cert.org.

1 0

CIDR deployment
by yakov＠watson.ibm.com 17 Mar '94

17 Mar '94

Ref: Your note of Thu, 17 Mar 1994 18:19:24 +0100 Erik-Jan, Seems that your testing indicates connectivity problem to Far East. Do you know who is on the path from you to Far East that is CIDR-incapable ? Yakov.

1 0

Re: New supernet routes from AS 200
by avg＠titan.sprintlink.net 16 Mar '94

16 Mar '94

>FYI, we should now be originating the following CIDR routes into the NSFNET >and to our BGP4-capable peers: > > 192.216.0.0 mask 255.255.0.0 [192.216/16] > 198.31.0.0 mask 255.255.0.0 [198.31/16] > 198.92.0.0 mask 255.252.0.0 [198.92/14] > 198.92.0.0 mask 255.255.128.0 [198.92/17] > 198.93.160.0 mask 255.255.224.0 [198.93.160/19] SprintLink do not see those CIDR routes (because of CIX...). --vadim

1 0

New supernet routes from AS 200
by yakov＠watson.ibm.com 16 Mar '94

16 Mar '94

Ref: Your note of Wed, 16 Mar 94 11:16:33 PST Vince, >... because the number of our peers (i.e. CIX-WEST) are still >not yet with BGP4/CIDR... Do we have somebody from the CIX on BGPD and/or regional-techs mailing lists ? If yes, could these folks provide us with information on their schedule with respect to providing BGP4/CIDR capabilities on CIX-WEST ? Who are the other peers (besides CIX-WEST) you are referring to ? Yakov.

1 0

New supernet routes from AS 200
by noc＠barrnet.net 16 Mar '94

16 Mar '94

FYI, we should now be originating the following CIDR routes into the NSFNET and to our BGP4-capable peers: 192.216.0.0 mask 255.255.0.0 [192.216/16] 198.31.0.0 mask 255.255.0.0 [198.31/16] 198.92.0.0 mask 255.252.0.0 [198.92/14] 198.92.0.0 mask 255.255.128.0 [198.92/17] 198.93.160.0 mask 255.255.224.0 [198.93.160/19] 198.93.160/19 and 198.92/17 are more-specific subsets of 198.92/14 which are multi-homed via AS 1740 - don't know if they are announcing these yet. No more-specific routes have been withdrawn yet, principally because a number of our peers (i.e. CIX-WEST) are still not yet with the BGP4/CIDR program. --Vince

1 0