From ipsec-request@ans.net Fri Jul 1 17:05:42 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA02514 (5.65c/IDA-1.4.4 for ); Fri, 1 Jul 1994 17:05:42 -0400 Received: by interlock.ans.net id AA22007 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Fri, 1 Jul 1994 16:47:53 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Fri, 1 Jul 1994 16:47:53 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 1 Jul 1994 16:47:53 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 1 Jul 1994 16:47:53 -0400 Date: Fri, 01 Jul 94 11:56:47 From: "Housley, Russ" Encoding: 545 Text Message-Id: <9406017730.AA773089007@uu0892.spyrus.com> To: ipsec@ans.net Subject: IEEE 802.10c/D5 All: The next draft of the SILS Key management document is available for anonymous ftp from atlas.arc.nasa.gov in the /sils directory. The file name is silskm5.ps. I suggest that we conside the SILS work as a good starting point for the Internet Key management work. I suspect that the most diputed part will be the use of the OSI Generic Upper Layer Security (GULS) stuff. However, I am convinced that GULS is compatible with the Internet since warwick Ford tells me that BNR implemented GULS directly on TCP. Russ From ipsec-request@ans.net Tue Jul 5 08:59:29 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13474 (5.65c/IDA-1.4.4 for ); Tue, 5 Jul 1994 04:34:09 -0400 Received: by interlock.ans.net id AA21190 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 5 Jul 1994 04:01:33 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 5 Jul 1994 04:01:33 -0400 From: Ran Atkinson Message-Id: <9407050359.ZM12431@sundance.itd.nrl.navy.mil> Date: Tue, 5 Jul 1994 03:59:29 -0500 Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 04apr94) To: ipsec@ans.net Subject: SAID size Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@sundance.itd.nrl.navy.mil (Apologies if this is no longer current; I've been away and am plowing through a very large number old email messages.) I'd really like to see at least a 32-bit SAID. Even with address-oriented SAIDs, I need a large SAID space. Some of my systems have a VERY large number of simultaneous or near-simultaneous connections. Also, a 32-bit aligned SAID has performance advantages on most systems. In general, I'd really really like to see at least 32-bit alignment and preferably 64-bit alignment of all possible fields. Early experiments we've done indicate that (at least on some of our platforms) protocol processing is the performance bottleneck, not the bit scambling hardware. I consider it important to be able to perform IP/ATM processing at line rates (at least OC-3c or 155 Mbps, with a strong preference for higher performance). Thanks, Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Tue Jul 5 09:38:47 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13444 (5.65c/IDA-1.4.4 for ); Tue, 5 Jul 1994 04:52:37 -0400 Received: by interlock.ans.net id AA04839 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 5 Jul 1994 04:42:43 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 5 Jul 1994 04:42:43 -0400 From: Ran Atkinson Message-Id: <9407050438.ZM12568@sundance.itd.nrl.navy.mil> Date: Tue, 5 Jul 1994 04:38:47 -0500 In-Reply-To: Phil Karn "Re: Re[2]: Granularity of authentication in swIPe" (Jun 24, 17:20) References: <199406250020.RAA26333@servo.qualcomm.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 04apr94) To: Phil Karn Subject: Re: Re[2]: Granularity of authentication in swIPe Cc: ipsec@ans.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@sundance.itd.nrl.navy.mil On Jun 24, 17:20, Phil Karn wrote: >Also, I think that the SAID structure must support IP broadcast and IP >multicast. For this reason, I want a larger SAID (say, 32 bits for >compatabiltiy with the IEEE 802.10 Secure Data Exchange and Key Management >Protocol). Management of broadcast and multicast keys within the Internet >will require a large pool of SAIDs. % As I think Perry already said, SAIDs logically include the IP % addresses. They're just like TCP sockets - each connection is % uniquely identified by the concatentation of the IP addresses and port % numbers, which means you need many fewer port numbers than you % otherwise would if everything was identified solely by port number. I need to be able to use IPSP on my MLS workstations (e.g. Sun). I also have other systems which need to have many concurrent connections. 32 bits is a practical minimum. The TCP ports and IP addresses are already accounted for when I say this. % As an aside I just don't see any easy way to support multicast in IPSP % that doesn't require a public key operation for each packet. Much of % the utility of IPSP comes from setting up a session key using a fairly % expensive key exchange protocol that is run only once for some fairly % large number of packets. But I don't see any easy way to do this for % multicast. % % I can see putting in hooks for multicast, but it's hard to see how % they could be really useful given the current costs of even a public % RSA operation. If you mean that it is hard to do scalable multicast key management using any published key mgmt protocol, then I agree. There are some promising developments recently (e.g. the work by Reiter) but it remains very much an area for research. However, I can do manual key distribution and/or reuse existing published key mgmt techniques for small multicast groups. I plan to do this. Also, one can use hardware to make various algorithms execute more quickly. While we need to take software implementation considerations into account, we must also recall that there will also be hardware implementations and should avoid undue constraints on them. IMHO, IPSP must not preclude support for multicasting since multicasting is a fundamental service in the community. I hope we're agreeing here, but am not sure. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Tue Jul 5 09:57:42 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07724 (5.65c/IDA-1.4.4 for ); Tue, 5 Jul 1994 05:07:03 -0400 Received: by interlock.ans.net id AA25903 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 5 Jul 1994 04:57:55 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 5 Jul 1994 04:57:55 -0400 From: Ran Atkinson Message-Id: <9407050457.ZM12699@sundance.itd.nrl.navy.mil> Date: Tue, 5 Jul 1994 04:57:42 -0500 In-Reply-To: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) "IPSEC Toronto Meeting" (Jun 29, 19:07) References: <00112.2855761894.21458@poncho.phx.sectel.mot.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 04apr94) To: Paul Lambert , ip security mailing list Subject: Re: IPSEC Toronto Meeting Cc: jis@mit.edu Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@sundance.itd.nrl.navy.mil Friday morning is a horrible time for any meeting. Please try to reschedule for any other time. Most IETF attendees have to leave early Friday morning in order to travel back whence they came. Key mgmt is too important a question to be on a Friday morning when many folks will not be able to attend. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Tue Jul 5 14:19:04 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06957 (5.65c/IDA-1.4.4 for ); Tue, 5 Jul 1994 09:31:46 -0400 Received: by interlock.ans.net id AA13639 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 5 Jul 1994 09:20:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 5 Jul 1994 09:20:28 -0400 Return-Path: shirey@mitre.org Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 5 Jul 1994 09:20:28 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 5 Jul 1994 09:20:28 -0400 Message-Id: <9407051319.AA27469@smiley.mitre.org.sit> X-Sender: shirey@smiley.mitre.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Jul 1994 09:19:04 -0500 To: atkinson@itd.nrl.navy.mil, Paul Lambert , ip security mailing list From: shirey@mitre.org (Robert W. Shirey) Subject: Re: IPSEC Toronto Meeting Cc: jis@mit.edu At 4:57 AM 7/5/94 -0500, Ran Atkinson wrote: >Friday morning is a horrible time for any meeting. Please try to >reschedule for any other time. Most IETF attendees have to leave >early Friday morning in order to travel back whence they came. Paul, I am among those who have conflicts. People have committed to squeezing in a non-IETF technical security meeting on Friday, under the assumption that Friday was to have only the usual morning general-interest plenaries. -Rob- From ipsec-request@ans.net Tue Jul 5 14:32:47 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06953 (5.65c/IDA-1.4.4 for ); Tue, 5 Jul 1994 10:45:37 -0400 Received: by interlock.ans.net id AA23114 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 5 Jul 1994 10:33:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 5 Jul 1994 10:33:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 5 Jul 1994 10:33:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 5 Jul 1994 10:33:08 -0400 Message-Id: <9407051432.AA29618@tis.com> Reply-To: James M Galvin To: shirey@mitre.org (Robert W. Shirey) Cc: ip security mailing list Subject: Re: IPSEC Toronto Meeting In-Reply-To: 's message of Tue, 05 Jul 1994 09:19:04 CDT. <9407051319.AA27469@smiley.mitre.org.sit> Date: Tue, 05 Jul 1994 10:32:47 -0400 From: James M Galvin I hate to burden this list with bureaucracy, but: At 4:57 AM 7/5/94 -0500, Ran Atkinson wrote: >Friday morning is a horrible time for any meeting. Please try to >reschedule for any other time. Most IETF attendees have to leave >early Friday morning in order to travel back whence they came. I am among those who have conflicts. People have committed to squeezing in a non-IETF technical security meeting on Friday, under the assumption that Friday was to have only the usual morning general-interest plenaries. The last time the IETF had general interest plenaries on Friday was July of 1992, in Boston. Since then working groups have met on friday, except for Amsterdam (July 1993) when there were technical presentations. Jim From ipsec-request@ans.net Tue Jul 5 03:18:53 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05044 (5.65c/IDA-1.4.4 for ); Tue, 5 Jul 1994 13:34:29 -0400 Received: by interlock.ans.net id AA35780 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 5 Jul 1994 13:23:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 5 Jul 1994 13:23:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 5 Jul 1994 13:23:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 5 Jul 1994 13:23:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 5 Jul 1994 13:23:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 5 Jul 1994 13:23:23 -0400 Message-Id: <00112.2856248708.22148@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list) Cc: atkinson#064#itd.nrl.navy.mil%INTERNET@email.mot.com (atkinson 064 itd.nrl.navy.mil) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Tue, 5 Jul 1994 10:18:53 MST Subject: Re: >IPSEC Toronto Meeting Reply to: RE>>IPSEC Toronto Meeting I will contact Megan and attempt to move the meeting. Paul -------------------------------------- Date: 7/5/94 2:22 AM To: Paul Lambert From: atkinson 064 itd.nrl.navy.mil Friday morning is a horrible time for any meeting. Please try to reschedule for any other time. Most IETF attendees have to leave early Friday morning in order to travel back whence they came. Key mgmt is too important a question to be on a Friday morning when many folks will not be able to attend. Ran atkinson@itd.nrl.navy.mil From ipsec-request@ans.net Wed Jul 6 11:21:01 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA06303 (5.65c/IDA-1.4.4 for ); Wed, 6 Jul 1994 22:32:13 -0400 Received: by interlock.ans.net id AA22507 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Wed, 6 Jul 1994 22:19:20 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Wed, 6 Jul 1994 22:19:20 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Wed, 6 Jul 1994 22:19:20 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Wed, 6 Jul 1994 22:19:20 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 6 Jul 1994 22:19:20 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 6 Jul 1994 22:19:20 -0400 Message-Id: <00112.2856364329.22582@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Wed, 6 Jul 1994 18:21:01 MST Subject: IPSEC Meeting Date Change IPSEC Meeting Date Change Please note the change below in the meeting dates for ipsec. The Friday key management meeting has been moved to Thursday. DRAFT Agenda of the Thirtieth IETF - as of 6/24/94 (July 25-29, 1994) WEDNESDAY, July 27, 1994 1330-1530 Afternoon Sessions I SEC IP Security WG - Network Layer Encryption (ipsec) (Paul Lambert/Motorola and Jim Zmuda/Spyrus) THURSDAY, July 28, 1994 0930-1200 Morning Session SEC IP Security WG - Key Management (Paul Lambert/Motorola and Jim Zmuda/Spyrus) We still have a couple of slots open for presentations ... Paul From ipsec-request@ans.net Tue Jul 12 05:47:28 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13377 (5.65c/IDA-1.4.4 for ); Tue, 12 Jul 1994 05:47:28 -0400 Received: by interlock.ans.net id AA38975 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 12 Jul 1994 05:28:58 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 12 Jul 1994 05:28:58 -0400 Message-Id: <199407120928.AA38971@interlock.ans.net> Date: 12 Jul 94 10:26:00 WET From: "Tim Dean" Subject: Architectural relationship between KMP and IPSP To: "ipsec" Has much thought been given to the architectural relationship between the IPSP and key management protocol(s) (KMPs)? If it has, then could someone summarize the discussions for my benefit, or point me in the right direction. Many Thanks! Alternatively, here is my two penny'worth on some of the issues: Clearly, the IPSP/KMP relationship has some important consequences for the development of an IPSP. For example: Option 1: If the KMP runs as an `application' over TCP, something special must happen when KMP packets hit the IPSP layer (it can't be treated like a normal application because when the first packet comes down, IPSP would discover no security association exists causing a recursive call back to the KMP: hence deadlock). Either: - KMP packets pass transparently through or bypass the security layer, and so KMP must provide all its own security services (peer entity authentication, replay detection etc) or: - the KMP could use a special pre-placed security association. But this would mean that pairwise SAs would need to be put in place for all systems that may wish to communicate, which sounds unworkable. Whichever of the above is chosen the effect on the IPSP is that it has to detect KMP packets in some way and treat them differently from other applications. How would this be achieved? Altenratively, (the most flexible solution?) IPSP could offer some general method of signalling security services to and from applications. Option 2: The KMP doesn't run over the normal TCP stack, but sits `by the side' of IPSP inside the network layer. This means that it must implement its own retransmission and cope with duplicate messages. This approach has the minimum impact on IPSP, but means a new protocol number must be allocated to the KMP on the `black' network. Option 3: The KMP sits above IPSP, but not running over the normal TCP stack. In this case IPSP could spot the KMP protocol number and do something special with it such as passing it straight through unchanged. If these issues have not been fully aired before, is there scope at the forthcoming meeting to discuss some of them? Which session do they fall into - KM or IPSP? Tim Dean Rm L110, DRA-Malvern Open Distributed Systems St Andrew's Road Software Engineering and CIS Technology Dept Malvern Defence Research Agency Worcestershire Tel: +44-684-894239 Fax: +44-684-896113 E-mail: Dean@hydra.dra.hmg.gb From ipsec-request@ans.net Tue Jul 12 16:39:01 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07646 (5.65c/IDA-1.4.4 for ); Tue, 12 Jul 1994 12:52:20 -0400 Received: by interlock.ans.net id AA36190 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 12 Jul 1994 12:39:14 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 12 Jul 1994 12:39:14 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 12 Jul 1994 12:39:14 -0400 Date: Tue, 12 Jul 1994 09:39:01 -0700 From: Phil Karn Message-Id: <199407121639.JAA10021@servo.qualcomm.com> To: DEAN@hydra.dra.hmg.gb Cc: ipsec@ans.net In-Reply-To: <199407120928.AA38971@interlock.ans.net> (DEAN@hydra.dra.hmg.gb) Subject: Re: Architectural relationship between KMP and IPSP Tim, I've given some thought to this problem (since I'm trying to implement something) and I think the most general solution is to let the application decide what security it wants from IPSP -- if any. That's the hook for the key management protocol; it would turn off IPSP level protections in favor of its own. Another (somewhat related) problem is puncturing firewalls, one of my original motivations for IPSP. It would probably be easiest if the key management protocol would share the same IP protocol number as IPSP itself, probably by using a special reserved SAID. That would make it easy to configure a firewall to allow all IPSP-related communications to come in. Phil From ipsec-request@ans.net Tue Jul 19 08:58:46 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA07746 (5.65c/IDA-1.4.4 for ); Tue, 19 Jul 1994 13:24:32 -0400 Received: by interlock.ans.net id AA47588 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 19 Jul 1994 12:59:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 19 Jul 1994 12:59:36 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 19 Jul 1994 12:59:36 -0400 Date: Tue, 19 Jul 94 12:58:46 EDT From: Robert Glenn Message-Id: <9407191658.AA13918@osi.ncsl.nist.gov> To: ipsec@ans.net Subject: More swIPe Comments...Better late than never The best feature of swIPe that I like the most is its simplistic approach. I have been told of and have seen simple security protocols end up in nightmares of complexity once everyone has had there say and added security features to protect against any/all possible attacks. Having said that, the following are not presented in any implicit order. 1. There seems to be possible redundancy between the Packet type and the Policy Identifier. What is gained by having the Packet type contained in the header as long as this information can be conveyed by the Policy ID? 2. I am still unconvinced that the benefits gained by adding a sequence number to a connectionless protocol out-weigh the costs attributed by the added complexity. I'll decline to argue further on this point though until I've actually tried to implement it. 3. In the definition of the Packet sequence number field it is stated that this field "may also be used for synchronization by a stream cipher". Later in the Draft the text describes that the sequence number is copied to the packet; Authentication is applied from the second 1/2 of the swIPe header to the end of the data, Encryption is applied to the same. I assume that this isn't quite right, because you cannot encrypt the sequence number field and still use it for synchronization. 4. The statement "The algorithm may require padding, which is appended to the packet after encryption has been performed." is slightly confusing. There is some implication here that the Pad field is not encrypted. 5. It has been pointed out to me that for reasons of efficiency, it may be optimal to have the Authenticator at the end of the packet. I am not convinced of this, but I thought I would mention it. 6. Since efficiency (both # bytes on the wire and speed of processing) is a key issue with some folks, it seems to me that including an extra IP header in every single packet (requardless of whether swIPe is running End-to-End or between routers) is inefficient. The extra IP header is only needed when using swIPe with a router (ie., Host to Router or Router to Router). In Host mode you could exclude the internal header and only have to process the packet through IP once. It is not too difficult to use the Policy identifier (or Packet type if 1. is ignored) to implement this. Explaining this is probably more difficult than implementing it. 7. A lack of some type of Version number in the packet header is painful at best. It has been argued that this information could be conveyed in the Policy ID (SAID). This doesn't work well. If the Policy ID field were to become larger in a future version, performing a Policy lookup would be difficult if you didn't know what version(s) were supported/implemented. 8. While no Key Management is specifically defined by swIPe, it is useful to identify those Key Management attributes that directly relate to swIPe's operation (eg., algorithms, keys, authenticator length, etc.). 9. The comments on traffic analysis only relate to Router mode operation of swIPe. 10. What value is obtained by encapsulating but not providing authentication or encryption (ie., packet type 0). Just my two cents.... Rob G. glenn@osi.ncsl.nist.gov From ipsec-request@ans.net Thu Jul 21 11:40:03 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18828 (5.65c/IDA-1.4.4 for ); Thu, 21 Jul 1994 16:02:06 -0400 Received: by interlock.ans.net id AA53712 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 21 Jul 1994 15:41:06 -0400 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 21 Jul 1994 15:41:06 -0400 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 21 Jul 1994 15:41:06 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 21 Jul 1994 15:41:06 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 21 Jul 1994 15:41:06 -0400 Date: Thu, 21 Jul 94 15:40:03 EDT From: perry@imsi.com (Perry E. Metzger) Message-Id: <9407211940.AA07982@webster.imsi.com> Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 21 Jul 1994 15:41:06 -0400 To: ipsec@ans.net Subject: swIPe mailing list Reply-To: perry@imsi.com X-Reposting-Policy: redistribute only with permission A mailing list for swIPe hackers has been started -- send mail to swipe-request@cs.columbia.edu to be added. (The list is naturally swipe@cs.columbia.edu). If you've been frustrated at not being able to get much done with swIPe or if you are attempting a port or just want to discuss the swIPe proposal per se, this is the place to do it. Perry From ipsec-request@ans.net Thu Jul 28 18:03:06 1994 Received: from interlock.ans.net by nis.ans.net with SMTP id AA04864 (5.65c/IDA-1.4.4 for ); Thu, 28 Jul 1994 14:15:45 -0400 Received: by interlock.ans.net id AA04194 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Thu, 28 Jul 1994 13:56:13 -0400 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 28 Jul 1994 13:56:13 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 28 Jul 1994 13:56:13 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 28 Jul 1994 13:56:13 -0400 From: hughes@hughes.network.com (James P. Hughes) Message-Id: <9407281303.ZM7503@hughes.network.com> Date: Thu, 28 Jul 1994 13:03:06 -0500 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: ipsec@ans.net Subject: Contribution procedure to IPSEC archive. Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Files to be placed in the IPSEC repository can be postscript, text and even code. The procedure to get these files put into available directories are as follows. ftp the file(s) to Ftp.Network.Com and place the files in the IETF/IPSEC/incoming directory. This directory is a blind drop, you (and others) will not be able to see these files. After putting the files, please send email to me (hughes@network.com) stating: Which files you want to move, to where and if any renames. A text that you want to be placed in the announcement. (After the files are moved, the announcement will be forwarded to the ipsec reflector.) Normal postscript is fine. If you have any questions about the "normallity" of your postscript files, ask. I can print the file on several printers to check before announcement. jim -- jim