- Test - lists.nanog.org

CERT Advisory CA-95:08 - Sendmail v.5 Vulnerability
by CERT Advisory 17 Aug '95

17 Aug '95

============================================================================= CA-95:08 CERT Advisory August 17, 1995 Sendmail v.5 Vulnerability ----------------------------------------------------------------------------- The CERT Coordination Center has received reports of a vulnerability in sendmail version 5. Although this version is several years old, it is still in use. The vulnerability enables intruders to gain unauthorized privileges, including root. We recommend installing all patches from your vendor or moving to the current version of Eric Allman's sendmail (version 8.6.12). The vulnerability is currently present in all versions of IDA sendmail and in some vendors' releases of sendmail. The vendors who have reported to us are listed in Section I. As we receive additional information relating to this advisory, we will place it in ftp://info.cert.org/pub/cert_advisories/CA-95:08.README We encourage you to check our README files regularly for updates on advisories that relate to your site. ----------------------------------------------------------------------------- I. Description In sendmail version 5, there is a vulnerability that intruders can exploit to create files, append to existing files, or execute programs. The vulnerability is currently present in all versions of IDA sendmail and in some vendors' releases of sendmail. Many vendors have previously installed upgrades or developed patches to address the problem; some are working on patches now. Here is a summary of vendors who reported to us as of the date of this advisory. More details can be found in the appendix of this advisory. The appendix is reproduced in CA-95:08.README, which we will update as we receive additional information. If you do not see your vendor's name or if you have questions about the version of sendmail at your site, please contact your vendor directly. Source or Vendor Status ---------------- -------------------------------------- Eric Allman sendmail 8.6.10 or later not vul. Apple Computer, Inc. upgrades to A/UX 3.1 and 3.1.1 not vul. Berkeley SW. Design BSD/OS 2.0 vulnerable - patch available BSD/OS 2.0.1 not vulnerable Cray Research, Inc. not vulnerable Digital Equipment Corp. not vulnerable if current with patches Harris Computer Systems not vulnerable Hewlett-Packard Company not vul. - see HP bulletin #25 IBM Corporation AIX 3.2 not vulnerable with patch AIX 4.1 not vulnerable NEC Corporation vulnerable - patches available NeXT Computer, Inc. vulnerable - patch is planned Open Software Foundation not vulnerable The Santa Cruz Operation vulnerable - patches available Silicon Graphics Inc. not vulnerable if current with patches Solbourne (Grumman) vulnerable - patch is planned Sun Microsystems, Inc. Solaris 2.x not vulnerable Sun OS 4.1.3, 4.1.37u1, & 4.1.4 vul. - patch available soon Public domain: Users of the public domain operating systems Linux (systems using sendmail rather than smail), NetBSD, and FreeBSD should upgrade to sendmail 8.6.12. II. Impact Local and remote users can create files, append to existing files or run programs on the system. Exploitation can lead to root access. III. Solution A. What to do IDA users: Convert to sendmail 8.6.12. Other users: Check the vendor information in the appendix of this advisory. Ensure that you have kept current with upgrades and patches from your vendor. If no patch is currently available, an alternative is to install sendmail 8.6.12. B. What you need to know about sendmail 1. Location Sendmail is available by anonymous FTP from ftp://ftp.cs.berkeley.edu/ucb/sendmail ftp://info.cert.org/pub/tools/sendmail/sendmail.8.6.12 ftp://auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu/ucb/sendmail The checksums are MD5 (sendmail.8.6.12.base.tar.Z) = 31591dfb0dacbe0a7e06147747a6ccea MD5 (sendmail.8.6.12.cf.tar.Z) = c60becd7628fad715df8f7e13dcf3cc6 MD5 (sendmail.8.6.12.misc.tar.Z) = 6212390ca0bb4b353e29521f1aab492f MD5 (sendmail.8.6.12.patch) = 10961687c087ef30920b13185eef41e8 MD5 (sendmail.8.6.12.xdoc.tar.Z) = 8b2252943f365f303b6302b71ef9a841 2. Additional security To restrict sendmail's program mailer facility, obtain and install the sendmail restricted shell program (smrsh) by Eric Allman (the original author of sendmail), following the directions included with the program. Copies of this program may be obtained via anonymous FTP from ftp://info.cert.org/pub/tools/smrsh ftp://ftp.uu.net/pub/security/smrsh Checksum information -------------------- BSD Sum 30114 5 README 25757 2 smrsh.8 46786 5 smrsh.c System V Sum 56478 10 README 42281 4 smrsh.8 65517 9 smrsh.c MD5 Checksum MD5 (README) = fc4cf266288511099e44b664806a5594 MD5 (smrsh.8) = 35aeefba9714f251a3610c7b1714e355 MD5 (smrsh.c) = d4822ce7c273fc8b93c68e39ec67739c 3. Notes on installation Depending upon the currently installed sendmail program, switching to a different sendmail may require significant effort (such as rewriting the sendmail.cf file.) --------------------------------------------------------------------------- The CERT Coordination Center staff thanks the vendors listed in this advisory, along with Karl Strickland and Neil Woods for their support in the development of this advisory. --------------------------------------------------------------------------- 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 staff by electronic mail, we strongly advise that the email 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 Postal address: CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 USA CERT advisories and bulletins are 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. Past advisories, CERT bulletins, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from info.cert.org. Copyright 1995 Carnegie Mellon University This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and the copyright statement is included. CERT is a service mark of Carnegie Mellon University. ........................................................................... Appendix: Vendor Information Current as of August 17, 1995 See CA-95.08.README for updated information Below is information we have received from vendors about the vulnerability in sendmail version 5. If you do not see your vendor's name below, contact the vendor directly for information. ------------- Eric Allman Sendmail 8.6.10 and later are not vulnerable. The current version is 8.6.12. Because the current version addresses vulnerabilities that appear in earlier versions, it is a good idea to use 8.6.12. Sendmail is available by anonymous FTP from ftp://ftp.cs.berkeley.edu/ucb/sendmail ftp://info.cert.org/pub/tools/sendmail/sendmail.8.6.12 ftp://auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu/ucb/sendmail The checksums are MD5 (sendmail.8.6.12.base.tar.Z) = 31591dfb0dacbe0a7e06147747a6ccea MD5 (sendmail.8.6.12.cf.tar.Z) = c60becd7628fad715df8f7e13dcf3cc6 MD5 (sendmail.8.6.12.misc.tar.Z) = 6212390ca0bb4b353e29521f1aab492f MD5 (sendmail.8.6.12.patch) = 10961687c087ef30920b13185eef41e8 MD5 (sendmail.8.6.12.xdoc.tar.Z) = 8b2252943f365f303b6302b71ef9a841 ------------- Apple Computer, Inc. [The following information also appeared in CERT advisory CA-95:05, "Sendmail Vulnerabilities."] An upgrade to A/UX version 3.1 (and 3.1.1) for these vulnerabilities is available. The upgrade replaces the sendmail binary with the 8.6.10 version. It is available via anonymous FTP from ftp.support.apple.: pub/apple_sw_updates/US/Unix/A_UX/supported/3.x/sendmail/ It is also available via anonymous FTP from abs.apple.com: pub/abs/aws95/patches/sendmail/ In both cases the compressed binary has the following signature: MD5 (sendmail.Z) = 31bb15604517630f46d7444a6cfab3f1 Uncompress(1) this file and replace the existing version in /usr/lib; be sure to preserve the hard links to /usr/ucb/newaliases and /usr/ucb/mailq, kill the running sendmail and restart. Earlier versions of A/UX are not supported by this patch. Users of previous versions are encouraged to update their system or compile the latest version of sendmail available from ftp.cs.berkeley.edu. Customers should contact their reseller for any additional information. ------------- Berkeley Software Design, Inc. (BSDI) BSD/OS V2.0.1 is not vulnerable. BSD/OS V2.0 users should install patch U200-011, available from ftp.bsdi.com in bsdi/patches/U200-011. BSDI Support contact information: Phone: +1 719 536 9346 EMail: support(a)bsdi.com ------------- Cray Research, Inc. not vulnerable ------------- Digital Equipment Corp. A patch for SENDMAIL (ULTSENDMAIL_EO1044 & OSFSENDMAIL_E01032) has been available for some time, so if you have kept current with patches you are not vulnerable to this particular reported problem. If you have not applied the kits above, Digital Equipment Corporation strongly urges customers to upgrade to the latest versions of ULTRIX V4.4 or DIGITAL DEC OSF/1 V3.2, then apply the appropriate sendmail solution kit. The above kits can be obtained through your normal Digital support channels or by access (kit) request via DSNlink, DSIN, or DIA. ------------- Grumman Systems Support Corporation (GSSC) GSSC now performs all Solbourne software and hardware support. We recommend running sendmail 8.6.10 (or later revision.) 8.6.12 has proven reliable in production use on Solbourne systems. We plan to release the Solbourne version of the Sun patch when it becomes available. Contact info: ftp: ftp.nts.gssc.com phone: 1-800-447-2861 email: support(a)nts.gssc.com ------------- Harris Computer Systems not vulnerable ------------- Hewlett-Packard Company Hewlett-Packard issued security bulletin #25 on April 2, 1995 announcing patches and describing a fix. The patches are PHNE_5402 (series 700/800, HP-UX 9.x), or PHNE_5401 (series 700/800, HP-UX 8.x), or PHNE_5384 (series 300/400, HP-UX 9.x), or PHNE_5383 (series 300/400, HP-UX 8.x), or PHNE_5387 (series 700, HP-UX 9.09), or PHNE_5388 (series 700, HP-UX 9.09+), or PHNE_5389 (series 800, HP-UX 9.08) The bulletin is available from the HP SupportLine and from http://www.hp.com in the HPSL category and from http://support.mayfield.hp.com. Patches may be obtained from HP via FTP (this is NOT anonymous FTP) or the HP SupportLine. To obtain HP security patches, you must first register with the HP SupportLine. The registration instructions are available via anonymous FTP at info.cert.org in the file "pub/vendors/hp/supportline_and_patch_retrieval". HP SupportLine: 1-415-691-3888 phone: 1-415-691-3680 telnet/ftp: support.mayfield.hp.com WWW: http://www.hp.com http://support.mayfield.hp.com. ------------- IBM Corporation A patch (ptf U425863) has been available for AIX 3.2 for some time. To determine if you have this ptf on your system, run the following command: % lslpp -lB U425863 If you have not already applied the patch, you can order it from IBM as APAR ix40304 To order APARs from IBM in the U.S., call 1-800-237-5511. To obtain APARs outside of the U.S., contact your local IBM representative. ------------- NEC Corporation OS Version Status ------------------ ------------ ------------------------------ EWS-UX/V(Rel4.0) R1.x - R6.x vulnerable EWS-UX/V(Rel4.2) R7.x - R10.x vulnerable patch available EWS-UX/V(Rel4.2MP) R10.x vulnerable patch available UP-UX/V R1.x - R4.x vulnerable UP-UX/V(Rel4.2MP) R5.x - R7.2 vulnerable patch available except for R5.x UX/4800 R11.x not vulnerable Contacts for further information: e-mail:UXcert-CT@d2.bsd.nes.nec.co.jp ------------- NeXT Computer, Inc. The sendmail executables included with all versions of NEXTSTEP up to and including release 3.3 are vulnerable to this problem. The SendmailPatch previously released for NEXTSTEP 3.1 and 3.2 is also vulnerable. An updated patch is planned which will address this vulnerability. The availability of this patch will be indicated in the NeXTanswers section of http://www.next.com/. For further information you may contact NeXT's Technical Support Hotline at (+1-800-955-NeXT) or via email to ask_next(a)NeXT.com. ------------- Open Software Foundation not vulnerable ------------- The Santa Cruz Operation Support Level Supplement (SLS) net382e, contains a patched version of sendmail for the following releases: SCO TCP/IP Runtime System Release 1.2.1 SCO Open Desktop Lite Release 3.0 SCO Open Desktop Release 3.0 SCO Open Server Network System Release 3.0 SCO Open Server Enterprise System Release 3.0 SCO OpenServer 5 contains Sendmail version 8.6.8, and contains fixes to all problems reported in this and previous sendmail advisories. Users of previous releases should consider updating. NOTE: The MMDF (M)ulti-Channel (M)emorandum (D)istribution (F)acility is the default mail system on SCO systems. The MMDF mail system is not affected by any of the problems mentioned in these advisories. Administrators who wish to use sendmail must specifically configure the system to do so during or after installation. To acquire SLS net382e: Anonymous ftp on the Internet: ============================== ftp://ftp.sco.COM/SLS/net382e.Z (disk image) ftp://ftp.sco.COM/SLS/net382e.ltr.Z (documentation) Anonymous uucp: =============== United States: -------------- sosco!/usr/spool/uucppublic/SLS/net382e.Z (disk image) sosco!/usr/spool/uucppublic/SLS/net382e.ltr.Z (documentation) United Kingdom: --------------- scolon!/usr/spool/uucppublic/SLS/net382e.Z (disk image) scolon!/usr/spool/uucppublic/SLS/net382e.ltr.Z (documentation) The telephone numbers and login names for the machines sosco and scolon are provided with the default /usr/lib/uucp/Systems file shipped with every SCO system. The checksums for the files listed above are as follows: file sum -r md5 =========================== ================================ net382e.Z: 29715 1813 41efeaaa855e4716ed70c12018014092 net382e.ltr.Z 52213 14 287ba6131519cba351bc58cb32880fda The Support Level Supplement is also available on floppy media from SCO Support at the following telephone numbers: USA/Canada: 6am-5pm Pacific Daylight Time (PDT) ----------- 1-408-425-4726 (voice) 1-408-427-5443 (fax) Pacific Rim, Asia, and Latin American customers: 6am-5pm Pacific ------------------------------------------------ Daylight Time (PDT) 1-408-425-4726 (voice) 1-408-427-5443 (fax) Europe, Middle East, Africa: 9am-5:00pm Greenwich Mean Time (GMT) ---------------------------- +44 1923 816344 (voice) +44 1923 817781 (fax) For further information, contact SCO at one of the above numbers, send electronic mail to support(a)sco.COM, or see the SCO Web Page at: http://www.sco.COM. ------------- Silicon Graphics Inc. On February 22, 1995, Silicon Graphics issued security advisory 19950201 addressing sendmail issues being raised at the time and previous older version sendmail issues. Patches are still available and as part of these patches, sendmail version 8.6.12 is provided as standard. At the time of this writing here is the patch information. **** IRIX 3.x **** Unfortunately, Silicon Graphics Inc, no longer supports the IRIX 3.x operating system and therefore has no patches or binaries to provide. However, two possible actions still remain: 1) upgrade the system to a supported version of IRIX (see below) and then install the binary/patch or 2) obtain the sendmail source code from anonymous FTP at ftp.cs.berkeley.edu and compile the program manually. **** IRIX 4.x **** For the IRIX operating system version 4.x, a manually installable binary replacement has been generated and made available via anonymous ftp and/or your service/support provider. The binary is sendmail.new.Z and is installable on all 4.x platforms. The SGI anonymous ftp site is ftp.sgi.com (192.48.153.1). The binary maybe be found in the following directories on the ftp server: ~ftp/Security or ~ftp/Patches/4.x ##### Checksums #### Filename: sendmail.new.Z Algorithm #1 (sum -r): 27178 422 sendmail.new.Z Algorithm #2 (sum): 46012 422 sendmail.new.Z MD5 checksum: 146DD1019673D7C2C89A78D7ACF85CF6 After obtaining the binary, it may be installed with the instructions below: 1) Become the root user on the system. % /bin/su - Password: # 2) Stop the current mail processes. # /etc/init.d/mail stop 3) Rename the current sendmail binary to a temporary name. # mv /usr/lib/sendmail /usr/lib/sendmail.stock 4) Change permissions on the old sendmail binary so it can not be used anymore. # chmod 0400 /usr/lib/sendmail.stock 5) Uncompress the binary. # uncompress /tmp/sendmail.new.Z 6) Put the new sendmail binary into place (in the example here the binary was retrieved via anonymous ftp and put in /tmp) # mv /tmp/sendmail.new /usr/lib/sendmail 7) Insure the correct permissions and ownership on the new sendmail. # chown root.sys /usr/lib/sendmail # chmod 4755 /usr/lib/sendmail 8) Restart the mail system with the new sendmail binary in place. # /etc/init.d/mail start 9) Return to normal user level. # exit **** IRIX 5.0.x, 5.1.x **** For the IRIX operating systems versions 5.0.x, 5.1.x, an upgrade to 5.2 or better is required first. When the upgrade is completed, then the patch described in the next section "**** IRIX 5.2, 5.3, 6.0, 6.0.1 ***" can be applied. **** IRIX 5.2, 5.3, 6.0, 6.0.1 **** For the IRIX operating system versions 5.2, 5.3, 6.0 and 6.0.1, an inst-able patch has been generated and made available via anonymous ftp and/or your service/support provider. The patch is number 332 and will install on IRIX 5.2, 5.3, 6.0 and 6.0.1 . The SGI anonymous ftp site is ftp.sgi.com (192.48.153.1). Patch 332 can be found in the following directories on the ftp server: ~ftp/Security or ~ftp/Patches/5.2 ~ftp/Patches/5.3 ~ftp/Patches/6.0 ~ftp/Patches/6.0.1 For obtaining security information, patches or assistance, please contact your SGI support provider. If there are questions about this patch information, email can be sent to cse-security-alert(a)csd.sgi.com . For reporting new SGI security issues, email can be sent to security-alert(a)sgi.com . ------------- Solbourne see Grumman Systems Support Corporation ------------- Sun Microsystems, Inc. Solaris 2.x is not vulnerable. Sun OS 4.1.3, 4.1.37u1, and 4.1.4 are vulnerable, and a patch will be available soon. This patch can be obtained from local Sun Answer Centers and through anonymous FTP from ftp.uu.net in the /systems/sun/sun-dist directory. In Europe, the patch is available from mcsun.eu.net (192.16.202.1) in the /sun/fixes directory.

