- Test - lists.nanog.org

MBone broadcast of Monday's and Tuesday's Meetings.
by Matt Mathis 10 Sep '95

10 Sep '95

The meetings on Monday and Tuesday will be multicast. See "NANOG" under sd for the details. We successfully tested full duplex operation through the PA system, and expect to be able to include the MBone audience in the discussion, contingent on the good behavior of the MBone itself. One warning: We will be running with "net mutes mike", to permit people on the MBone to interject comments. The downside to this is that if anyone leaves a mike open, it will disrupt the meeting. Please no not unmute you mike or depend on "VOX" unless you are actively participating in the conversation. Open mikes will be silenced on our end, effectively removing you from the discussion. Thanks, --MM--

1 0

Re: What do you use interdomain routing for?
by nordlund＠databank.com 08 Sep '95

08 Sep '95

> >HI, > >We are looking at requirements for interdomain routing, and are >interested to know what you use it for. For instance, do you use >interdomain routing to select transit carriers for some traffic in >preference to other carriers. Neal What do you mean by "interdomain" routing? Is this inter ASN routing? Or is this OSPF Interarea routing? > >Are there policies that you would like to be able to implement that you are >unable to because of limitations in the available protocols? How much >would you be willing to slow down your forwarding rates in order to >have the capability? > >Please send me your answers and I'll summarize. > > --Neal > Dave Nordlund Dir of Technical Svcs Databank, Inc 913/842-6699 1473 Hwy 40 nordlund(a)databank.com Lawrence, KS 66044 "Your Key to the Internet

1 0

Fwd: You have been removed from the list
by MBYRON10＠aol.com 08 Sep '95

08 Sep '95

