- Test - lists.nanog.org

Re: 20402 routing entries
by epg＠merit.edu 14 Apr '94

14 Apr '94

Vince asks: > > Question to the MERIT folks: have you had any luck (and have you tried) using > the ASxxx(a)MERIT.EDU mailing lists to try and get in touch with those non-BGP4 > sites which might not be on the BGPD or Regional Techs mailing list? I'm likely > asking the obvious, but... > > --Vince > Yes, we have again started trying to get folks to move to BGP4 - heck we are still trying to get some folks to move to BGP. The results are slow in coming. --Elise

1 0

CERT Advisory /tmp/cert.org.ftp.files/CA-94:08.ftpd.vulnerabilities
by cert-advisory＠cert.org 14 Apr '94

14 Apr '94

============================================================================= CA-94:08 CERT Advisory April 14, 1994 ftpd Vulnerabilities ----------------------------------------------------------------------------- The CERT Coordination Center has received information concerning two vulnerabilities in some ftpd implementations. The first is a vulnerability with the SITE EXEC command feature of the FTP daemon (ftpd) found in versions of ftpd that support the SITE EXEC feature. This vulnerability allows local or remote users to gain root access. The second vulnerability involves a race condition found in the ftpd implementations listed in Section I. below. This vulnerability allows local users to gain root access. Sites using these implementations are vulnerable even if they do not support anonymous FTP. As these vulnerabilities are widely known, we strongly recommend that any site running a version of ftpd listed below take steps to immediately upgrade or disable their FTP daemon. Also potentially at risk are sites whose ftpd is derived from the DECWRL or wuarchive ftpd code containing the SITE EXEC feature. For additional information or assistance, contact the developer or vendor of your ftpd implementation. If we receive additional information relating to this advisory, we will place it, along with any clarifications, in a README file available by anonymous FTP from info.cert.org (e.g., /pub/cert_advisories/CA-94:xx.README). We encourage you to check our README files regularly for updates on advisories that relate to your site. ----------------------------------------------------------------------------- I. Description There is a vulnerability in the SITE EXEC command feature of ftpd that allows any remote or local user to obtain root access. There is also a vulnerability due to a race condition in these implementations. Versions known to be vulnerable to these problems are: wuarchive ftpd versions 2.0-2.3 (version 2.2 patched the SITE EXEC problem, but not the race condition) DECWRL ftpd versions prior 5.93 BSDI ftpd version 1.1 prior to patch 5 The SITE EXEC vulnerability affects your ftpd only if the SITE EXEC command feature has been explicitly activated at your site. This functionality is not activated by default. Sites that have not enabled the SITE EXEC feature are not at risk from this vulnerability. However, since the race condition does not have an easily applied workaround, CERT recommends that you upgrade to one of the versions listed below. II. Impact Anyone (remote or local) can gain root access on a host running a vulnerable FTP daemon. Support for anonymous FTP is not required to exploit this vulnerability. III. Solution Affected sites can solve both of these problems by upgrading to the latest version of ftpd. These versions are listed below. Be certain to verify the checksum information to confirm that you have retrieved a valid copy. If you cannot install the new version in a timely manner, you should disable FTP service until you have corrected this problem. It is not sufficient to disable anonymous FTP. You must disable the FTP daemon. For wuarchive ftpd, you can obtain version 2.4 via anonymous FTP from wuarchive.wustl.edu, in the "/packages/wuarchive-ftpd" directory. If you are currently running version 2.3, a patch file is available. BSD SVR4 File Checksum Checksum MD5 Digital Signature ----------------- -------- --------- -------------------------------- wu-ftpd-2.4.tar.Z 38213 181 20337 362 cdcb237b71082fa23706429134d8c32e patch_2.3-2.4.Z 09291 8 51092 16 5558a04d9da7cdb1113b158aff89be8f For DECWRL ftpd, sites can obtain version 5.93 via anonymous FTP from gatekeeper.dec.com in the "/pub/misc/vixie" directory. BSD SVR4 File Checksum Checksum MD5 Digital Signature ----------------- -------- --------- -------------------------------- ftpd.tar.gz 38443 60 1710 119 ae624eb607b4ee90e318b857e6573500 For BSDI systems, patch 005 should be applied to version 1.1 of the BSD/386 software. You can obtain the patch file via anonymous FTP from ftp.bsdi.com in the "/bsdi/patches-1.1" directory. BSD SVR4 File Checksum Checksum MD5 Digital Signature ----------------- -------- --------- -------------------------------- BU110-005 35337 272 54935 543 1f454d4d9d3e1397d1eff0432bd383cf --------------------------------------------------------------------------- The CERT Coordination Center wishes to thank Neil Woods and Karl Strickland for finding and reporting the wustl FTP daemon bug. We also wish to thank Bryan O'Connor and Chris Myers of Washington University in St. Louis, Paul Vixie of Vixie Enterprises, and Tony Sanders of BSDI for their invaluable assistance in resolving this problem. --------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in the Forum of Incident Response and Security Teams (FIRST). If you wish to send sensitive incident or vulnerability information to CERT via electronic mail, CERT strongly advises that the e-mail be encrypted. CERT can support a shared DES key, PGP (public key available via anonymous FTP on info.cert.org) or PEM (contact CERT for details). 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 via anonymous FTP from info.cert.org.