1 0

Re: CIDR FAQ
by Scott Bradner 17 Aug '95

17 Aug '95

> You can't strip a non-zero part of IPv6 address > as this would cause transport layer pseudo-header checksum to fail which is why the compatable address has 96 0s in the prefix Scott

1 0

Re: CIDR FAQ
by owen＠DeLong.SJ.CA.US 17 Aug '95

17 Aug '95

> Peter, > > > > > BTW - I have not studied the RFC's - so what will IPv6 do for us in > > the contect of routeing aggregation and latger boxes etc ? > > > > Couple of observations: > > 1. The ability to aggregate routing information depends > on how addresses are assigned, but does not depend on whether > addresses are 32 bits wide or 128 bits wide. > > 2. IPv6 address allocation architecture (see > draft-ietf-ipngwg-unicst-addr-allo-01.txt) is the same as IPv4. > (just so that folks who read this note would have no doubts, > the IPv6 Address Allocation Architecture document was written > by Tony Li and myself - the same people who wrote the CIDR Address > Allocation Architecture document). > > Conclusion: > > In the area of routing aggregation IPv6 will do for us *exactly the same* > as what IPv4 does. > With one notable exception.... No allocation legacies. That is there aren't any old badly-distributed ipv6 addresses floating around. This means that ipv6 aggregation should be substantially more effective than ipv4 CIDR has been. > Yakov. > Owen