I don't understand I am receiving your post fine? The bounce must be someones misstake! Fwd-2 ______________________________________ Subj: PGP authentication for the RADB Date: Thu, Sep 7, 1995 12:53 PM EDT From: renaud(a)MERIT.EDU X-From: renaud(a)MERIT.EDU (Brian Renaud) Sender: renaud(a)MERIT.EDU Resent-from: nanog(a)MERIT.EDU Reply-to: renaud(a)MERIT.EDU To: nanog(a)MERIT.EDU The RADB now supports authentication using PGP-based digital signatures. If you want to use this feature, there are three things you must do: * Register your public key with the RA. * Modify your maintainer object to reflect your use of digital signatures * Sign (via PGP) your RADB transactions. 1. Registering your public key with the RA. You must send your public key to the RA for inclusion onto our PGP keyring. Use the "pgp -kxa" command to generate a copy of your public key suitable for mailing, then mail the resultant file to db-admin(a)ra.net. For example: % pgp -kxa smith(a)ra.net pubkey ... % mail -s 'please register my public key' db-admin(a)ra.net < pubkey.asc You may use one of two methods of verification: * Fax a copy of a photographic identification (passport or drivers license) to: RADB public key verification +1 313 747 3185 please write your PGP fingerprint and email address on the fax * Attend an RA sponsored key signing session at NANOG or IETF. You will need to bring a copy of your public key with a PGP fingerprint and photo identification. (This will be verification via the identification you bring, rather than having two other people agree that you are who you say you are.) We will be holding a key signing at NANOG on Monday, September 11 at 5:00. If that time is not convenient, you can also accost RA team members at random and present them with with the appropriate information. 2. Modifications to the maintainer object There is a new authentication option for the maintainer object. The syntax for it is: auth: PGP-FROM {PGP User Id} For example, auth: PGP-FROM John Smith <smith(a)ra.net> 3. Signing your RADB transactions You will need to PGP-sign each transaction you send to auto-dbm(a)ra.net. Use the "pgp -sta" command to do this. For example: % pgp -sta -u smith(a)ra.net routes ... % mail -s 'route updates' auto-dbm(a)ra.net < routes.asc ----------------------- Headers -------------------------------- >From nanog-request(a)MERIT.EDU Thu Sep 7 12:54:50 1995 Return-Path: nanog-request(a)MERIT.EDU Received: from merit.edu (merit.edu [35.1.1.42]) by emin04.mail.aol.com (8.6.12/8.6.12) with ESMTP id MAA03037 for <MBYRON10(a)aol.com>; Thu, 7 Sep 1995 12:54:37 -0400 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id LAA03917; Thu, 7 Sep 1995 11:52:35 -0400 Resent-Date: Thu, 7 Sep 1995 11:52:35 -0400 Message-Id: <199509071552.LAA21225(a)home.merit.edu> From: Brian Renaud <renaud(a)MERIT.EDU> To: nanog(a)MERIT.EDU Subject: PGP authentication for the RADB Reply-To: renaud(a)MERIT.EDU Date: Thu, 07 Sep 1995 11:52:31 -0400 Sender: renaud(a)MERIT.EDU Resent-Message-ID: <"obcC1.0.5z.2LnJm"@merit.edu> Resent-From: nanog(a)MERIT.EDU X-Mailing-List: <nanog(a)MERIT.EDU> archive/latest/24 X-Loop: nanog(a)MERIT.EDU Precedence: list Resent-Sender: nanog-request(a)MERIT.EDU --------------------- Forwarded message: From: nanog-request(a)MERIT.EDU To: MBYRON10(a)aol.com Date: 95-09-07 12:38:12 EDT Your mail address MBYRON10(a)aol.com has been removed from the nanog(a)MERIT.EDU mailinglist. It generated an excessive amount of bounced mails. Before sending in a subscription request to nanog-request(a)MERIT.EDU again, please ensure that this problem has been resolved. When in doubt, ask your system administrator or send mail to "postmaster". The last one of those bounced mails has been quoted below: >From MAILER-DAEMON Thu Sep 7 12:10:01 1995 >Received: from localhost (localhost) by merit.edu (8.6.12/merit-2.0) with internal id MAA03450; Thu, 7 Sep 1995 12:10:01 -0400 >Date: Thu, 7 Sep 1995 12:10:01 -0400 >From: Mail Delivery Subsystem <MAILER-DAEMON> >Subject: Returned mail: User unknown >Message-Id: <199509071610.MAA03450(a)merit.edu> >To: nanog-request(a)MERIT.EDU > >The original message was received at Thu, 7 Sep 1995 11:42:00 -0400 >from slist@localhost > > ----- The following addresses had delivery problems ----- >tom(a)news1.mnsinc.com (unrecoverable error) > > ----- Transcript of session follows ----- >edm(a)nwnexus.wa.com... Deferred: Connection timed out during initial connection with nwnexus.wa.com. >... while talking to zippy.cais.net.: >>>> RCPT To:<tom(a)zippy.cais.net> ><<< 550 <tom(a)zippy.cais.net>... User unknown >550 tom(a)news1.mnsinc.com... User unknown >noah(a)gxl.woodtech.com... Deferred: Connection timed out during initial connection with gxl.woodtech.com. >451 bob@databank.com,nordlund@databank.com... reply: read error from exodus.databank.com. >451 NEAL_CASTAGNOLI@novell.com,RHADDOCK@novell.com... timeout waiting for input during client greeting >451 NEAL_CASTAGNOLI@novell.com,RHADDOCK@novell.com... reply: read error from umx-hub.novell.com. >NEAL_CASTAGNOLI@novell.com,RHADDOCK@novell.com... Deferred: Connection timed out during initial connection with ums-hub.novell.com. >451 MBYRON10(a)aol.com... reply: read error from mail05.mail.aol.com. >MBYRON10(a)aol.com... Deferred: Connection reset by peer during client greeting with mail05.mail.aol.com. > > ----- Message header follows ----- >Return-Path: nanog-request(a)MERIT.EDU >Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id LAA03439; Thu, 7 Sep 1995 11:42:00 -0400 >Resent-Date: Thu, 7 Sep 1995 11:42:00 -0400 >Date: Thu, 7 Sep 95 11:35:17 -0400 >From: nrm1838(a)rserver3.dsac.dla.mil (James Cassell) >Message-Id: <9509071535.AA02406(a)rserver3.dsac.dla.mil> >X-Mailer: Ez-Mail v4.4 <Date: Thu, 07 Sep 95 11:41:31 nrm1838> >To: nanog(a)MERIT.EDU >Subject: Re: Pittsburgh directions >Old-Status: N >Resent-Message-ID: <"Rj0Gu.0.hr.7BnJm"@merit.edu> >Resent-From: nanog(a)MERIT.EDU >X-Mailing-List: <nanog(a)MERIT.EDU> archive/latest/23 >X-Loop: nanog(a)MERIT.EDU >Precedence: list >Resent-Sender: nanog-request(a)MERIT.EDU > > ----- Message body suppressed ----- >

