From Paul_Lambert@poncho.phx.sectel.mot.com Thu Jul 1 02:57:43 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13757 (5.65c/IDA-1.4.4 for ); Thu, 1 Jul 1993 13:08:32 -0400 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA14581 (InterLock SMTP Gateway 1.1 for ); Thu, 1 Jul 1993 12:52:36 -0400 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.14 for ) id AA16147; Thu, 1 Jul 1993 11:57:34 -0500 Received: from phx.sectel.mot.com ([192.94.147.2]) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.14 for ) id AA24148; Thu, 1 Jul 1993 11:57:31 -0500 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA22743; Thu, 1 Jul 93 09:56:51 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA39718; Thu, 1 Jul 1993 10:00:05 MST Message-Id: <00112.2824365605.39718@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: Thu, 1 Jul 1993 9:57:43 MST Subject: IPSEC Agenda IPSEC Agenda There will be a IP Security (IPSEC) WG Meeting on Tuesday 13 July at the 27th IETF (9:00 to 12:00 noon) in Amsterdam. This will be the second meeting of IPSEC as a Working Group. Draft Agenda for 2nd IPSEC Working Group Meeting - Tuesday July 13, 1993 9:00 Introduction o Review and Approve Agenda o Minutes of March Ohio Meeting 9:05 Review of Charter and Schedule 9:15 Liaisons o ISO/ANSI (NLSP) o IPtng o IEEE 802.10 o others 9:30 Review of Initial Experimental Implementations o swIPe, SP3, NLSP, and Convergence Protocol 9:45 Review of Preliminary IPSP Draft o Features and Requirements o Clear Header Format - SAID length and conventions - other fields ? o Security Transformations - DES, Triple DES? - Intergrity only o Protected Header Format and Processing - how many modes of operation? - host-to-host requirements vs. subnet-to-subnet o Labels o Peek-Through o Relationship to IP clients - TCP - UDP - ARP, ICMP - IPSP as client of IPSP o Host-to-Subnet and Subnet-to-Subnet Considerations - Red Side Fragmentation - Black Side Fragmentation o Multicast and Conferencing o Solicit Writing Assignments 10:20 Summarize IPSP Recommendations 11:00 Key Management o Basic Assumptions (from previous meetings and discussions) o Background and References o Requirements, Issues, Considerations - Public Key Based Key Exchange - Negotiation of Key Exchange - Negotiation of Security Attributes for IPSP - Representation of Attributes - Multicast and Conference Control - Key Escrow (?) - others o Solicit Writing Assignments 11:50 Summary o Review Action Items 12:00 Close From ahoover@ans.net Thu Jul 1 23:07:58 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13593 (5.65c/IDA-1.4.4 for ); Thu, 1 Jul 1993 16:17:09 -0400 Received: by interlock.ans.net id AA12455 (InterLock SMTP Gateway 1.1 for ipsec@ans.net); Thu, 1 Jul 1993 16:03:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 1 Jul 1993 16:03:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 1 Jul 1993 16:03:07 -0400 Date: Thu, 1 Jul 1993 16:07:58 -0700 From: Alton Hoover Message-Id: <199307012307.AA01404@hoovermac.ans.net> To: ipsec@ans.net Subject: IPSEC Minutes Gentlepeople: I must apologize for the delay in posting these minutes. A copy of these were sent to Steve Crocker (SAG) and Jim Galvin immediately after the Ohio meeting. They were previously posted via email but due to a mailer error (mia culpa) they never reached the IPSEC list. After this was appropriately pointed out, I attempted to recover/reconstruct the notes from my crashed AUX system. Its been too long and I apologize for any/all inconvenience. These are the summary meeting notes. I will be following with details and posted documents. Sincerely, Al Hoover IP Security Working Group (IPSEC) Meeting 9:30 AM 3-31-93 Chaired by: Al Hoover, ANS CO+RE Systems, Inc. Paul Lambert, Motorola, Inc. Agenda: Introduction Review and approval of agenda Minutes of Washington D.C. posted to ipsec list IPSEC Charter has been submitted with final revisions and is being shepherded by the Area Director through the approval process. Review of IPSEC Charter and Task Schedule Identification of Working Group Liaisons and Volunteers SIP - Ran Atkinson AVT - Stuart Stubblebine MOBILE IP PIP - John Ioannidis CAT - John Linn TUBA - Richard Colella CIPSO - Ron Sharp SC27 - Piers McMahon SC6 - Paul Lambert IEEE 802.10 Paul Lambert - Russ Housley Review of Initial Experimental Implementations John "ji" Ioannidis, Columbia University presented an overview on swIPe. John will provide a postscript version of his slides on the archive server. Jim Zmuda, Hughes Aircraft, Inc presented an overview of NetGuard and the Digital Tandu encryption chip. Andrew Partan, UUNET Technologies, Inc. presented a brief overview of the "LAN Guardian" security offering. Summarize Approach and Recommendations A preliminary list of IPSEC protocol features/requirements was discussed and will be posted to the list for further refinement. Key Management A brief discussion related to key management took place and it was suggest that it be continued on the list. Summary Next Meeting - An IPSEC meeting will be scheduled for the Amsterdam meeting. It was suggested that a VAT conference back to the states be attempted for Amsterdam. If there is a requirement for an interim IPSEC meeting before Amsterdam either a site/date will be selected or a conference call or VAT will be scheduled. Review and closing Attendees: Al Hoover ahoover@ans.net Paul Lambert Paul_Lambert@email.mot.com James Zumda zumda@mls.hac.com John Linn jlinn@mcimail.com Rob Hagens hagens@ans.net Paul Sangster sangster@ans.net Philip Lozowick lozowick@isv.dec.com Ted Tso tytso@mit.edu Richard Colella collella@nist.gov Jeff Schiller jis@mit.edu Steve Lunt lunt@bellcore.com Rich Graveman rfg@ctt@bellcore.com Richard Thomas rjthomas@bnr.ca John Campbell jrcamp@nosc.mil Jim Weatherford weatherf@nosc.mil Rich Bjers rich.bjers@uc.edu Jon Fellows jonf@gdstech.grumman.com Stefan Fassbender stf@casi.net Ran Atkinson atkinson@itd.nrl.navy.mil Steve Crocker crocker@tis.com Jim Barnes barnes@xylogics.com Allyson Showalter allyson@nsipo.nasa.gov Cynthia E. Martin martin@spica.drsa.mil Joe Pagan jrp@afterlife.ncsc.mil Chas DiFatta cd@sei.cmu.edu Ron Sharp rls@neptune.att.com Radia Perlman perlman@dsmail.enet.dec.com Klaus Trugel trugel@gmd.de Wolfgang Schneider wolfgang.schneider@gmd.de Thyen Vu vu@polanisi.disa.mil Rina Nathaniel rina@md.vndi.uunet.com Paul Traina pst@cisco.com Tom Benkart teb@saturn.sys.acc.com Phil Karn karn@qualcomm.com Jisso Geiter geiter@mitre.com Piers McMahon p.v.mcmahon@rea0803.wins.icl.co.uk Dan Hanson hanson@oas2-tic.af.mil Antonio Fernandez afa@thumper.bellcore.com Charles Perkins perk@watson.ibm.com Rich Harris rharris@atc.boeing.com Andrew Partan asp@uunet.uu.net Barbara Fraser byf@cert.org Charlie Kaufman kaufman@zk3.dec.com Dan Frommer dan@jeremy.enet.dec.com David Conrad davidc@iij.ad.jp Kishan L. Dudkikar kishan@icm1.icp.net Marcus j. Ranum mjr@tis.com John Ionnidis ji@cs.columbia.edu Dale S. Johnson dsj@merit.edu Steve Kent kent@bbn.com Mike St.Johns stjohns@darpa.mil Chuck Warlick warlick@theophilus.msfc.nasa.gov Rob Shirey shirey@mitre.org From atkinson@itd.nrl.navy.mil Tue Jul 6 09:13:04 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15240 (5.65c/IDA-1.4.4 for ); Tue, 6 Jul 1993 13:25:13 -0400 Received: from itd.nrl.navy.mil by interlock.ans.net with SMTP id AA16208 (InterLock SMTP Gateway 1.1 for ); Tue, 6 Jul 1993 13:08:08 -0400 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA10797; Tue, 6 Jul 93 13:13:04 EDT Date: Tue, 6 Jul 93 13:13:04 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9307061713.AA10797@itd.nrl.navy.mil> To: ipsec@ans.net, Paul_Lambert@poncho.phx.sectel.mot.com Subject: Re: IPSEC Agenda I have a couple of comments on the agenda... 1) I'm very surprised to hear that there are only "experimental" implementations of SP3. This is simply not true. The US Government currently uses SP3 implementations, which are purchased commercially, to secure some of its networks. SP3 is known to be solid and to work well and be scalable to higher bandwidth networks. It is not experimental at all, but rather is a solid production-quality protocol and has a clear, readable, and sufficiently detailed specification. 2) What is the status of getting the IPSP session onto the MBONE Multicast Conference list for Amsterdam ? A number of us are unable to attend and would like to participate via the MBONE. 3) I don't see any announcement of an IPSP draft being available online via the Internet drafts mechanism. As such, it is inappropriate to discuss any particular IPSP draft or select one at this time. Drafts for the various proposals need to be made fully available using the Internet Drafts mechanism sufficiently before any IETF meeting or any decision so that anyone on the Internet may have time to review and comment on those drafts. As such the 0945 agenda item appears to be inappropriate if it talks about any specific IPSP draft proposal rather than discussing technical features desired in a proposal-neutral manner. I would also suggest that IP labelling is out of the scope of the IPSP working group. The IPSP working group clearly needs to support RFC-1108 which is on the Internet Standards track. Also conference control security is a problem for the working group on internet conferencing not for IPSP. The conference control problem is not necessarily best solved at the IP layer and the IPSP WG should narrow its focus to IP security. 4) I would like to encourage more email list discussions and less reliance on face to face meetings. Decisions reached at IETF physical meetings are not necessarily binding on the whole working group and all subjects should be thoroughly discussed on the email list as well before any conclusions are drawn. One of the big advantages of the IETF process over some less successful processes is this ability to discuss matters via email so that there is more discussion and review of the technical content prior to making any decisions. It will always be the case that some folks can't make a physical meeting (Amsterdam is maybe worse than normal in this respect) and email is a critical part of the IETF process. Ran atkinson@itd.nrl.navy.mil From stubble@ISI.EDU Tue Jul 6 18:43:48 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15806 (5.65c/IDA-1.4.4 for ); Tue, 6 Jul 1993 14:47:52 -0400 Received: from zephyr.isi.edu by interlock.ans.net with SMTP id AA06832 (InterLock SMTP Gateway 1.1 for ); Tue, 6 Jul 1993 14:38:52 -0400 Received: by zephyr.isi.edu (5.65c/5.61+local-13) id ; Tue, 6 Jul 1993 11:43:48 -0700 Date: Tue, 6 Jul 1993 11:43:48 -0700 From: stubble@ISI.EDU (Stuart Stubblebine) Message-Id: <199307061843.AA18896@zephyr.isi.edu> To: ipsec@ans.net Subject: Re: IPSEC Agenda Comments on the agenda... 1. I agree with Ran that conference control is not what needs to be addressed in the IPSEC WG meeting. Instead the -shortened- item of "multicasting" is the requirement/consideration at the network layer for the scalability of secure conferencing. For secure conferencing, the security services of data confidentiality and data origin authentication should scale well for datagrams addressed to large multicast groups. (Furthermore, the time to process the datagrams should be minimal.) 2. I am curious how much interest there is for traffic flow confidentiality as a ip security service. (I would appreciate any feedback on this addressed directly to me or to the group.) --Stuart Stubblebine stubblebine@isi.edu From nmh@thumper.bellcore.com Tue Jul 6 10:58:33 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15863 (5.65c/IDA-1.4.4 for ); Tue, 6 Jul 1993 14:59:27 -0400 Received: from thumper.bellcore.com by interlock.ans.net with SMTP id AA16415 (InterLock SMTP Gateway 1.1 for ); Tue, 6 Jul 1993 14:53:43 -0400 Received: from fall.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ipsec@ans.net; Tue, 6 Jul 93 14:58:36 EDT Received: by fall.bellcore.com (5.0/SMI-SVR4) id AA03601; Tue, 6 Jul 93 14:58:33 EDT Date: Tue, 6 Jul 93 14:58:33 EDT From: nmh@thumper.bellcore.com (Neil Haller) Message-Id: <9307061858.AA03601@fall.bellcore.com> To: stubble@ISI.EDU Subject: Re: IPSEC Agenda Cc: ipsec@ans.net Content-Length: 287 >I am curious how much interest there is for traffic flow confidentiality Traffic flow confidentially is interesting, important, and hard. I would like to see a discussion of ideas, but it shouldn't slow progress on a basic IP security mechanism. Neil Haller nmh@thumper.bellcore.com From pmetzger@lehman.com Tue Jul 6 19:20:24 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA15771 (5.65c/IDA-1.4.4 for ); Tue, 6 Jul 1993 15:26:49 -0400 Received: from Lehman.COM by interlock.ans.net with SMTP id AA15876 (InterLock SMTP Gateway 1.1 for ); Tue, 6 Jul 1993 15:17:06 -0400 Received: from shearson.com ([192.9.140.112]) by lehman.com (4.1/LB 0.1) id AA07799; Tue, 6 Jul 93 15:21:11 EDT Received: from lehman.com by shearson.com (4.1/LB-0.6) id AA21734; Tue, 6 Jul 93 15:20:55 EDT Received: from shearson.com ([192.9.140.112]) by lehman.com (4.1/LB 0.1) id AA07789; Tue, 6 Jul 93 15:20:35 EDT Received: from snark.shearson.com by shearson.com (4.1/LB-0.6) id AA21725; Tue, 6 Jul 93 15:20:26 EDT Received: by snark.shearson.com (4.1/SMI-4.1) id AA10613; Tue, 6 Jul 93 15:20:24 EDT Message-Id: <9307061920.AA10613@snark.shearson.com> To: nmh@thumper.bellcore.com (Neil Haller) Cc: stubble@isi.edu, ipsec@ans.net Subject: Re: IPSEC Agenda In-Reply-To: Your message of "Tue, 06 Jul 1993 14:58:33 EDT." <9307061858.AA03601@fall.bellcore.com> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Tue, 06 Jul 1993 15:20:24 -0400 From: "Perry E. Metzger" Neil Haller says: > > >I am curious how much interest there is for traffic flow confidentiality > > Traffic flow confidentially is interesting, important, and hard. > I would like to see a discussion of ideas, but it shouldn't slow > progress on a basic IP security mechanism. It should be easy to protect traffic flow from traffic analysis with the swIPe proposal. You could generate all the fake traffic you wanted with very little work. Given the swIPe "IP in IP" infrastructure, you can also trivially conceal where packets are really going from and where they are really going to. It provides an excellent and simple mechanism for doing whatever you could possibly want to do IMHO. Perry From atkinson@itd.nrl.navy.mil Tue Jul 6 20:39:17 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17659 (5.65c/IDA-1.4.4 for ); Wed, 7 Jul 1993 00:40:55 -0400 Received: from itd.nrl.navy.mil by interlock.ans.net with SMTP id AA16301 (InterLock SMTP Gateway 1.1 for ); Wed, 7 Jul 1993 00:34:22 -0400 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA08924; Wed, 7 Jul 93 00:39:17 EDT Date: Wed, 7 Jul 93 00:39:17 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9307070439.AA08924@itd.nrl.navy.mil> To: nmh@thumper.bellcore.com, pmetzger@lehman.com Subject: Re: IPSEC Agenda Cc: ipsec@ans.net, stubble@isi.edu It isn't as easy as Perry suggests. I agree with Neil. Getting traffic flow security would be nice, but lets concentrate on getting the fundamental parts of IP security in place first. Traffic flow security can be solved using mechanisms separate from and below IP and need not be solved at the IP layer. Ran atkinson@itd.nrl.navy.mil From pmetzger@lehman.com Wed Jul 7 15:20:11 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17595 (5.65c/IDA-1.4.4 for ); Wed, 7 Jul 1993 11:27:37 -0400 Received: from Lehman.COM by interlock.ans.net with SMTP id AA12522 (InterLock SMTP Gateway 1.1 for ); Wed, 7 Jul 1993 11:15:23 -0400 Received: from shearson.com ([192.9.140.112]) by lehman.com (4.1/LB 0.1) id AA11084; Wed, 7 Jul 93 11:20:18 EDT Received: from lehman.com by shearson.com (4.1/LB-0.6) id AA11222; Wed, 7 Jul 93 11:20:16 EDT Received: from shearson.com ([192.9.140.112]) by lehman.com (4.1/LB 0.1) id AA11081; Wed, 7 Jul 93 11:20:15 EDT Received: from snark.shearson.com by shearson.com (4.1/LB-0.6) id AA11219; Wed, 7 Jul 93 11:20:13 EDT Received: by snark.shearson.com (4.1/SMI-4.1) id AA16322; Wed, 7 Jul 93 11:20:11 EDT Message-Id: <9307071520.AA16322@snark.shearson.com> To: ipsec@ans.net Subject: Re: IPSEC Agenda In-Reply-To: Your message of "Wed, 07 Jul 1993 00:39:17 EDT." <9307070439.AA08924@itd.nrl.navy.mil> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Wed, 07 Jul 1993 11:20:11 -0400 From: "Perry E. Metzger" Ran Atkinson says: > It isn't as easy as Perry suggests. I agree with Neil. > > Getting traffic flow security would be nice, but lets concentrate on > getting the fundamental parts of IP security in place first. Traffic > flow security can be solved using mechanisms separate from and below > IP and need not be solved at the IP layer. How can you do traffic flow security below the IP layer if the encryption in your system is at the IP layer? This hacker can't think of a mechanism and would like to know how you can do it. Also, you say "It isn't as easy as Perry suggests." I'd like to know why. A bare assertion doesn't sit well with me. If you disagree with what I have to say, it would be nice to know what you think is wrong with the statement. E-Mail eliminates emotion -- please understand I'm not being hostile -- I just honestly want to know what you think is incorrect about this. As I said, IMHO, swIPe has the distinct advantage that its easy to think of how you can build systems to pad your traffic or conceal sources and destinations. Since its built on IP in IP, you can decide to falsify traffic in dozens of ways -- fake extra traffic, conceal sources and destinations, route packets through odd paths with destination concealed at each point, etc. In fact, its VERY easy to do it -- many kinds of concealment policy could be implemented on top of it. It provides an obvious mechanism without policy, which is a Good Thing. The fact that swIPe would give this to you for free is, in my opinion, a win. Perry From dan@isv.dec.com Thu Jul 8 13:10:07 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18721 (5.65c/IDA-1.4.4 for ); Thu, 8 Jul 1993 09:12:23 -0400 Received: from inet-gw-2.pa.dec.com by interlock.ans.net with SMTP id AA03684 (InterLock SMTP Gateway 1.1 for ); Thu, 8 Jul 1993 09:05:36 -0400 Received: by inet-gw-2.pa.dec.com; id AA17625; Thu, 8 Jul 93 06:10:27 -0700 Received: by vbormc.vbo.dec.com; id AA27357; Thu, 8 Jul 93 15:09:53 +0200 Received: by jerusalem (5.57/fma-100391); id AA27956; Thu, 8 Jul 93 16:10:08 +0300 Message-Id: <9307081310.AA27956@jerusalem> To: ipsec@ans.net Cc: dan@isv.dec.com Subject: Hardware support Date: Thu, 08 Jul 93 16:10:07 +0300 From: dan@isv.dec.com X-Mts: smtp An issue that wasn't addressed so far as related to the IPSP packet format is provision for support by hardware for fast links. I believe it is important the agreed on packet format does not preclude the use of an outboard `crypto engine' to accelerate encryption. The hardware would be built in such a fashion to perform cryptographic processing on packets as they traverse the link as opposed to a DES chip that resides on the system bus. A typical configuration would be to have the device attached between the host's Ethernet interface and the backbone segment. There are several requirements from the packet format that would simplify the parsing performed by the device and enhance its performance. These are prerequisites to the design of a low-cost device: [1] The ICV (Integrity Check Value) should be placed at the end of the packet as a trailer rather than as part of the header. This would allow the device to calculate and check the ICV while packets flow through it (`cut through') without the need to use store and forward thus reducing latency. [2] The integrity/authentication algorithm used should be the same as used for encryption to reduce hardware complexity. One way of achieving an ICV with DES/CBC is to use the DES residue. Using separate algorithms for encryption and authentication means implementing both algorithms in hardware; this could be complex and expensive in terms of chip real estate. [3] Use an 8-byte SAID (or Key ID) field. The hardware needs to determine from the contents of an incoming packet how decryption should be performed. A common approach is to use an index into a table containing encryption keys. A drawback of this approach is that it forces the device to store a potentially large table of keys. A different approach is to use an encrypted DES key. The device performs 2 iterations of decryption: It first decrypts the key received in the packet with a ``Master key'' not known to anyone by itself. Subsequently, the data is decrypted with the resulting key. Keys are established using Diffie-Hellman or a similar process. The hosts then each encrypt the session key under their master key and send the result to each other for subsequent inclusion in data packets. [4] Include a fragmentation/reassembly mechanism to eliminate the need to perform fragmentation by IP on the originating system. A fragmented packet cannot be decrypted by hardware ``on the fly'' due to several reasons; A simple and inexpensive device cannot be expected to maintain context between fragments to perform decryption. The best it can do is detect that fragmentation has taken place and pass the packet unmodified to the host which will handle decryption. Many popular implementations of NFS generate 8K UDP packets that are fragmented by IP on the originating system. Such packets cannot be cryptographically processed by hardware. Incorporating a fragmentation facility into IPSP would eliminate this problem as packets would be fragmented at this level rather than by IP, thus the IPSP header would be included in every packet. Dan ------------------------------------------------------------------------------- Dan Frommer | Digital Equipment Corporation | Internet: dan@isv.dec.com P.O. Box 10109 | Phone : +972 2 782551 Jerusalem 93 469, Israel | Fax : +972 2 782373 ------------------------------------------------------------------------------- From nmh@thumper.bellcore.com Thu Jul 8 06:17:20 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18790 (5.65c/IDA-1.4.4 for ); Thu, 8 Jul 1993 10:19:53 -0400 Received: from thumper.bellcore.com by interlock.ans.net with SMTP id AA02892 (InterLock SMTP Gateway 1.1 for ); Thu, 8 Jul 1993 10:12:26 -0400 Received: from latour.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ipsec@ans.net; Thu, 8 Jul 93 10:17:20 EDT Received: by latour.bellcore.com (4.1/4.7) id for ipsec@ans.net; Thu, 8 Jul 93 10:17:20 EDT Date: Thu, 8 Jul 93 10:17:20 EDT From: nmh@thumper.bellcore.com (Neil Haller) Message-Id: <9307081417.AA28820@latour.bellcore.com> To: ipsec@ans.net Subject: Re: Hardware support > [2] The integrity/authentication algorithm used should be the same > as used for encryption to reduce hardware complexity. ... I think it would be a mistake to use DES for the integrity/authentication check. DES is much slower in software than MD5, and then there is the export control issue. Neil Haller From Paul_Lambert@poncho.phx.sectel.mot.com Tue Jul 6 09:51:46 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19963 (5.65c/IDA-1.4.4 for ); Thu, 8 Jul 1993 16:35:20 -0400 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA20041 (InterLock SMTP Gateway 1.1 for ); Thu, 8 Jul 1993 16:28:13 -0400 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.15 for ) id AA04852; Thu, 8 Jul 1993 15:33:08 -0500 Received: from phx.sectel.mot.com (rambo.phx.sectel.mot.com) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.15 for ) id AA11949; Thu, 8 Jul 1993 15:33:06 -0500 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA29788; Tue, 6 Jul 93 16:54:27 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA40084; Tue, 6 Jul 1993 16:56:24 MST Message-Id: <00112.2824822584.40084@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list), rem-conf@es.net (rem-conf) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Tue, 6 Jul 1993 16:51:46 MST Subject: IPSEC & Multipoint IPSEC & Multipoint Regarding IPSP and support for multipoint communications: >Date: 6 Jul 93 13:13:04 -0400 >From: Ran Atkinson >To: ipsec@ans.net, > >I have a couple of comments on the agenda... > > ... > ... Also conference control security > is a problem for the working group on internet conferencing not for > IPSP. The conference control problem is not necessarily best solved > at the IP layer and the IPSP WG should narrow its focus to IP security. and >From: Stuart Stubblebine > >1. I agree with Ran that conference control is not what needs to be >addressed in the IPSEC WG meeting. Instead the -shortened- item of >"multicasting" is the requirement/consideration at the network layer for the >scalability of secure conferencing. For secure conferencing, the security >services of data confidentiality and data origin authentication should scale >well for datagrams addressed to large multicast groups. (Furthermore, the >time to process the datagrams should be minimal.) I did not put *conference control* on the agenda, only multicast and conferencing. I agree that conference control is not in the scope of the IP Security Protocol (IPSP), but we need to document the IPSP mechanisms that support mulipoint communications. Not all IP communications are point-to-point. Broadcast, multicast, or multipoint communications all require special cryptographic considerations. The key used to decrypt multipoint traffic must be available to all recipients. This impacts the way that security identifiers need to be allocated in the IPSP clear header. Some portion of the identifier space needs to be reserved for multipoint communications. Conferencing is just one application of the multipoint mechanism and I will remove this specific reference from the agenda. Paul From Paul_Lambert@poncho.phx.sectel.mot.com Tue Jul 6 09:28:45 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20225 (5.65c/IDA-1.4.4 for ); Thu, 8 Jul 1993 16:35:28 -0400 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA13121 (InterLock SMTP Gateway 1.1 for ); Thu, 8 Jul 1993 16:27:54 -0400 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.15 for ) id AA04824; Thu, 8 Jul 1993 15:32:50 -0500 Received: from phx.sectel.mot.com (rambo.phx.sectel.mot.com) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.15 for ) id AA11918; Thu, 8 Jul 1993 15:32:48 -0500 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA29776; Tue, 6 Jul 93 16:35:58 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA40081; Tue, 6 Jul 1993 16:39:43 MST Message-Id: <00112.2824821583.40081@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: Tue, 6 Jul 1993 16:28:45 MST Subject: IPSP & Labels IPSP & Labels >From: Ran Atkinson >To: ipsec@ans.net, > >I have a couple of comments on the agenda... > > ... I would also > suggest that IP labelling is out of the scope of the IPSP working group. > The IPSP working group clearly needs to support RFC-1108 which > is on the Internet Standards track. The IPSP should support labels by providing a field to optionally carry label information. I agree that we should not enter into the morass of label formats. We must at a minimum describe our relationship and possible use of RFC-1108. Ran, maybe you could help on this text (hint, hint ..). Paul From Paul_Lambert@poncho.phx.sectel.mot.com Tue Jul 6 10:11:50 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA19718 (5.65c/IDA-1.4.4 for ); Thu, 8 Jul 1993 16:36:13 -0400 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA15947 (InterLock SMTP Gateway 1.1 for ); Thu, 8 Jul 1993 16:28:16 -0400 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.15 for ) id AA04856; Thu, 8 Jul 1993 15:33:11 -0500 Received: from phx.sectel.mot.com (rambo.phx.sectel.mot.com) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.15 for ) id AA11955; Thu, 8 Jul 1993 15:33:09 -0500 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA29808; Tue, 6 Jul 93 17:13:14 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA40086; Tue, 6 Jul 1993 17:15:11 MST Message-Id: <00112.2824823711.40086@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list), rem-conf@es.net (rem-conf) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Tue, 6 Jul 1993 17:11:50 MST Subject: Re: IPSEC & Multipoint RE>IPSEC & Multipoint Oops, let me withdraw my previous comment about : >I did not put *conference control* on the agenda, only multicast and conferencing. The 9:45 IPSP agenda item had *Multicast and Conferencing* and the 11:00 Key management item did have *Multicast and Conference Control*. Sorry for the confusion and the double posting (a jittery mouse finger). I will remove conference control from the Key Management agenda item. While removing this item from the next meeting, it is still an interesting issue to consider the relationship of multipoint key distribution to conference control. The control of the multipoint key distribution ought to be a service that can be used by other applications, like conference control, to securely establish connectivity. Paul From Paul_Lambert@poncho.phx.sectel.mot.com Tue Jul 6 09:28:33 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13832 (5.65c/IDA-1.4.4 for ); Thu, 8 Jul 1993 16:36:14 -0400 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA19267 (InterLock SMTP Gateway 1.1 for ); Thu, 8 Jul 1993 16:27:57 -0400 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.15 for ) id AA04828; Thu, 8 Jul 1993 15:32:53 -0500 Received: from phx.sectel.mot.com (rambo.phx.sectel.mot.com) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.15 for ) id AA11925; Thu, 8 Jul 1993 15:32:51 -0500 Received: from pobox by phx.sectel.mot.com (4.1/SMI-4.1) id AB29770; Tue, 6 Jul 93 16:27:37 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA40079; Tue, 6 Jul 1993 16:28:53 MST Message-Id: <00112.2824820933.40079@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list), rem-conf@es.net (rem-conf) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Tue, 6 Jul 1993 16:28:33 MST Subject: IPSEC & Multipoint IPSEC & Multipoint Regarding IPSP and support for multipoint communications: >Date: 6 Jul 93 13:13:04 -0400 >From: Ran Atkinson >To: ipsec@ans.net, > >I have a couple of comments on the agenda... > > ... > ... Also conference control security > is a problem for the working group on internet conferencing not for > IPSP. The conference control problem is not necessarily best solved > at the IP layer and the IPSP WG should narrow its focus to IP security. and >From: Stuart Stubblebine > >1. I agree with Ran that conference control is not what needs to be >addressed in the IPSEC WG meeting. Instead the -shortened- item of >"multicasting" is the requirement/consideration at the network layer for the >scalability of secure conferencing. For secure conferencing, the security >services of data confidentiality and data origin authentication should scale >well for datagrams addressed to large multicast groups. (Furthermore, the >time to process the datagrams should be minimal.) I did not put *conference control* on the agenda, only multicast and conferencing. I agree that conference control is not in the scope of the IP Security Protocol (IPSP), but we need to document the IPSP mechanisms that support mulipoint communications. Not all IP communications are point-to-point. Broadcast, multicast, or multipoint communications all require special cryptographic considerations. The key used to decrypt multipoint traffic must be available to all recipients. This impacts the way that security identifiers need to be allocated in the IPSP clear header. Some portion of the identifier space needs to be reserved for multipoint communications. Conferencing is just one application of the multipoint mechanism and I will remove this specific reference from the agenda. Paul From Paul_Lambert@poncho.phx.sectel.mot.com Tue Jul 6 09:28:20 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20240 (5.65c/IDA-1.4.4 for ); Thu, 8 Jul 1993 16:36:40 -0400 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA20557 (InterLock SMTP Gateway 1.1 for ); Thu, 8 Jul 1993 16:28:25 -0400 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.15 for ) id AA04864; Thu, 8 Jul 1993 15:33:21 -0500 Received: from phx.sectel.mot.com (rambo.phx.sectel.mot.com) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.15 for ) id AA11967; Thu, 8 Jul 1993 15:33:18 -0500 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA29770; Tue, 6 Jul 93 16:27:04 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA40078; Tue, 6 Jul 1993 16:28:51 MST Message-Id: <00112.2824820931.40078@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: atkinson@itd.nrl.navy.mil (Ran Atkinson), ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Tue, 6 Jul 1993 16:28:20 MST Subject: Re: >IPSEC Agenda Reply to: RE>>IPSEC Agenda Ran, Thanks for the comments on the agenda. >Date: 6 Jul 93 13:13:04 -0400 >From: Ran Atkinson >To: ipsec@ans.net, > Paul_Lambert-P15452 >Subject: Re: IPSEC Agenda >Message-Id: <9307061713.AA10797@itd.nrl.navy.mil> > > > >I have a couple of comments on the agenda... > >1) I'm very surprised to hear that there are only "experimental" > implementations of SP3. This is simply not true. The US Government > currently uses SP3 implementations, which are purchased commercially, > to secure some of its networks. SP3 is known to be solid and to work > well and be scalable to higher bandwidth networks. It is not experimental > at all, but rather is a solid production-quality protocol and has > a clear, readable, and sufficiently detailed specification. You are correct that SP3 is widely installed. Experimental is the wrong term for SP3 and I will modify the agenda. The intent was to provide time for a brief discussion of existing network security implementations some of which are experimental. >2) What is the status of getting the IPSP session onto the MBONE Multicast > Conference list for Amsterdam ? A number of us are unable to attend > and would like to participate via the MBONE. It looks like a MBONE slot may be open on Tuesday morning! I will attempt to arrange for IPSEC to be multicast and will post a note to this list when I get confirmation. > 3) I don't see any announcement of an IPSP draft being available online > via the Internet drafts mechanism. As such, it is inappropriate to > discuss any particular IPSP draft or select one at this time. Drafts > for the various proposals need to be made fully available using the > Internet Drafts mechanism sufficiently before any IETF meeting or any > decision so that anyone on the Internet may have time to review and comment > on those drafts. > > As such the 0945 agenda item appears to be inappropriate if it > talks about any specific IPSP draft proposal rather than discussing > technical features desired in a proposal-neutral manner. ... You are correct that no IPSP draft is currently available online. This portion of the agenda represented my own commitment to cobble together a working draft of a specification for the group to review. I agree that any draft should ideally be available at least two weeks before a meeting. However, given the dearth of contributions I had assumed that any draft would be better than no draft. This *draft* would have been posted this weekend, in time for discussion (but not much review) at the Amsterdam meeting. We did discuss at the last meeting most of the technical *features* and requirements that would be appropriate in IPSP. Some of these features were controversial. I had hoped that a working draft would be a good way to capture this work. If you insist, I will postpone posting a working draft for a few months until we have a better document that has been fully reviewed and approved. > ... > 4) I would like to encourage more email list discussions and less reliance > on face to face meetings. Decisions reached at IETF physical meetings > are not necessarily binding on the whole working group and all subjects > should be thoroughly discussed on the email list as well before any > conclusions are drawn. One of the big advantages of the IETF process > over some less successful processes is this ability to discuss matters > via email so that there is more discussion and review of the technical > content prior to making any decisions. It will always be the case that > some folks can't make a physical meeting (Amsterdam is maybe worse than > normal in this respect) and email is a critical part of the IETF process. Ok, lets send more email to this list ... Thanks again for your comments, Paul From Paul_Lambert@poncho.phx.sectel.mot.com Thu Jul 8 09:11:59 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17650 (5.65c/IDA-1.4.4 for ); Thu, 8 Jul 1993 19:25:57 -0400 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA08262 (InterLock SMTP Gateway 1.1 for ); Thu, 8 Jul 1993 19:10:24 -0400 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.15 for ) id AA14589; Thu, 8 Jul 1993 18:15:19 -0500 Received: from phx.sectel.mot.com (rambo.phx.sectel.mot.com) by pobox.mot.com with SMTP (5.67a/IDA-1.4.4/MOT-2.15 for ) id AA26512; Thu, 8 Jul 1993 18:15:17 -0500 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA05700; Thu, 8 Jul 93 16:14:01 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA40321; Thu, 8 Jul 1993 16:16:35 MST Message-Id: <00112.2824992995.40321@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list), pmetzger@lehman.com (pmetzger) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Thu, 8 Jul 1993 16:11:59 MST Subject: Re: >IPSEC Agenda &swIPE Reply to: RE>>IPSEC Agenda &swIPE Perry, In regards to your comments on swIPe: >As I said, IMHO, swIPe has the distinct advantage that its easy to >think of how you can build systems to pad your traffic or conceal >sources and destinations. Since its built on IP in IP, you can decide >to falsify traffic in dozens of ways -- fake extra traffic, conceal >sources and destinations, route packets through odd paths with >destination concealed at each point, etc. In fact, its VERY easy to do >it -- many kinds of concealment policy could be implemented on top of >it. It provides an obvious mechanism without policy, which is a Good >Thing. The fact that swIPe would give this to you for free is, in my >opinion, a win. > >Perry Is there any documentation of swIPe available online? Paul From atkinson@itd.nrl.navy.mil Thu Jul 8 22:28:03 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA03287 (5.65c/IDA-1.4.4 for ); Fri, 9 Jul 1993 02:32:02 -0400 Received: from itd.nrl.navy.mil by interlock.ans.net with SMTP id AA16562 (InterLock SMTP Gateway 1.1 for ); Fri, 9 Jul 1993 02:23:11 -0400 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA03406; Fri, 9 Jul 93 02:28:03 EDT Date: Fri, 9 Jul 93 02:28:03 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9307090628.AA03406@itd.nrl.navy.mil> To: Paul_Lambert@poncho.phx.sectel.mot.com, atkinson@itd.nrl.navy.mil, ipsec@ans.net Subject: Re: >IPSEC Agenda Paul, By all means post your draft proposal. However, the text of that Internet Draft should make it clear that it is only one possible proposal fo an IP Security Protocol. I happen to consider SP3's IP variant a very solid proposal that should be seriously considered as a/the base document. I believe that other folks feel the same way about SP3. If anyone has SP3 in electronic form, that would also be a good Internet Draft to have available. I also understand that a more detailed draft of the "swIPe" proposal is in preparation and I believe that those folks should be given an opportunity (and encouraged) to post "swIPe" as another Internet Draft. In my view, the "swIPe" folks need to act sooner rather than later in posting a specific proposal as an Internet Draft. As you can tell, I perceive there to be at least 3 potential approaches. Before we narrow down to using any specific proposal as a base document or the moral equivalent of that, I think we need to see Internet Drafts of all of them and have ample discussion on the ipsec mailing list. Ran atkinson@itd.nrl.navy.mil From atkinson@itd.nrl.navy.mil Thu Jul 8 22:33:20 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA17629 (5.65c/IDA-1.4.4 for ); Fri, 9 Jul 1993 02:35:39 -0400 Received: from itd.nrl.navy.mil by interlock.ans.net with SMTP id AA14525 (InterLock SMTP Gateway 1.1 for ); Fri, 9 Jul 1993 02:28:27 -0400 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA03446; Fri, 9 Jul 93 02:33:20 EDT Date: Fri, 9 Jul 93 02:33:20 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9307090633.AA03446@itd.nrl.navy.mil> To: Paul_Lambert@poncho.phx.sectel.mot.com Subject: Re: IPSP & Labels Cc: ipsec@ans.net Paul, I don't think I was very clear. Please permit me to try to clarify my view... IPSP should permit the use of Internet Standard IP options to carry labels. IPSP should not include a field within the IPSP protocol that is a sensitivity label field. This way we decouple the security mechanism from the sensitivity label mechanism somewhat and thereby permit innovation and improvement in IP labelling through the lifetime of IPSP without having to modify IPSP. Also, different communities might have different views on what kinds of labels are useful to have/use. This decoupling of labelling from protection also promotes the ability to have labelled IPv4 traffic be sent through an IPSP engine for protection and then reappear on the far end, be unprotected, and have the original labels be intact so that the protection mechanism is less obtrusive into ordinary users (thinking mainly of the subnet--subnet protection model as an example here). Ran atkinson@itd.nrl.navy.mil From atkinson@itd.nrl.navy.mil Thu Jul 8 22:51:18 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA05132 (5.65c/IDA-1.4.4 for ); Fri, 9 Jul 1993 02:52:16 -0400 Received: from itd.nrl.navy.mil by interlock.ans.net with SMTP id AA14567 (InterLock SMTP Gateway 1.1 for ); Fri, 9 Jul 1993 02:46:26 -0400 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA03540; Fri, 9 Jul 93 02:51:18 EDT Date: Fri, 9 Jul 93 02:51:18 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9307090651.AA03540@itd.nrl.navy.mil> To: ipsec@ans.net Subject: Internet Drafts & IPSP work There are a number of folks participating in the IPSP work who are perhaps fairly new to the IETF and the IETF way of doing things. So let me encourage those folks to get and read "The Tao of the IETF" and the other introductory documents (either online or whilst at the IETF in Amsterdam). The IETF process is significantly different from ANSI/ISO/CCITT processes. In particular, ALL working drafts and ALL proposals should normally be kept online as Internet Drafts. It is not generally acceptable practice to only put something out as an Internet Draft only after the group has "blessed" or "reached consensus" or what have you. Also, anyone can put out almost anything as an Internet Draft (there are minimal syntax and format rules which are available online). The reason for this is that the preferred and standard way of distributing proposals and working documents is online from the Internet Drafts directory. These practices permit everyone on the Internet to read and review all the drafts easily. The larger peer review of folks outside the working group is desirable and leads to better specifications. So I stress that the existence of something as an Internet Draft does not make it "preferred" or "blessed" but rather just means that it is something that folks in the working group should be reading and discussing. Note also that all new Internet Drafts will be announced by the IETF Secretariat to the entire IETF and so will almost certainly get wider review than just the working group (again, this is a feature). During the development of MIME, there were several different Internet Drafts at the same time that proposed different ways of doing multimedia/multilingual email. Some proposals became Internet standards-track RFCs, some became informational RFCs, and some eventually died because the consensus was that they were not worth implementing or documenting as RFCs. The point is that making all the working documents and drafts (even competing drafts) available online as Internet Drafts helps make the IETF process one of the most open on the planet and thereby helps the IETF develop really good specs that are readable and that will actually be implemented widely. So my earlier suggestion that we see Paul's draft and an SP3 like draft and a swIPe draft is really a suggestion that the group operate in a manner consistent with the normal IETF process. Regards, Ran atkinson@itd.nrl.navy.mil From nmh@thumper.bellcore.com Fri Jul 9 06:44:23 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA20399 (5.65c/IDA-1.4.4 for ); Fri, 9 Jul 1993 10:45:53 -0400 Received: from thumper.bellcore.com by interlock.ans.net with SMTP id AA13933 (InterLock SMTP Gateway 1.1 for ); Fri, 9 Jul 1993 10:39:30 -0400 Received: from latour.bellcore.com by thumper.bellcore.com (4.1/4.7) id for ipsec@ans.net; Fri, 9 Jul 93 10:44:24 EDT Received: by latour.bellcore.com (4.1/4.7) id for ipsec@ans.net; Fri, 9 Jul 93 10:44:23 EDT Date: Fri, 9 Jul 93 10:44:23 EDT From: nmh@thumper.bellcore.com (Neil Haller) Message-Id: <9307091444.AA21091@latour.bellcore.com> To: ipsec@ans.net Subject: Re: IPSP & Labels Ran, Is it fair to interpret what you are advocating as: The IP packet carried in the IPSP packet should be a standard IP packet; no more and no less. Neil nmh@thumper.bellcore.com From aditya@cdotd.ernet.in Tue Jun 22 09:47:48 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA16486 (5.65c/IDA-1.4.4 for ); Sat, 10 Jul 1993 03:16:16 -0400 Received: from spool.UU.NET by interlock.ans.net with SMTP id AA06289 (InterLock SMTP Gateway 1.1 for ); Sat, 10 Jul 1993 03:02:08 -0400 Received: by spool.UU.NET with UUCP (5.61/UUNET-uucp-primary) id AA24113; Sat, 10 Jul 93 03:07:03 -0400 From: aditya@cdotd.ernet.in Received: by sangam.ncst.ernet.in (4.1/SMI-4.1-MHS-7.0) id AA25003; Tue, 22 Jun 93 15:58:03+0530 Received: from cdotd.UUCP by ern.doe.ernet.in (4.1/SMI-4.1-MHS-7.0) id AA29100; Tue, 22 Jun 93 15:17:48+0530 Date: Tue, 22 Jun 93 15:17:48+0530 Message-Id: <9306220947.AA29100@ern.doe.ernet.in> To: ldl@ans.net Subject: Re: ipsec mailing list Cc: aditya@sangam.ncst.ernet.in, ipsec-request@ans.net, ipsec@ans.net I am not on the mailing list. Kindly put me on the list. Thanks, Aditya Chaudhuri From Paul_Lambert@poncho.phx.sectel.mot.com Mon Jul 12 10:48:45 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12253 (5.65c/IDA-1.4.4 for ); Mon, 12 Jul 1993 20:48:56 -0400 Received: from motgate.mot.com by interlock.ans.net with SMTP id AA21843 (InterLock SMTP Gateway 1.1 for ); Mon, 12 Jul 1993 20:42:09 -0400 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.15 for ) id AA25299; Mon, 12 Jul 1993 19:47:03 -0500 Received: from phx.sectel.mot.com (rambo.phx.sectel.mot.com) by pobox.mot.com with SMTP (5.67a/IDA-1.4.4/MOT-2.15 for ) id AA22214; Mon, 12 Jul 1993 19:47:02 -0500 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA13729; Mon, 12 Jul 93 17:45:26 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA40618; Mon, 12 Jul 1993 17:49:42 MST Message-Id: <00112.2825344182.40618@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Cc: ipsec@ans.net (ip security mailing list) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Mon, 12 Jul 1993 17:48:45 MST Subject: Re: >>IPSEC Agenda Reply to: RE>>>IPSEC Agenda Ran, Thanks for the encouragement to post, but I am not able to complete the work before the meeting. >Paul, > > By all means post your draft proposal. However, the text of that >Internet Draft should make it clear that it is only one possible >proposal fo an IP Security Protocol. > > I happen to consider SP3's IP variant a very solid proposal that >should be seriously considered as a/the base document. I believe that >other folks feel the same way about SP3. If anyone has SP3 in electronic >form, that would also be a good Internet Draft to have available. > > I also understand that a more detailed draft of the "swIPe" proposal >is in preparation and I believe that those folks should be given an >opportunity (and encouraged) to post "swIPe" as another Internet >Draft. In my view, the "swIPe" folks need to act sooner rather than >later in posting a specific proposal as an Internet Draft. > > As you can tell, I perceive there to be at least 3 potential >approaches. Before we narrow down to using any specific proposal as a >base document or the moral equivalent of that, I think we need to see >Internet Drafts of all of them and have ample discussion on the ipsec >mailing list. > >Ran >atkinson@itd.nrl.navy.mil > I did error somewhat in calling the document that IUd intended to post a proposal. I was really trying to put together a discussion document for the meeting that was somewhat proposal neutral. It is obviously too late now, with the meeting tomorrow, but I will post after the meeting and hopefully incorporate any recommendations from the meeting. I have found some versions of the SP3 documentation that might be a viable source for raw text. The latest NLSP should also be available soon in electronic format. Hopefully next week we can get SP3, NLSP, and other reference documents on our archive server. Paul From atkinson@itd.nrl.navy.mil Tue Jul 13 05:24:35 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA12118 (5.65c/IDA-1.4.4 for ); Tue, 13 Jul 1993 09:26:51 -0400 Received: from itd.nrl.navy.mil by interlock.ans.net with SMTP id AA07326 (InterLock SMTP Gateway 1.1 for ); Tue, 13 Jul 1993 09:19:43 -0400 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA06852; Tue, 13 Jul 93 09:24:35 EDT Date: Tue, 13 Jul 93 09:24:35 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9307131324.AA06852@itd.nrl.navy.mil> To: Paul_Lambert@poncho.phx.sectel.mot.com Subject: Re: >>IPSEC Agenda Cc: ipsec@ans.net Paul, Thanks for your note. Please lets get all the drafts out as Internet Drafts so they are fully and easily available to everyone rather than just being on a single archive server. I would feel much more comfortable if we did not keep working documents on some secondary archive server and would much prefer to use the Internet Draft system for working documents. We did this with the MIME work and it made it much easier for folks to get drafts and participate. If I can help with this in any way, please let me know how. Thanks, Ran atkinson@itd.nrl.navy.mil From kate@digiw.fi Thu Jul 15 14:18:35 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA18404 (5.65c/IDA-1.4.4 for ); Thu, 15 Jul 1993 11:31:32 -0400 Received: from eunet.fi by interlock.ans.net with SMTP id AA06830 (InterLock SMTP Gateway 1.1 for ); Thu, 15 Jul 1993 11:22:55 -0400 Received: from digiw.fi by eunet.fi with SMTP id AA20267 (5.65c+l/IDA-1.4.4 for ); Thu, 15 Jul 1993 18:27:43 +0300 Received: by digiw.fi (5.65/1.34) id AA28272; Thu, 15 Jul 93 17:18:35 +0300 (MET) Date: Thu, 15 Jul 93 17:18:35 +0300 From: kate@digiw.fi (Kate Marika Alhola) Message-Id: <9307151418.AA28272@digiw.fi> To: ipsec@ans.net Subject: Ipsec Draft > Goals and Milestones: > > June 93 Post as an Internet-Draft the IP Security Protocol. Where i can find this one, i have not seen it here or even reference to ftp server where i can found it. I am looking way to implement net to net secure IP by crypting TCP and UDP packets going between networks. At this moment i have plan to implement it as a extra layer berween IP and network Driver. Kate Alhola kate@digiw.fi From ahoover@ans.net Mon Jul 19 13:13:42 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA13779 (5.65c/IDA-1.4.4 for ); Mon, 19 Jul 1993 06:16:14 -0400 Received: by interlock.ans.net id AA21139 (InterLock SMTP Gateway 1.1 for ipsec@ans.net); Mon, 19 Jul 1993 06:08:40 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 19 Jul 1993 06:08:40 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 19 Jul 1993 06:08:40 -0400 Date: Mon, 19 Jul 1993 06:13:42 -0700 From: Alton Hoover Message-Id: <199307191313.AA26427@hoovermac.ans.net> To: ipsec@ans.net Subject: IPSEC Draft Posting To: kate@digiw.fi Subject: Re: Ipsec Draft Kate: The Draft is expected to be posted by 8-30-93 or earlier. Notes from the IPSEC meeting will be posted in the next 2 weeks or less. These will also be available at ftp.ans.net in the /pub/ipsec directory besides being posted to the list. Al H. ---- Previous Message ---- To: ipsec@ans.net Subject: Ipsec Draft Status: R > Goals and Milestones: > > June 93 Post as an Internet-Draft the IP Security Protocol. Where i can find this one, i have not seen it here or even reference to ftp server where i can found it. I am looking way to implement net to net secure IP by crypting TCP and UDP packets going between networks. At this moment i have plan to implement it as a extra layer berween IP and network Driver. Kate Alhola kate@digiw.fi From simon@matisse.harvard.edu Thu Jul 29 11:32:27 1993 Received: from interlock.ans.net by nis.ans.net with SMTP id AA14178 (5.65c/IDA-1.4.4 for ); Fri, 30 Jul 1993 11:06:22 -0400 Received: from head-cfa.harvard.edu by interlock.ans.net with SMTP id AA03591 (InterLock SMTP Gateway 1.1 for ); Fri, 30 Jul 1993 11:00:00 -0400 Received: from matisse.harvard.edu by head-cfa.harvard.edu (4.1/SMI-4.0) id AA23624; Thu, 29 Jul 93 15:32:28 EDT Received: by matisse.harvard.edu (4.1/SMI-4.1) id AA01448; Thu, 29 Jul 93 15:32:27 EDT From: simon@matisse.harvard.edu (Richard Simon) Message-Id: <9307291932.AA01448@matisse.harvard.edu> To: ipsec@ans.net Cc: rsimon@matisse.harvard.edu Subject: IPSP Date: Thu, 29 Jul 93 15:32:27 EDT I would like to receive a copy of the IPSP when it becomes available. Thanks. ==================================================================== Rich Simon Smithsonian Astrophysical Observatory rsimon@matisse.harvard.edu 60 Garden Street, MS 6 Phone: 617-496-7714 Cambridge, MA 02138 USA