6 9

Re: CIDR FAQ
by lear＠yeager.corp.sgi.com 16 Aug '95

16 Aug '95

At the last CIDR meeting did we not have a volunteer to go out and actually run some prediction tools to see where were going, and why? I realize you guys are doing the best you can merely to keep up with the day's troubles, but I'd really like to see some more data on growth. -- Eliot Lear [lear(a)sgi.com]

1 0

Re: CIDR FAQ (off topic)
by afink＠ping.ch 16 Aug '95

16 Aug '95

Please dont CC your messages to local-ir(a)ripe.net. Its off topic there. Thank you ---------------------------------------------------------------- To: peter(a)demon.net Cc: nathan(a)netrail.net, dsiegel(a)net99.net, jon(a)branch.com, sob(a)academ.com, bwatson(a)mci.net, jerry(a)fc.net, inet-access(a)earth.com, HANK(a)taunivm.tau.ac.il, nanog(a)merit.edu, local-ir(a)ripe.net, iap(a)vma.cc.nd.edu, yakov(a)cisco.com Subject: Re: CIDR FAQ Date: Wed, 16 Aug 95 05:47:43 PDT From: Yakov Rekhter <yakov(a)cisco.com> Peter, > > BTW - I have not studied the RFC's - so what will IPv6 do for us in > the contect of routeing aggregation and latger boxes etc ? > Couple of observations: 1. The ability to aggregate routing information depends on how addresses are assigned, but does not depend on whether addresses are 32 bits wide or 128 bits wide. 2. IPv6 address allocation architecture (see draft-ietf-ipngwg-unicst-addr-allo-01.txt) is the same as IPv4. (just so that folks who read this note would have no doubts, the IPv6 Address Allocation Architecture document was written by Tony Li and myself - the same people who wrote the CIDR Address Allocation Architecture document). Conclusion: In the area of routing aggregation IPv6 will do for us *exactly the same* as what IPv4 does. Yakov. Andreas Fink --------------------------------------------------------------------- Ping Net GmbH, Dorfstrasse 21, 8902 Urdorf, Switzerland afink(a)ping.ch http://www.ping.ch/ Tel: 01-7358333 Fax: 01-7358334 Administration: admin(a)ping.ch Tech Support: support(a)ping.ch --------------------------------------------------------------------- Ping Net Sarl, World Trade Cent er, Av. Gratta Paille 2, 1000 Lausanne 30, Switzerland. Tel: 021-6411339 Fax: 021-6411310 ---------------------------------------------------------------------