1 0

What do you use interdomain routing for?
by Neal Castagnoli 07 Sep '95

07 Sep '95

HI, We are looking at requirements for interdomain routing, and are interested to know what you use it for. For instance, do you use interdomain routing to select transit carriers for some traffic in preference to other carriers. Are there policies that you would like to be able to implement that you are unable to because of limitations in the available protocols? How much would you be willing to slow down your forwarding rates in order to have the capability? Please send me your answers and I'll summarize. --Neal

1 0

PGP authentication for the RADB
by Brian Renaud 07 Sep '95

07 Sep '95

The RADB now supports authentication using PGP-based digital signatures. If you want to use this feature, there are three things you must do: * Register your public key with the RA. * Modify your maintainer object to reflect your use of digital signatures * Sign (via PGP) your RADB transactions. 1. Registering your public key with the RA. You must send your public key to the RA for inclusion onto our PGP keyring. Use the "pgp -kxa" command to generate a copy of your public key suitable for mailing, then mail the resultant file to db-admin(a)ra.net. For example: % pgp -kxa smith(a)ra.net pubkey ... % mail -s 'please register my public key' db-admin(a)ra.net < pubkey.asc You may use one of two methods of verification: * Fax a copy of a photographic identification (passport or drivers license) to: RADB public key verification +1 313 747 3185 please write your PGP fingerprint and email address on the fax * Attend an RA sponsored key signing session at NANOG or IETF. You will need to bring a copy of your public key with a PGP fingerprint and photo identification. (This will be verification via the identification you bring, rather than having two other people agree that you are who you say you are.) We will be holding a key signing at NANOG on Monday, September 11 at 5:00. If that time is not convenient, you can also accost RA team members at random and present them with with the appropriate information. 2. Modifications to the maintainer object There is a new authentication option for the maintainer object. The syntax for it is: auth: PGP-FROM {PGP User Id} For example, auth: PGP-FROM John Smith <smith(a)ra.net> 3. Signing your RADB transactions You will need to PGP-sign each transaction you send to auto-dbm(a)ra.net. Use the "pgp -sta" command to do this. For example: % pgp -sta -u smith(a)ra.net routes ... % mail -s 'route updates' auto-dbm(a)ra.net < routes.asc

1 0

Re: Pittsburgh directions
by nrm1838＠rserver3.dsac.dla.mil 07 Sep '95

07 Sep '95