1 0

722 Nets, 23 ASs, 98 Aggregates
by yakov＠watson.ibm.com 14 Apr '94

14 Apr '94

Ref: Your note of Thu, 14 Apr 1994 11:50:18 -0400 Marty, >The way I read your message is that all new network numbers should >be CIDRized You misread my message (but this is probably my fault as well, since I wasn't clear enough). So, let me try again. What I suggested is that if a site has a contiguous block of network numbers (such that this block could be reduced to a small number of IP address prefixes), then this site should be announced to the Internet as just the prefixes, rather than a set of individual network numbers. Yakov.

1 0

722 Nets, 23 ASs, 98 Aggregates
by Dale S. Johnson 14 Apr '94

14 Apr '94

Good News from the CIDR Press!! AS690 CIDR Squeezings Report: 722 Nets, 23 ASs, 98 Aggregates -------------------------------------------------------------- 722 (35%) of the ever-announced more-specific routes within aggregates have been withdrawn. 442 of those were withdrawn within the last week. 155 the week before that. 122 the week before that. 23 ASs have registered aggregates in the PRDB. 20 of those are announcing aggregates. 11 have withdrawn at least one more specific route. 98 Aggregates are configured. 88 of these were Top-Level Aggregates (not nested in another aggregate). 69 of these were announced to AS690 as of yesterday. 58 of those have at least one subnet configured (the other 11 may be saving. the Internet future subnet announcements). 29 have stopped announcing at least one configured more specific route. 19 have stopped announcing half of their configured more specific routes. 16 have stopped announcing most (80%) of their more specific routes. See merit.edu:pub/nsfnet/cidr/cidr_savings for more detail. -----------------------------------------------------------

2 1

Re: Problems with BARRNET network 131.119.250.119
by noc＠barrnet.net 12 Apr '94

12 Apr '94

Our mailer tries to deliver mail to 131.119.250.119 (bargate.silvaco.com, SILVACO.BARRNET.NET) and gets host unreachable. Routes for 131.119.0.0 are given as: gw3#sh ip ro 131.119.0.0 Routing entry for 131.119.0.0 (mask 255.255.255.0), 2 known subnets Redistributing via igrp 51771 B 131.119.246.0 [200/100] via 193.23.5.33, 16:10:55 B 131.119.253.0 [200/100] via 193.23.5.33, 16:11:51 This is odd. You should have a route to 131.119.0.0/255.255.0.0 which handles all subnets of 131.119. Is it useful to add Class-B-Subnets to the routing table whilst we are trying to reduce Class-C entries? This was an oversight. We are sending the subnet routes to ENSS128 in order to insure correct next-hop resolution across our DMZ network. These subnets should not have been sent to other external peers and no longer will be. Vince Fuller/BARRNet P.S. In the future, you will receive faster response if you send BARRNet problem reports directly to us, either to "noc(a)BARRNET.NET" or to the MERIT-maintained trouble list "as200-trouble(a)MERIT.EDU".

3 2

Re: Problems with BARRNET network 131.119.250.119
by noc＠barrnet.net 12 Apr '94

12 Apr '94

These must be going through another AS path. AS 690 blocks further redistribution of your more specific routes. Does anyone have an AS path for these routes? Curtis- I believe the problem was at the CIX - we were not filtering-out the 131.119 subnets in our BGP advertisements to them. This has been fixed. --Vince

1 0

Re: Draft minutes ALE WG
by Vince Fuller 12 Apr '94

12 Apr '94

BTW there will be a BOF at INTEROP Thursday night on RFC 1597. Out of curiosity, are there going to be other BOF or IETF-related meetings at Interop with technical substance sufficient to motivate one to go? The last couple of years have seen Interop become more and more of a marketing and sales (aka dog and pony) show and less of a technical conference. This year, since it isn't just up the road from here, some of us have much less incentive to go than in previous years. Opinions explicitly solicited - I will summarize if anyone cares. --Vince

1 0

493 Nets in 93 Aggregates
by yakov＠watson.ibm.com 12 Apr '94

12 Apr '94

Ref: Your note of Mon, 11 Apr 94 20:39:08 MET DST Peter, >May I suggest that we inherit some of the techniques from the >phone-marketing people, and actively go after people that >could reduce their routing announcements by using CIDR ? One useful step in this direction would be identify individual sites that have a large block of contiguous Class C networks, and then go after these sites first. This would allow us to maximize the "return on investment". Yakov. P.S. As a matter of fact, I wonder whether we can get a list of sites that have Class C networks sorted (in descreasing order) by the number of contiguous Class C networks assigned to a site.

2 1

None
by John J. Hedderman (ANS Install Eng) 12 Apr '94

12 Apr '94

FYI. This is a large step in getting ASes 1321-1333 fully CIDR-compliant. ANS will now be working on the aggregations themselves. - John --------------- Received: from interlock.ans.net by home.ans.net with SMTP id AA13587 (5.65c/IDA-1.4.4); Tue, 12 Apr 1994 10:06:28 -0400 Received: from knock.aa.ans.net by interlock.ans.net with SMTP id AA30279 (InterLock SMTP Gateway 1.1); Tue, 12 Apr 1994 10:10:55 -0400 Received: by knock.aa.ans.net id AA45218 (5.65c/IDA-1.4.4); Tue, 12 Apr 1994 14:11:10 GMT Date: Tue, 12 Apr 1994 14:11:10 GMT From: Serpil Bayraktar <sbb> Message-Id: <199404121411.AA45218(a)knock.aa.ans.net> To: ans-neteng(a)ans.net, install-eng(a)ans.net, nnaf(a)ans.net All the core CISCOs have been upgraded to 9.21+bgp4.2.2 and they are running BGP4 with AS 690. Serpil

1 0

Problems with BARRNET network 131.119.250.119
by xladm＠xlink.net 12 Apr '94

12 Apr '94

Our mailer tries to deliver mail to 131.119.250.119 (bargate.silvaco.com, SILVACO.BARRNET.NET) and gets host unreachable. Routes for 131.119.0.0 are given as: gw3#sh ip ro 131.119.0.0 Routing entry for 131.119.0.0 (mask 255.255.255.0), 2 known subnets Redistributing via igrp 51771 B 131.119.246.0 [200/100] via 193.23.5.33, 16:10:55 B 131.119.253.0 [200/100] via 193.23.5.33, 16:11:51 gw3#sh ip bgp 131.119.246.0 BGP routing table entry for 131.119.246.0/255.255.255.0, version 2409868 Paths: (1 available, best #1) 1273 1755 1800 1239 1280 200 193.23.5.33 (metric 108166) from 192.54.104.130, localpref 100, weight 210 Origin IGP, valid, internal, best gw3#sh ip bgp 131.119.253.0 BGP routing table entry for 131.119.253.0/255.255.255.0, version 2409849 Paths: (1 available, best #1) 1273 1755 1800 1239 1280 200 193.23.5.33 (metric 108166) from 192.54.104.130, localpref 100, weight 210 Origin IGP, valid, internal, best Is it useful to add Class-B-Subnets to the routing table whilst we are trying to reduce Class-C entries? Regards, Arnold -- XLINK Hostmaster of the day / NTG Netzwerk und Telematic GmbH \/ phone: +49 721 9652 0 Geschaeftsbereich XLINK /\ LINK fax: +49 721 9652 210 Vincenz-Priessnitz-Str. 3 /_______ email: hostmaster(a)xlink.net D-76131 Karlsruhe, Germany

1 0