1 0

Re: CIDR FAQ
by jgs＠aads.net 16 Aug '95

16 Aug '95

At 11:00 AM 8/15/95, Dave Siegel wrote: >Let's excuse the fact that gated consumes more memory than a cisco for the >same amount of routes for a second... > >Okay, so let's talk functionality. > >Are there HSSI PCI cards available? Can you do SMDS over this card? Frame? >What about a DS3 ATM card, or higher? And Paul Traina wrote something vaguely similar. I think you guys are both missing what I think was Jon's original point: Routers forward packets faster than PCs, but the forwarding function and the routing protocol function do not have to reside on the same box. You can add a PC (workstation, whatever) which runs the routing protocol and stuffs routes into the router. It doesn't have to support the link-layer du jour. Ethernet will do the job just fine. As I recall the original discussion was of colocating a router, to forward packets, with a workstation, to compute routes. --John

7 10

Re: routing meltdown
by kwe＠6SigmaNets.com 16 Aug '95

16 Aug '95

At 2:08 PM 8/11/95, Paul A Vixie wrote: > >I clearly think that colocated workstations are better than route processors >inside the routers themselves. I'm less certain that they are better than >route servers and a unified/recursive/realtime RADB. I'm not sure at all >that any interconnect can, should, or ever shall require this kind of dual- >routing setup for its members. In other words, why are we discussing this? I like the idea of workstation-based route processors over forwarding/routing engines because it decouples the complex route processing s/w environment from the forwarding function. The economics of complex route processing don't match the economics of big honking routers and workstations are a better development environment. The reason to talk about it here is that if we are to move forward in this direction we need a simple exchange protocol between route server and forwarding engine to make this happen. --Kent