In reply to the mail from <nanog(a)merit.edu>... ------------------------------------------------------------------------------- Hello Pam! I am a late resistrant for the NANOG meeting next week. The Holiday Inn is full :(. Any ideas about another hotel that might be close to the meeting. Thanks, Jim ------------------------------------------------------------------------------- nrm1838 sends (Jim Cassell)...

1 0

Agenda for next week
by Susan R. Harris 06 Sep '95

06 Sep '95

North American Network Operators Group (NANOG) Agenda Monday, September 11 Time Topic Presenter(s) ---- ----- ------------ 9:00 a.m. Welcome, Introductions, Bill Norton Future Meetings 9:15 a.m. RA Project Update Elise Gerich 10:00 a.m. New Routing Tools for the Craig Labovitz Internet 10:30 a.m. Break 10:45 a.m. Updates from the Interconnection Points AADS NAP Mark Knopper PacBell NAP Current status Warren Williams ATM Testing Kent England Washington, D.C. NAP Steve Feldman MAE-West Steve Feldman 12:30-1:30 p.m. Lunch 1:30 p.m. Top-Level Domains: the Mark Kosters and InterNIC Solution Dave Graves 2:00 p.m. Top-Level Domains: Milo Medin, Moderator Community Views and Discussion 2:45 p.m. Nimrod Routing: How Can Michael Patton We Meet Your Needs? 3:15 p.m. Break 3:30 p.m. Experience With Route-Flap Sean Doran Dampening 4:00 p.m. Auto-configuration in IPv6 Alison Mankin Tuesday, September 12 9:00 a.m. Proxy Aggregation: Stan Barber, Moderator Community Views and Discussion 10:00 a.m. CA*net ATM Backbone Guy Middleton Transition 10:30 a.m. Break 10:45 a.m. RADIUS: Distributed John Vollbrecht Authentication for MichNet 11:15 a.m. GateD Consortium Martyne Hallgren 11:30 a.m. Classless DNS Delegations in Daniel Karrenberg IN-ADDR.ARPA 12:00 p.m. Adjourn

1 0

NEW Tool Announcement
by labovit＠MERIT.EDU 06 Sep '95

06 Sep '95

MRT-1.0-ALPHA README Last updated 9/6/95 The first official alpha release of the Multi-threaded Routing Toolkit (MRT) tools is now available: (SunOS) ftp://ftp.merit.net/net-research/mrt/mrt-1.0.alpha.sunos.tar.gz (Solaris) ftp://ftp.merit.net/net-research/mrt/mrt-1.0.alpha.solaris.tar.gz For more information on the MRT toolkit, see: http://www.merit.net/net-research/mrt/mrt.html MRT is an easy-to-use, extensible platform for developing and debugging routing protocols and routing code. MRT's Unix programs and C-library routines separate routing into its key component pieces of routing protocol, routing engine, and routing policy services. The MRT tools greatly improve the ability of network providers to monitor, troubleshoot, and analyze networks, and provide protocol developers or researchers with a useful vehicle for quick prototyping and experimentation. You can use MRT tools to: --Capture a BGP peering session and monitor it in real time --Input a binary file to the routing stream to replicate a problem or create any desired routing condition --Use a real-time dump to perform statistical analyses, prototype a new protocol, or test a routing engine --Record and replay sequences of events, in order to reproduce scenarios such as routing failures --Collect routing statistics and analyze route flapping The Alpha release contains the following tools: * SBGP A simple BGP4 speaker and listener * Route_BtoA Convert binary MRT messages to ASCII * Route_AtoB Convert ASCII descriptions of MRT messages to binary * CiscoBGP Check cisco routing tables against IRR * BGPCheck Check BGP updates against IRR * Route_Flap Perform route flap analysis and statistics collection 1.0 ALPHA RELEASE NOTES ----------------------- 1. This is an ALPHA release. The code is still a bit buggy and unstable. Depending on the number of bugs that turn up, we hope to make a BETA release available in late October. 2. MRT was designed to run on native kernel-level multi-threaded machines. If you run MRT on older machines, you will not achieve nearly the same level of performance. In addition, some MRT features will not work. 3. The complete set of MRT programming libraries and documentation will be released with MRT-1.0 BETA in late October. 4. MRS, XMRS, SRIp, PortMapper and MSGServer are included in this release as undocumented, unsupported prototypes.

1 0

CERT Advisory CA-95:10 - ghostscript Vulnerability
by CERT Advisory 31 Aug '95

31 Aug '95

============================================================================= CA-95:10 CERT Advisory August 31, 1995 ghostscript Vulnerability ----------------------------------------------------------------------------- A large portion of the technical content of this advisory was provided by the DFN-CERT and NASIRC response teams, and is used with their permission. There is a vulnerability in older versions of ghostscript (gs) that enables users to execute commands and thus modify files. This problem involves the -dSAFER option and is present in all versions of ghostscript from 2.6 through 3.22 beta. We recommend that you apply the solution in Section III below to fix the -dSAFER PostScript code or install the latest version of ghostscript (version 3.33). In both cases, we urge you to make -dSAFER the default mode for all versions of ghostscript starting with version 2.6. As we receive additional information relating to this advisory, we will place it in ftp://info.cert.org/pub/cert_advisories/CA-95:10.README We encourage you to check our README files regularly for updates on advisories that relate to your site. ----------------------------------------------------------------------------- I. Background The PostScript language, which was designed for the expression of graphical data, is widely used for transferring images and preformatted text across the Internet. The language includes primitives for file operations, which were intended to be useful in the expression of images. Unfortunately the operations can be abused by people intentionally embedding commands within an otherwise harmless image so that when displaying that image the PostScript viewer may perform malicious file creations or deletions. This is a potentially serious problem because many images transferred on the World Wide Web are sent in PostScript. For example, a malicious person could install a booby-trapped image on a web-page, buried among useful or interesting data. The viewer "ghostscript," a PostScript interpreter, recognizes the command-line option: "-dSAFER". This option is intended to disable the file operations and the %pipe PostScript operator that could be abused to do damage. This option is intended to protect you from this type of sabotage when viewing images from untrusted sources. II. Problem Description Problems exist with the ghostscript program, which supports the kind of commands discussed above. Older versions of ghostscript do not completely disable the pipe operator that can be used execute commands that can modify files. Therefore the option -dSAFER does not provide full protection. This problem is present in all versions of ghostscript between 2.6 (when the %pipe operator was added) and 3.22beta (when a fix was made). III. Impact Attackers who have inserted malicious code into a PostScript file can cause commands to be executed and files to be modified on any system where that PostScript file is viewed with ghostscript. IV. Solutions We recommend either fixing the -dSAFER PostScript code or installing version 3.33 of ghostscript (see Sections IV.A and IV.B). In addition, we urge you to enable the -dSAFER option as the default (see Section IV.C). A. Fixing the -dSAFER PostScript code The following fix is in the form of "diff" output, which is suitable for use with the GNU patch program. This patch brings the code into conformance with the version of gs_init.ps distributed with the latest version of ghostscript (3.33) and can be applied to the GNU versions 2.6, 2.6.1, and 2.6.2. The file to be patched is in the ghostscript library. As an example, gs_init.ps could be installed in: /usr/local/lib/ghostscript/gs_init.ps Here is the patch: --------------------------------cut here-------------------------------------- *** gs_init.ps.orig Fri Aug 25 10:42:51 1995 --- gs_init.ps Fri Aug 25 11:16:24 1995 *************** *** 302,308 **** % If we want a "safer" system, disable some obvious ways to cause havoc. SAFER not { (%END SAFER) .skipeof } if /file ! { dup (r) eq { file } { /invalidfileaccess signalerror } ifelse --- 302,308 ---- % If we want a "safer" system, disable some obvious ways to cause havoc. SAFER not { (%END SAFER) .skipeof } if /file ! { dup (r) eq 2 index (%pipe*) .stringmatch not and { file } { /invalidfileaccess signalerror } ifelse --------------------------------cut here-------------------------------------- The key is to change the line that says: { dup (r) eq to one that says: { dup (r) eq 2 index (%pipe*) .stringmatch not and Here are the relevant lines in the gs_init.ps file for version 2.6.2 of ghostscript before the patch: 302 % If we want a "safer" system, disable some obvious ways to cause havoc. 303 SAFER not { (%END SAFER) .skipeof } if 304 /file 305 { dup (r) eq 306 { file } 307 { /invalidfileaccess signalerror } 308 ifelse 309 } bind odef 310 /renamefile { /invalidfileaccess signalerror } odef 311 /deletefile { /invalidfileaccess signalerror } odef 312 %END SAFER Here are the same lines after the patch has been applied: 302 % If we want a "safer" system, disable some obvious ways to cause havoc. 303 SAFER not { (%END SAFER) .skipeof } if 304 /file 305 { dup (r) eq 2 index (%pipe*) .stringmatch not and 306 { file } 307 { /invalidfileaccess signalerror } 308 ifelse 309 } bind odef 310 /renamefile { /invalidfileaccess signalerror } odef 311 /deletefile { /invalidfileaccess signalerror } odef 312 %END SAFER B. Installing version 3.33 You may wish to install Aladdin Ghostscript version 3.33. The latest version of ghostscript is version 3.33 and is available at the locations noted below. This version of ghostscript is provided by Aladdin Enterprises and is subject to their licensing agreements. Please read the "Aladdin Ghostscript Free Public License" (included in the source code distribution) which differs from the "GNU Public License." Please note that this version is not the GNU version. The latest GNU version, which is version 2.6.2, does not fix this problem. ftp://ftp.cs.wisc.edu/pub/ghost/aladdin/ghostscript-3.33.tar.gz MD5=28b78ab052dff21639c4b97051323e49 ftp://ftp.cs.wisc.edu/pub/ghost/aladdin/ghostscript-3.33jpeg.tar.gz MD5=b7dd9064dd57db8fccc306f5e4528d99 Optionally, you may need the font files for this release. They are available at these locations: ftp://ftp.cs.wisc.edu/pub/aladdin/ghostscript-fonts-std-3.0.tar.gz MD5=fe7377bb155496828a328624ae80149d ftp://ftp.cs.wisc.edu/pub/aladdin/ghostscript-fonts-other-3.0.tar.gz MD5=afe46faf7fde6518ae004a7e8d9a4af4 C. Making -dSAFER the default To make -dSAFER the default mode for ghostscript for all versions of ghostscript starting with version 2.6, the file gs_init.ps must again be changed. The PostScript commands which check the actual interpreted command are collected in one single if statement in the gs_init.ps file. By commenting out the begin and end lines of this if statement, the check is always applied meaning that the -dSAFER option is always enabled. NOTE: If you make this change, all file and %pipe operations are disabled and cannot be re-enabled. The lines which must be changed are: 303 SAFER not { (%END SAFER) .skipeof } if and 312 %END SAFER These two lines should be commented out and made to look like this: 303 % SAFER not { (%END SAFER) .skipeof } if and 312 % %END SAFER If you are using ghostscript 2.6.2, the code will look like the following when both patches noted above are installed: 302 % If we want a "safer" system, disable some obvious ways to cause havoc. 303 % SAFER not { (%END SAFER) .skipeof } if 304 /file 305 { dup (r) eq 2 index (%pipe*) .stringmatch not and 306 { file } 307 { /invalidfileaccess signalerror } 308 ifelse 309 } bind odef 310 /renamefile { /invalidfileaccess signalerror } odef 311 /deletefile { /invalidfileaccess signalerror } odef 312 % %END SAFER --------------------------------------------------------------------------- The CERT Coordination Center staff thanks the DFN-CERT and NASIRC response teams for providing a large portion of the technical content of this advisory, and we thank Wolfgang Ley for his assistance. --------------------------------------------------------------------------- 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 CERT publications, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from info.cert.org. This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and the CERT Coordination Center, DFN-CERT, and NASIRC are acknowledged. CERT is a service mark of Carnegie Mellon University.

1 0

Re: NANOG Meeting
by prue＠ISI.EDU 29 Aug '95

29 Aug '95

Hi, I will be attending the NANOG meeting in Pittsburg. Walt Prue Los Nettos USC/ISI

1 0