1 0

Re: CIDR FAQ
by Sean Doran 15 Aug '95

15 Aug '95

| Once the market is there, its usually too late for the poor fools | running the backbone. Hi there. I'm one of those "poor fools". Could you please take this off NANOG? Given the level of factual content, I humbly suggest com-priv as the appropriate venue for this enlightening conversation. Thanks. Sean. - -- Sean Doran <smd(a)sprint.net>

1 0

Re: CIDR FAQ
by Nicolas Williams 15 Aug '95

15 Aug '95

Tony Li previously wrote: > The original post was about making time at the Pittsburg NANOG meeting > to talk about solutions to the problem of some exchange routers seeing > tens of thousands (even 100x) paths. The size of a full-Internet route > table is growing (albeit more slowly than it used to), the number of > ASes meeting at the various NAPs and MAEs is increasing, etc. Will the > number of paths heard by some routers at the XPs ever be so large that > they don't fit in the 7000 or 4500m's 64MB of RAM? Possibly (IMHO, > likely). What then? Use lots of filtering to keep the number of paths > heard down and lose flexibility? >Then I ask you to sign a nondisclosure agreement. ;-) Oh, then the whole argument is for naught. :) >We've actually been very good (some say too good) about adding >features. Yes, Cisco is very good about adding software features and even about allowing its customers to beta test software. >Tony > Nick

3 5

Re: CIDR FAQ
by jgs＠aads.net 15 Aug '95

15 Aug '95

At 7:23 PM 8/15/95, Nicolas Williams wrote: [...] >Colocated BGP4 "proxies" (I'm still not sure what to call these, >anyone?) [...] How about RCP (routing control processor)? And you could call the forwarding box a PSP (packet switching processor). Unless of course IBM has trademarked these or something. --John P.S.: For nostalgia's sake the RCP and PSP could talk over a 4 Mbit token-ring.

1 0