To: ipsec@TIS.COM Subject: Very Preliminary release of IPSEC code for Linux Reply-To: ji@hol.gr Organization: La maison qui rend fou. Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Date: Fri, 01 Nov 1996 01:32:11 +0200 From: John Ioannidis Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9611010802.aa00948@neptune.TIS.COM> -----BEGIN PGP SIGNED MESSAGE----- Content-Type: text/plain; charset=us-ascii Greetings! The Linux IPSP implementation I have been working on lately is finally at a stage where it can benefit from feedback, and also where other may also benefit from it. This is NOT an untar-and-play release; far from it. It is being made available so that it can reach the UnP stage faster than if only I work on it. The code compiles into a loadable module for the 2.0.xx (I'm running 2.0.24) kernel. Use at your own risk. I won't be held responsible even if it mails the contents of your filesystems to the NSA and the KGB (or whatever), and then proceeds to encrypt them :-) The gzip-ed tar file is in: http://prometheus.hol.gr/~ji/ipsec-0.2.tar.gz If you want to mirror it to your ftp site, please drop me a note. Enjoy! /ji -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQCVAgUBMnk2+c+A0YctPurVAQFSSAQAkt6e6a8TiYNcZ0rcLnxzIjm3uUTyYP3W sUaM9hkMYsDbePdc/O9GoA5Q/HnAg4/BNl+Tla1Os72NCq+uDZX2gDnlUFktnd9b q3S961FIL+ilmV0TepmQGGImjXPpThWMg4FKK7bhaiymcepJ7xs43sJoFEfkQ+uZ iUxTEo2j1Ro= =ztQp -----END PGP SIGNATURE----- Date: 31 Oct 1996 14:28:09 -0400 From: WaterhouseR Subject: ISAKMP Questions To: IPSEC Working Group X-Mailer: Mail*Link SMTP-MS 3.0.2 Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9611010807.aa01477@neptune.TIS.COM> The following is based on draft-ietf-ipsec-isakmp-05. 1. Since my application is not Internet, I will need to define a different DOI. IPSEC AH and IPSEC ESP are not relevant. Nevertheless, I see no reason to unnecessarily deviate re ISAKMP. Do the ISAKMP Proposal Formats exist anywhere - right now A.7.4 is empty. Figure 18 does provide some information (why is Protocol # (value=1) rather than value=3). But I can't identify what the ISAKMP Transform ID values are. Nor do I know how to populate the 32 bit fields defined in A.6.3 (plus "Group Identifier" seems to be undefined). 2. In places where you say "Values ... are reserved for private use." I'm assuming it's OK to select values from this range as long as I document this usage in my DOI. Do I go to IANA to get a DOI identifier ? 3. While I don't see this explicitly stated, I'm assuming I can define additional Notify Message Types within a DOI. (The alternative would be to define additional Payloads within the DOI.) Is any guidance available on the best values to use should this be done ? Message-Id: <199611010057.QAA19310@cornpuffs.cisco.com> From: Ran Atkinson Date: Thu, 31 Oct 1996 16:57:00 PST In-Reply-To: rja@cisco.com (Ran Atkinson) "ISAKMP support for inline keying" (Oct 16, 4:05pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipsec@TIS.COM Subject: [Admin] ISAKMP Inline Keying document editor Sender: ipsec-approval@neptune.tis.com Precedence: bulk All, The IPsec WG co-chairs would like to announce the appointment of Bill Sommerfeld as IPsec Document Editor for adding inline-keying support within the ISAKMP framework. This action is taken in conformance with the guidance provided by the Security AD in his September public statement. Bill is specifically asked to prepare an I-D (and corresponding presentation for the San Jose IETF) on placing inline-keying mechanisms within the ISAKMP Framework. This work is to be based on in part on SKIP as defined in and the other SKIP documents, and also based in part on inputs from other members of the working group. One goal of this specification is to devise a protocol that could share code with an ISAKMP implementation wherever that might be practical. It is intended that the resulting document will follow the normal IETF standards track ultimately resulting in a protocol specification that is ELECTIVE standard. Change control for the resulting specification will rest solely with the IETF. Ran rja@cisco.com -- Received: from relay.hq.tis.com by neptune.TIS.COM id aa02373; 1 Nov 96 8:19 EST Received: by relay.hq.tis.com; id IAA20460; Fri, 1 Nov 1996 08:23:20 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma020446; Fri, 1 Nov 96 08:23:01 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id IAA16824 for ; Fri, 1 Nov 1996 08:24:39 -0500 (EST) Received: by relay.hq.tis.com; id IAA20427; Fri, 1 Nov 1996 08:22:51 -0500 Received: from hutcs.cs.hut.fi(130.233.192.6) by relay.tis.com via smap (V3.1.1) id xma020413; Fri, 1 Nov 96 08:22:44 -0500 Received: from localhost (santtu@localhost) by hutcs.cs.hut.fi (8.7.6/8.7.3) with SMTP id PAA21743 for ; Fri, 1 Nov 1996 15:24:35 +0200 (EET) Date: Fri, 1 Nov 1996 15:24:35 +0200 (EET) From: Santeri Paavolainen X-Sender: santtu@hutcs To: ipsec@TIS.COM Subject: Re: proposed IPSEC changes/extensions In-Reply-To: <199610311806.NAA00482@thunk.orchard.medford.ma.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk On Thu, 31 Oct 1996, Bill Sommerfeld wrote: > > Isn't stateful compression most logically done as a separate > > protocol, performed prior to any IPSEC encryption? > > Maybe from a "purity of layers" perspective, but stateful compression > requires similar message-sequencing goop as replay detection; there > are likely some real efficiencies from handling both at the same > time.. True, but unless there is a good reason to put both of them into a single transformation they should be kept separate. It is up to the IPSEC layer to optimize (if possible) the packet processing. Even if compression and replay prevention both require state, their state is separate from each other's state. Compression does not need to know anything about replay prevention's state to work. Why should they be defined in the protocol to be contained both in a single transformation? There could be benefits in code if you combined both of these transformations into a single one, but I see optimizing for such case the responsibility of the IPSEC implementation, not the standard. Logically they should be separate -- the IPSEC code itself is free to implement them in any way as long as the final product appears to have gone through the both transformations as separate, even if the IPSEC itself has optimized by doing the both transformations in a more "singly" transformation way. I would not sacrifice the "purity of layers" for the ease of efficient implementation. I think to do so would be short-sighted. -- sjpaavol@cc.Helsinki.FI I have become death, destroyer of the worlds. Received: from relay.hq.tis.com by neptune.TIS.COM id aa02730; 1 Nov 96 12:47 EST Received: by relay.hq.tis.com; id MAA28942; Fri, 1 Nov 1996 12:51:34 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma028927; Fri, 1 Nov 96 12:51:06 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id MAA05607 for ; Fri, 1 Nov 1996 12:52:47 -0500 (EST) Received: by relay.hq.tis.com; id MAA28918; Fri, 1 Nov 1996 12:51:02 -0500 Received: from netmail.austin.ibm.com(129.35.208.98) by relay.tis.com via smap (V3.1.1) id xma028912; Fri, 1 Nov 96 12:51:00 -0500 Received: from vulcan.austin.ibm.com (vulcan.austin.ibm.com [129.35.56.115]) by netmail.austin.ibm.com (8.6.12/8.6.11) with SMTP id LAA141240; Fri, 1 Nov 1996 11:53:02 -0600 Received: by vulcan.austin.ibm.com (AIX 3.2/UCB 5.64/4.03-client-2.4) for ipsec@TIS.COM at austin.ibm.com; id AA30119; Fri, 1 Nov 1996 11:52:53 -0600 From: Will Fiveash Message-Id: <9611011752.AA30119@vulcan.austin.ibm.com> Subject: Re: ISPEC docs in AFS In-Reply-To: <9610312351.AA25929@vulcan.austin.ibm.com> from Will Fiveash at "Oct 31, 96 05:51:36 pm" To: will@austin.ibm.com Date: Fri, 1 Nov 1996 11:52:52 -0600 (CST) Cc: ipsec@TIS.COM Reply-To: will@austin.ibm.com X-Mailer: ELM [version 2.4ME+ PL26 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: ipsec-approval@neptune.tis.com Precedence: bulk Will Fiveash wrote: > I put all the IETF IPSEC drafts in: > > /afs/austin/depts/f13s/projects/ipsec/docs Sorry about the above message. I thought I was sending it to a mail list for some IBMers in Austin that are working on IPSEC. Unfortunately, this AFS cell is not publicly accessible. The lesson for me is that I should try not to do too much in the last 10 minutes of my work-day. -- Will Fiveash IBM AIX System Development Internet: will@austin.ibm.com 11400 Burnet Road, Bld.905/9551 VNET: FIVEASH AT AUSTIN Austin, TX 78758-3493 Phone:(512) 838-7904(off)/3509(fax), T/L 678-7904 Received: from relay.hq.tis.com by neptune.TIS.COM id aa10690; 1 Nov 96 13:55 EST Received: by relay.hq.tis.com; id NAA01437; Fri, 1 Nov 1996 13:59:32 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma001426; Fri, 1 Nov 96 13:59:14 -0500 Received: from london.eu.tis.com (root@london.eu.tis.com [10.217.55.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with ESMTP id OAA10863 for ; Fri, 1 Nov 1996 14:00:53 -0500 (EST) Received: from relay.eu.tis.com (firewall-user@relay.eu.tis.com [10.217.55.100]) by london.eu.tis.com (8.7.3/8.7.3) with ESMTP id SAA27360 for ; Fri, 1 Nov 1996 18:54:06 GMT Received: by relay.eu.tis.com; id OAA00371; Fri, 1 Nov 1996 14:51:18 GMT Received: from zafu.bbn.com(128.89.0.25) by relay.eu.tis.com via smap (V3.1.1) id xma000368; Fri, 1 Nov 96 14:51:01 GMT Received: from [128.89.0.110] (COMSEC.BBN.COM [128.89.0.110]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id NAA28561; Fri, 1 Nov 1996 13:58:15 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 Nov 1996 14:01:50 -0500 To: Hilarie Orman From: Stephen Kent Subject: Re: proposed IPSEC changes/extensions Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hilarie, IP layer compression is definately a separable part of packet processing, but existing implementations of IP stacks do not tend to incoporate such a facility. Since the addition of IP layer encryption strongly motivates the use of compression (at least over dialup links), I think it is not unreasonable to incorporate the compression facility as part of an IPSEC implementation. (If we cause the problem, we can also incorporate the solution?) The resulting protocol could still be an independent module, to facilitate reuse in other contexts, so I'm not so fond of closely tying the compression to any other IPSEC processing, as has been suggested. This leaves the question of whether ESP should have an optional set of fields for compression, or if a separate header should be used. While a separate header is cleaner, and I ma a supported of the "do it right the first time" approach, I know a lot of folks are anxious to have IPSEC deployed, so I can appreciate the motivation for making this another optional part of ESP. Steve Received: from relay.hq.tis.com by neptune.TIS.COM id aa00594; 1 Nov 96 14:21 EST Received: by relay.hq.tis.com; id OAA01915; Fri, 1 Nov 1996 14:11:02 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma001905; Fri, 1 Nov 96 14:10:40 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id OAA11690 for ; Fri, 1 Nov 1996 14:12:22 -0500 (EST) Received: by relay.hq.tis.com; id OAA01892; Fri, 1 Nov 1996 14:10:32 -0500 Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma001876; Fri, 1 Nov 96 14:10:29 -0500 Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id ; Fri, 1 Nov 1996 14:12:22 -0500 Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.7.5/8.6.12) with ESMTP id OAA01596; Fri, 1 Nov 1996 14:12:20 -0500 (EST) Message-Id: <199611011912.OAA01596@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: Santeri Paavolainen Cc: ipsec@TIS.COM Subject: Re: proposed IPSEC changes/extensions In-Reply-To: santtu's message of Fri, 01 Nov 1996 15:24:35 +0200. Date: Fri, 01 Nov 1996 14:12:10 -0500 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk > Even if compression and replay prevention both require state, their state > is separate from each other's state. Compression does not need to know > anything about replay prevention's state to work. Why should they be > defined in the protocol to be contained both in a single > transformation? Both replay prevention and stateful compression require sequence numbering of some sort. Putting two sequence numbers which are stepped identically in a packet is wasteful; it also *potentially* increases the amount of predictable plaintext in a message (a concern which Steve Bellovin has raised on at least one occasion).. - Bill Date: Fri, 1 Nov 1996 16:02:53 -0500 From: Hilarie Orman Message-Id: <199611012102.QAA26649@earth.hpc.org> To: kent@bbn.com Cc: ipsec@TIS.COM In-reply-to: Yourmessage Subject: Re: proposed IPSEC changes/extensions Sender: ipsec-approval@neptune.tis.com Precedence: bulk It's not good to see the design process driven by the perceived difficulty of modifying an old base and the perceived difficulty of getting through standards process. Hilarie Received: from relay.hq.tis.com by neptune.TIS.COM id aa16170; 1 Nov 96 16:46 EST Received: by relay.hq.tis.com; id QAA08533; Fri, 1 Nov 1996 16:50:49 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma008513; Fri, 1 Nov 96 16:50:24 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id QAA27238 for ; Fri, 1 Nov 1996 16:52:08 -0500 (EST) Received: by relay.hq.tis.com; id QAA08494; Fri, 1 Nov 1996 16:50:22 -0500 Received: from volitans.morningstar.com(137.175.2.11) by relay.tis.com via smap (V3.1.1) id xma008486; Fri, 1 Nov 96 16:50:18 -0500 Received: from carp.morningstar.com by volitans.MorningStar.Com (8.7.1/95070701) id QAA21389; Fri, 1 Nov 1996 16:52:11 -0500 (EST) Received: by carp.morningstar.com (8.7.5/95031605) id QAA28551; Fri, 1 Nov 1996 16:53:00 -0500 (EST) Date: Fri, 1 Nov 1996 16:53:00 -0500 (EST) Message-Id: <199611012153.QAA28551@carp.morningstar.com> From: Karl Fox To: Stephen Kent Cc: Hilarie Orman , ipsec@TIS.COM Subject: Re: proposed IPSEC changes/extensions In-Reply-To: References: Reply-To: Karl Fox Organization: Ascend Communications Sender: ipsec-approval@neptune.tis.com Precedence: bulk Stephen Kent writes: > This leaves the question of whether ESP should have an optional set > of fields for compression, or if a separate header should be used. While a > separate header is cleaner, and I ma a supported of the "do it right the > first time" approach, I know a lot of folks are anxious to have IPSEC > deployed, so I can appreciate the motivation for making this another > optional part of ESP. Does the ESP header itself have to deal with compression? Wouldn't it be better to encrypt the compression headers along with the compressed data? -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 Received: from relay.hq.tis.com by neptune.TIS.COM id aa18283; 1 Nov 96 17:07 EST Received: by relay.hq.tis.com; id RAA09339; Fri, 1 Nov 1996 17:11:49 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma009330; Fri, 1 Nov 96 17:11:26 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id RAA28731 for ; Fri, 1 Nov 1996 17:13:06 -0500 (EST) Received: by relay.hq.tis.com; id RAA09322; Fri, 1 Nov 1996 17:11:19 -0500 Received: from capone.ch.apollo.hp.com(15.254.24.3) by relay.tis.com via smap (V3.1.1) id xma009313; Fri, 1 Nov 96 17:11:04 -0500 Received: from thunk.orchard.medford.ma.us (thunk.ch.apollo.hp.com) by capone.ch.apollo.hp.com id ; Fri, 1 Nov 1996 17:12:56 -0500 Received: from thunk (sommerfeld@localhost) by thunk.orchard.medford.ma.us (8.7.5/8.6.12) with ESMTP id RAA01728; Fri, 1 Nov 1996 17:12:54 -0500 (EST) Message-Id: <199611012212.RAA01728@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: pau@watson.ibm.com Cc: kent@bbn.com, ipsec@TIS.COM Subject: Re: proposed IPSEC changes/extensions In-Reply-To: pau's message of Tue, 29 Oct 1996 15:01:34 -0500. <9610292001.AA22994@secpwr.watson.ibm.com> Date: Fri, 01 Nov 1996 17:12:43 -0500 From: Bill Sommerfeld Sender: ipsec-approval@neptune.tis.com Precedence: bulk > C: If "crypto period" or "SA life time" is an SA parameter, should they > be negotiated by key management protocol ? Perhaps as an attribute of a > transform in ISAKMP ? Definitely. the current isakmp-05 draft says: In particular, key lifetimes and SA lifetimes are purely a local issue, and should not be negotiated. I think this is *very* wrong. It means that a receiver can terminate an SA while the sender still thinks its valid... this will set off false alarms when incoming traffic fails to decrypt/verify, and freeze user traffic for several RTT's while the key mgmt protocols try to resynchronize. Very clumsy.. Note that negotiating a lifetime for the SA does *NOT* require synchronized clocks; all it requires is a clock on each end with frequency accurate to within a couple percent. ISAKMP currently handles SA removal with explicit DELETE messages, but it would be more efficient, in general, to let idle SA's expire without the need to send messages (consider demand-dial links .. you probably want the SA to live longer than the demand-dial idle timeout, and it would be silly to bring the link up just to send a DELETE message..). - Bill Received: from [192.94.214.100] by neptune.TIS.COM id aa26824; 1 Nov 96 18:32 EST Received: by relay.hq.tis.com; id SAA11839; Fri, 1 Nov 1996 18:34:19 -0500 From: pau@watson.ibm.com MMDF-Warning: Parse error in original version of preceding line at neptune.TIS.COM Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma011834; Fri, 1 Nov 96 18:33:51 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id SAA02266 for ; Fri, 1 Nov 1996 18:35:34 -0500 (EST) Received: by relay.hq.tis.com; id SAA11829; Fri, 1 Nov 1996 18:33:49 -0500 Received: from igw3.watson.ibm.com(129.34.139.18) by relay.tis.com via smap (V3.1.1) id xma011823; Fri, 1 Nov 96 18:33:31 -0500 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id SAA15810; Fri, 1 Nov 1996 18:34:06 -0500 Received: from secpwr.watson.ibm.com (secpwr.watson.ibm.com [9.2.24.17]) by mailhub1.watson.ibm.com (8.7.1/10-26-96) with SMTP id SAA619160; Fri, 1 Nov 1996 18:33:52 -0500 Received: by secpwr.watson.ibm.com (AIX 4.1/UCB 5.64/4.03) id AA21500; Fri, 1 Nov 1996 18:36:04 -0500 Date: Fri, 1 Nov 1996 18:36:04 -0500 Message-Id: <9611012336.AA21500@secpwr.watson.ibm.com> To: sommerfeld@apollo.hp.com Subject: Re: proposed IPSEC changes/extensions Cc: kent@bbn.com, ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Md5: qNk/ueaLgIvmWzYDKnZf6A== Sender: ipsec-approval@neptune.tis.com Precedence: bulk In msg <199611012212.RAA01728@thunk.orchard.medford.ma.us> Bill Sommerfeld Wrote: >=20 > > C: If "crypto period" or "SA life time" is an SA parameter, should = they > > be negotiated by key management protocol ? Perhaps as an = attribute of a > > transform in ISAKMP ? >=20 > Definitely. the current isakmp-05 draft says: >=20 > In particular, key lifetimes and SA lifetimes are purely a local > issue, and should not be negotiated. >=20 > I think this is *very* wrong. It means that a receiver can terminate > an SA while the sender still thinks its valid... this will set off > false alarms when incoming traffic fails to decrypt/verify, and freeze > user traffic for several RTT's while the key mgmt protocols try to > resynchronize. Very clumsy.. >=20 > Note that negotiating a lifetime for the SA does *NOT* require > synchronized clocks; all it requires is a clock on each end with > frequency accurate to within a couple percent. Completely agree.=20 >=20 > ISAKMP currently handles SA removal with explicit DELETE messages, but > it would be more efficient, in general, to let idle SA's expire > without the need to send messages (consider demand-dial links .. you > probably want the SA to live longer than the demand-dial idle timeout, > and it would be silly to bring the link up just to send a DELETE > message..). >=20 > - Bill > Yes. our experience shows that if life time is negotiated and the clocks on the two sides have reasonable accuracy (I would say accurate to = seconds is good enough.), then no explicit DELETE msg is needed, just refresh = the key near (but before) its expiration. This has been implemented and used on IBM firewall, it seems to work pretty well. Of course, if no further communication is needed, we can just let the SA (key) expire. As far as I can see, the only case needs special care is if the key's life time is pretty long and the user/system wish to terminate the SA long before the key expires. So DELETE msg may needed in this special case. But if the life time is set to be so long, maybe the user/system does not care that much anyway. Pau-Chen Received: from relay.hq.tis.com by neptune.TIS.COM id aa18282; 3 Nov 96 12:37 EST Received: by relay.hq.tis.com; id MAA24417; Sun, 3 Nov 1996 12:42:23 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma024413; Sun, 3 Nov 96 12:41:55 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id MAA18437 for ; Sun, 3 Nov 1996 12:43:35 -0500 (EST) Received: by relay.hq.tis.com; id MAA24405; Sun, 3 Nov 1996 12:41:53 -0500 Received: from mail.zipnet.net(199.232.240.10) by relay.tis.com via smap (V3.1.1) id xma024401; Sun, 3 Nov 96 12:41:24 -0500 Received: from ferguson ([199.249.254.9]) by mail.zipnet.net (8.7.6/8.7.3) with SMTP id MAA21634; Sun, 3 Nov 1996 12:43:15 -0500 (EST) Message-Id: <2.2.16.19961103174036.0bd73814@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 2.2 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 03 Nov 1996 12:40:36 -0500 To: ipsec@TIS.COM From: Rodney Thayer Subject: Re: proposed IPSEC changes/extensions Cc: msabin@netcom.com Sender: ipsec-approval@neptune.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- That was my view, which is why I proposed it as a separate transform. I believe the different points of view have to do with the use of history-based or non-history-based compression. It is my opinion that both schemes have a place. I sort of see things evolving from use of a separate transform or protocol, towards some sort of combined mechanism. I assume that eventually the transforms actually used in the real world will be optimized for combined functions such as the 3des-compression-replay-etc. transform. >Date: Thu, 31 Oct 1996 09:50:25 -0500 >From: Hilarie Orman >To: msabin@netcom.com >Cc: ipsec@TIS.COM >Subject: Re: proposed IPSEC changes/extensions >Sender: ipsec-approval@neptune.hq.tis.com > >> 2) Compression is stateful, which means that the transmitter and receiver >> can get out of sync if packets are missed. > >Isn't stateful compression is most logically done as a separate >protocol, performed prior to any IPSEC encryption? -----BEGIN PGP SIGNATURE----- Version: 4.0 Business Edition Comment: PGP by ViaCrypt iQCVAgUBMnzT2cKmlvJNktGxAQGrZAP8CWC8JqC80/Sire6f9OYiibM2H2JVnFMc 1LvLR/y2RjZyCKIb2ppEVm3QJ9eBXbJjNwwWDReQmton0Ei73IB5ZAPL3sue7An8 WjZWks3k2U1CT2on9Z5WomJJKy4tLvyYgsJUYHGjcn+6fNpXtohgiSEnpIC0NCjt JE/stO4Nbzg= =WY44 -----END PGP SIGNATURE----- Rodney Thayer +1 617 332 7292 Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA Fax: +1 617 332 7970 http://www.shore.net/~sable Communications Software Development Date: Fri, 1 Nov 1996 16:02:53 -0500 From: Hilarie Orman Message-Id: <199611012102.QAA26649@earth.hpc.org> To: kent@bbn.com Cc: ipsec@TIS.COM In-reply-to: Yourmessage Subject: Re: proposed IPSEC changes/extensions Sender: ipsec-approval@neptune.tis.com Precedence: bulk It's not good to see the design process driven by the perceived difficulty of modifying an old base and the perceived difficulty of getting through standards process. Hilarie To: Hilarie Orman cc: kent@bbn.com, ipsec@TIS.COM Subject: Re: proposed IPSEC changes/extensions Date: Fri, 01 Nov 1996 20:44:58 -0500 From: Steven Bellovin Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9611040742.aa27436@neptune.TIS.COM> It's not good to see the design process driven by the perceived difficulty of modifying an old base and the perceived difficulty of getting through standards process. I'd intended to wait a few days before posting this, but... The issue isn't one of process. Rather, it's what we know how to do. We know (or think we know) how to build ESP and AH. Many of us have a few qualms about pieces of the spec, but they're not worth revisiting anymore -- we have a spec and it works. I'm much less sanguine that we know how to do compression. We don't have a spec (or rather, if we do have one, I couldn't find it; the best I found was draft-thayer-seccomp-00.txt, and it referenced a BoF for technical details), and there are some obvious technical details in implementing compression over a lossy medium such as IP. Yes, there's a requirement for a resync bit -- but does that imply a need for compression-level NAK packets, to say that something was dropped, and that we need to resync? (Possibly all of these objections have been dealt with in the technical draft -- I haven't seen it, which is why I had wanted to wait.) My estimate is that it will take about a year before we have a clean spec for compression, independent of the standards process. I don't want to wait until then to start deploying IPSEC. Nor am I convinced that we know what fields to add now to the ESP header, to leave room for compression. The question of one versus two sequence numbers is mostly irrelevant. Even if we have only one, there's no reason why ESP cannot pass the value to the decompressor. That's a matter of interface design -- and if we so choose, we will impose a new requirement on the interface. It isn't clear that an additional sequence number would add more probable plaintext. If the starting point was random, you'd need a two-packet attack to start. And looking at the draft I cited, I'd say that at least 44 bits of the remaining 48 are predictable for a simpler single-packet attack. (The sequence number field is 16 bits in that draft.) I'd also want to look at what the beginning of the compressed packet looked like. Date: Sun, 3 Nov 1996 18:18:54 -0800 From: Ran Atkinson Message-Id: <199611040218.SAA15844@cornpuffs.cisco.com> To: sommerfeld@apollo.hp.com Subject: Re: proposed IPSEC changes/extensions In-Reply-To: <199611012212.RAA01728@thunk.orchard.medford.ma.us> References: <9610292001.AA22994@secpwr.watson.ibm.com> Organization: cisco Systems Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk In article <199611012212.RAA01728@thunk.orchard.medford.ma.us>, Bill Sommerfeld wrote: >Definitely. the current isakmp-05 draft says: > > In particular, key lifetimes and SA lifetimes are purely a local > issue, and should not be negotiated. > >I think this is *very* wrong. It means that a receiver can terminate >an SA while the sender still thinks its valid... this will set off >false alarms when incoming traffic fails to decrypt/verify, and freeze >user traffic for several RTT's while the key mgmt protocols try to >resynchronize. Very clumsy.. I agree with Bill on this. The next ISAKMP draft should provide specific support for negotiating soft and hard SA lifetimes. >ISAKMP currently handles SA removal with explicit DELETE messages, but >it would be more efficient, in general, to let idle SA's expire >without the need to send messages (consider demand-dial links .. you >probably want the SA to live longer than the demand-dial idle timeout, >and it would be silly to bring the link up just to send a DELETE >message..). Yes, though the DELETE message is useful in other cases (e.g. one side believes the SA to be compromised and wants to ensure the other side does not use that SA any longer). Ran rja@cisco.com Date: Mon, 4 Nov 1996 13:18:45 +0200 (EET) From: Santeri Paavolainen To: ipsec@TIS.COM Subject: Re: proposed IPSEC changes/extensions In-Reply-To: <199611011912.OAA01596@thunk.orchard.medford.ma.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipsec-approval@neptune.tis.com Precedence: bulk On Fri, 1 Nov 1996, Bill Sommerfeld wrote: > > Even if compression and replay prevention both require state, their state > > is separate from each other's state. Compression does not need to know > > anything about replay prevention's state to work. Why should they be > > defined in the protocol to be contained both in a single > > transformation? > > Both replay prevention and stateful compression require sequence > numbering of some sort. Putting two sequence numbers which are > stepped identically in a packet is wasteful; it also *potentially* > increases the amount of predictable plaintext in a message (a concern > which Steve Bellovin has raised on at least one occasion).. Still I do not count such synergy to be good enough reason to include both of them in a single transformation. Also all the ciphers must themselves somehow address known-plaintext attacks, and I would not combine replay prevention and combination just on the basis of "common sequence number". I object to any transformation whose behaviour can be changed on anything else that counts as a "key". If the compression part of this mega-transformation is optional it should be defined as a separate transformation which can be optionally applied or not. We should not except that the only application of IPSEC is critically secure data links -- a large portion of traffic containet withing IPSEC will be non-confidential TCP traffic. TCP is inherently safe from replay prevention, and no cryptographic security is needed. The only item of interest is authentication, eg. tamperproof connections. These would probably also benefit from compression. We can either define a single huge transformation with a lot of options: CRYPTO-HASH-REPLAYPREVENTION-COMPRESS (crypto, hash, replayprevention and compression all optional) or a lot of smaller transformations CRYPTO HASH REPLAYPREVENTION and COMPRESS and apply them layer by layer in any such combination we deem necessary. Notice that is the mega-transformation uses any component which fails, such as MD5 instead of SHA, the whole specification has to be changed. With multiple component transformations one can tailor the whole combination to their needs. That is, for a regular WWW page access the user is mostly interested that the data that is sent is the same data they receive, thus just the HASH transformation is necessary (TCP has its own state). Anything more would be overkill. Thus to satisfy all the possible needs we would have to specify all the sub-components of the mega-transformation as a separate pieces anyway. So do what is the need for such mega-transformation in the first place if we can have the same effect by combining smaller transformations? I say there is no need. The issues about implementation efficiency are just that, an implementation issue. I am not advocating for us to draft "bad" specifications that would make efficient implementations impossible, but I do not either want to be hindered by only considering the efficiency issues. There is the problem of known-plaintext in layered transformations. We should always consider SPI as known plaintext (it could be obtained by breaking the key management traffic, for example), thus if we do AH<-CRYPT<-COMPRESS for example we in effect supply at least 8 bytes of known plaintext for the cryptanalyst for breaking the CRYPT portion of such combined transformation. On the other hand - none of the cryptographic methods used should except "good" input, eg. such that is inherently unguessable. I am saying that any cryptographic transformation falling on these 8 bytes of known plaintext is unusable in the first place. If we are using IPSEC in a tunnel mode, the IP header itself offers a much better target than any compression or other transformation header anyway. If we are so concerned about security, we should not include the COMPRESS transformation in the first place (with a change of views: we should, as it increases entropy per byte). Or apply a stronger cipher. What good is of an IV, anyway? :-) -- sjpaavol@cc.Helsinki.FI I have become death, destroyer of the worlds. Received: from relay.hq.tis.com by neptune.TIS.COM id aa04340; 4 Nov 96 8:44 EST Received: by relay.hq.tis.com; id IAA02883; Mon, 4 Nov 1996 08:49:02 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma002881; Mon, 4 Nov 96 08:48:43 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id IAA03147 for ; Mon, 4 Nov 1996 08:50:17 -0500 (EST) Received: by relay.hq.tis.com; id IAA02863; Mon, 4 Nov 1996 08:48:35 -0500 Received: from volitans.morningstar.com(137.175.2.11) by relay.tis.com via smap (V3.1.1) id xma002852; Mon, 4 Nov 96 08:48:08 -0500 Received: from carp.morningstar.com by volitans.MorningStar.Com (8.7.1/95070701) id IAA13788; Mon, 4 Nov 1996 08:50:00 -0500 (EST) Received: by carp.morningstar.com (8.7.5/95031605) id IAA01459; Mon, 4 Nov 1996 08:51:09 -0500 (EST) Date: Mon, 4 Nov 1996 08:51:09 -0500 (EST) Message-Id: <199611041351.IAA01459@carp.morningstar.com> From: Karl Fox To: Steven Bellovin Cc: Hilarie Orman , kent@bbn.com, ipsec@TIS.COM Subject: Re: proposed IPSEC changes/extensions In-Reply-To: <9611040742.aa27436@neptune.TIS.COM> References: <9611040742.aa27436@neptune.TIS.COM> Reply-To: Karl Fox Organization: Ascend Communications Sender: ipsec-approval@neptune.tis.com Precedence: bulk Steven Bellovin writes: > Yes, there's a requirement for a resync bit -- but does that imply > a need for compression-level NAK packets, to say that something was > dropped, and that we need to resync? Feedback in compression isn't always necessary. There's always the `reset-every-n-packets' method. > My estimate is that it will take about a year before we have a clean > spec for compression, independent of the standards process. I don't > want to wait until then to start deploying IPSEC. I agree completely. > Nor am I convinced that we know what fields to add now to the ESP > header, to leave room for compression. I disagree--I don't think any compression fields belong in the ESP header. As I've said before (with no comment from others), I think all compression header fields should be encrypted, and should be as small as possible to reduce the amount of guessable plaintext. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 Received: from relay.hq.tis.com by neptune.TIS.COM id aa07283; 4 Nov 96 9:12 EST Received: by relay.hq.tis.com; id JAA03663; Mon, 4 Nov 1996 09:17:03 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma003655; Mon, 4 Nov 96 09:16:39 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id JAA04994 for ; Mon, 4 Nov 1996 09:18:14 -0500 (EST) Received: by relay.hq.tis.com; id JAA03646; Mon, 4 Nov 1996 09:16:33 -0500 Received: from ercole.cefriel.it(131.175.5.10) by relay.tis.com via smap (V3.1.1) id xma003596; Mon, 4 Nov 96 09:16:07 -0500 Received: from espo.cefriel.it ([131.175.4.136]) by ercole.cefriel.it (8.7.5/8.7.3) with SMTP id PAA14622 for ; Mon, 4 Nov 1996 15:13:22 +0100 (MET) Message-Id: <2.2.32.19961104141339.0068bdbc@mailer.cefriel.it> X-Sender: esposito@mailer.cefriel.it X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 04 Nov 1996 15:13:39 +0100 To: ipsec@TIS.COM From: Sergio Esposito Subject: IPsec implementations Sender: ipsec-approval@neptune.tis.com Precedence: bulk Hi, are there free downloadable IPSec implementations for Solaris that are available outside the U.S.? Thanks in advance for your kind response, Sergio Esposito ============================================================================ Organization : CEFRIEL Address : Via Emanueli, 15 - 20126 MILANO (Italy) Phone : +39-2-66161.211 / +39-2-66161.1 FAX : +39-2-66161.448 Interests : IPv6, IPSec, VPN e-mail : esposito@mailer.cefriel.it www : ============ Received: from relay.hq.tis.com by neptune.TIS.COM id aa14526; 4 Nov 96 10:22 EST Received: by relay.hq.tis.com; id KAA06695; Mon, 4 Nov 1996 10:27:05 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma006677; Mon, 4 Nov 96 10:26:43 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id KAA12959 for ; Mon, 4 Nov 1996 10:28:17 -0500 (EST) Received: by relay.hq.tis.com; id KAA06648; Mon, 4 Nov 1996 10:26:35 -0500 Received: from border.com(199.71.190.98) by relay.tis.com via smap (V3.1.1) id xma006565; Mon, 4 Nov 96 10:26:12 -0500 Received: by janus.border.com id <18438-2>; Mon, 4 Nov 1996 10:25:29 -0500 Message-Id: <96Nov4.102529est.18438-2@janus.border.com> To: Hilarie Orman MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM cc: kent@bbn.com, ipsec@TIS.COM Subject: Re: proposed IPSEC changes/extensions References: <199611012102.QAA26649@earth.hpc.org> In-reply-to: ho's message of "Fri, 01 Nov 1996 16:02:53 -0500". <199611012102.QAA26649@earth.hpc.org> From: "C. Harald Koch" MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Organization: Secure Computing Canada Ltd. Phone: +1 416 368 7157 X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Mon, 4 Nov 1996 10:25:57 -0500 Sender: ipsec-approval@neptune.tis.com Precedence: bulk In message <199611012102.QAA26649@earth.hpc.org>, Hilarie Orman writes: > It's not good to see the design process driven by the perceived difficulty > of modifying an old base and the perceived difficulty of getting through > standards process. A standard that no-one adopts is worse than no standard at all. -- C. Harald Koch chk@border.com Received: from relay.hq.tis.com by neptune.TIS.COM id aa15779; 4 Nov 96 10:35 EST Received: by relay.hq.tis.com; id KAA07454; Mon, 4 Nov 1996 10:40:06 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma007435; Mon, 4 Nov 96 10:39:44 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id KAA13747 for ; Mon, 4 Nov 1996 10:41:22 -0500 (EST) Received: by relay.hq.tis.com; id KAA07396; Mon, 4 Nov 1996 10:39:37 -0500 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma007390; Mon, 4 Nov 96 10:39:30 -0500 Received: from [128.89.0.110] (COMSEC.BBN.COM [128.89.0.110]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id KAA20281 for ; Mon, 4 Nov 1996 10:41:29 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 4 Nov 1996 10:43:07 -0500 To: ipsec@TIS.COM From: Stephen Kent Subject: Re: proposed IPSEC changes/extensions Sender: ipsec-approval@neptune.tis.com Precedence: bulk Folks, I think the concensus is that we should NOT include compression in ESP, for a bariety of reasons. So, the revised ESP document will not include ANY hooks for compression, reserved fields, etc. Note, however, that we are moving away from the notion of transforms as bundled sets of algorithms described in a single document. Instead, we are defining the algorithms separately, and the notion of a transform will appear only in a document that describes the combinations of algorithms that are negotiated during SA establishment. It will cite these algorithms by reference to appropriate RFCs, but wil not provide processing descriptions, etc. Thus I do not see how to include compression into ESP processing at some later time. If we keep it as a separate protocol, that's fine, but don't count on some more optimized version that is tightly integrated into ESP. Steve Received: from relay.hq.tis.com by neptune.TIS.COM id aa15910; 4 Nov 96 10:37 EST Received: by relay.hq.tis.com; id KAA07556; Mon, 4 Nov 1996 10:41:36 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma007550; Mon, 4 Nov 96 10:41:15 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id KAA13902 for ; Mon, 4 Nov 1996 10:42:49 -0500 (EST) Received: by relay.hq.tis.com; id KAA07523; Mon, 4 Nov 1996 10:41:07 -0500 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma007490; Mon, 4 Nov 96 10:40:39 -0500 Received: from [128.89.0.110] (COMSEC.BBN.COM [128.89.0.110]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id KAA20291; Mon, 4 Nov 1996 10:41:32 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 4 Nov 1996 10:43:11 -0500 To: Karl Fox From: Stephen Kent Subject: Re: proposed IPSEC changes/extensions Cc: Steven Bellovin , Hilarie Orman , ipsec@TIS.COM MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Karl, I think the imprortance of reducing guessable plaintext introduced by fixed (guessable) headres is sometimes overstated. Let's just work on designing the protocols to work correctly and assume that the crypto will be secure under assumptions of known (and chosen) plaintext attacks. This is a sufficiently hard task. Steve Date: Mon, 04 Nov 1996 10:20:54 -0800 To: Santeri Paavolainen From: Bob Monsour Subject: Re: proposed IPSEC changes/extensions Cc: ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9611041337.aa03289@neptune.TIS.COM> At 03:24 PM 11/1/96 +0200, Santeri Paavolainen wrote: >On Thu, 31 Oct 1996, Bill Sommerfeld wrote: >> > Isn't stateful compression most logically done as a separate >> > protocol, performed prior to any IPSEC encryption? >> >> Maybe from a "purity of layers" perspective, but stateful compression >> requires similar message-sequencing goop as replay detection; there >> are likely some real efficiencies from handling both at the same >> time.. > >True, but unless there is a good reason to put both of them into a single >transformation they should be kept separate. Recall that the reason that the replay prevention counter was originally suggested to be used as the compression sequence number was due to the draft which combined compression with 3DES, replay prevenion and HMAC as a single defined (and singly documented) transform. Unfortunate as the timing was, that draft was posted just as the requirement to reduce all the specific transforms, i.e., 3DES, HMAC, compression, etc., to separate documents and having the ESP draft accommodate each of them so as to avoid transform explosion. There is clearly no specific need, nor requirement, to combine the use of those two sequence numbers. FYI, the draft that combined those functions was announced as follows: Title : Combined 3DES-CBC, LZS Compression, HMAC, and Replay Prevention ESP Transform Author(s) : M. Sabin, R. Monsour Filename : draft-sabin-esp-des3-lzs-md5-00.txt Pages : 18 Date : 10/23/1996 This document proposes the "3DES-CBC-LZS-HMAC-Replay" security transform for the IP Encapsulating Security Payload (ESP). The proposed transform combines triple-DES encryption, LZS compression, HMAC authentication, and replay prevention into a single packet format. The transform is compatible with implementations that do not support compression and with implementations that support only single-DES encryption. Compression is performed prior to encryption, which has the side benefit of reducing the amount of data that must be encrypted. This document is based on the IPsec Working Group's proposed "Combined DES-CBC, HMAC, and Replay Prevention Security Transform," cited later in this document. Bob Monsour rmonsour@earthlink.net Date: Mon, 04 Nov 1996 10:28:14 -0800 To: Karl Fox From: Bob Monsour Subject: Re: proposed IPSEC changes/extensions Cc: Stephen Kent , Hilarie Orman , ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9611041338.aa03372@neptune.TIS.COM> At 04:53 PM 11/1/96 -0500, Karl Fox wrote: >Does the ESP header itself have to deal with compression? Wouldn't it >be better to encrypt the compression headers along with the compressed >data? In our draft (draft-sabin-esp-des3-lzs-md5-00.txt), all of the compression-specific fields are encrypted. We would suggest that regardless of the method of documenting the compression fields (as part of ESP), it should not result in those fields being unencrypted. While the transforms will wind up being documented separately and accommodated within the ESP definition, the bytes of the data stream should be no different from the case where they are documented together. Bob Monsour rmonsour@earthlink.net Date: Mon, 04 Nov 1996 10:41:05 -0800 To: Stephen Kent From: Bob Monsour Subject: Re: proposed IPSEC changes/extensions Cc: Hilarie Orman , ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9611041357.aa05278@neptune.TIS.COM> At 02:01 PM 11/1/96 -0500, Stephen Kent wrote: >Since the addition of IP layer encryption >strongly motivates the use of compression (at least over dialup links), I >think it is not unreasonable to incorporate the compression facility as >part of an IPSEC implementation. Steve, this goes way beyond dial-up links. The effective use of compression on T1 links saves companies thousands of dollars per month. >The resulting protocol could still be an >independent module, to facilitate reuse in other contexts, so I'm not so >fond of closely tying the compression to any other IPSEC processing, as has >been suggested. That is correct. There is no need to intimately tie the processing together. Compression can be defined in such a way to make it a straightforward IPSec implementation option (one that would be negotiated and be specified as an SA attribute). > This leaves the question of whether ESP should have an optional set >of fields for compression, or if a separate header should be used. While a >separate header is cleaner, and I ma a supported of the "do it right the >first time" approach, I know a lot of folks are anxious to have IPSEC >deployed, so I can appreciate the motivation for making this another >optional part of ESP. I could go either way on this, but my feeling is that it is more natural to include support for compression within ESP itself as it is best employed in the context of encrypted packets. As a separate header, while it is perhaps cleaner, its use only really makes sense when encrypting since in the absence of encryption, compression will be performed at the PPP level. Bob Monsour rmonsour@earthlink.net Date: Mon, 04 Nov 1996 10:49:00 -0800 To: Steven Bellovin From: Bob Monsour Subject: Re: proposed IPSEC changes/extensions Cc: Hilarie Orman , kent@bbn.com, ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9611041359.aa05438@neptune.TIS.COM> At 08:44 PM 11/1/96 -0500, Steven Bellovin wrote: >I'm much less sanguine that we know how to do compression. We don't >have a spec (or rather, if we do have one, I couldn't find it; the >best I found was draft-thayer-seccomp-00.txt, and it referenced a >BoF for technical details), and there are some obvious technical >details in implementing compression over a lossy medium such as IP. Steve, see the following: Title : Combined 3DES-CBC, LZS Compression, HMAC, and Replay Prevention ESP Transform Author(s) : M. Sabin, R. Monsour Filename : draft-sabin-esp-des3-lzs-md5-00.txt Pages : 18 Date : 10/23/1996 This document proposes the "3DES-CBC-LZS-HMAC-Replay" security transform for the IP Encapsulating Security Payload (ESP). The proposed transform combines triple-DES encryption, LZS compression, HMAC authentication, and replay prevention into a single packet format. The transform is compatible with implementations that do not support compression and with implementations that support only single-DES encryption. Compression is performed prior to encryption, which has the side benefit of reducing the amount of data that must be encrypted. This document is based on the IPsec Working Group's proposed "Combined DES-CBC, HMAC, and Replay Prevention Security Transform," cited later in this document. >My estimate is that it will take about a year before we have a clean >spec for compression, independent of the standards process. I don't >want to wait until then to start deploying IPSEC. Nor am I convinced >that we know what fields to add now to the ESP header, to leave room >for compression. I disagree. Compression has been widely deployed at the data link (PPP) layer, and although that is a connection-oriented mechanism, there is certainly no black magic in terms of what is needed to deal with it. In addition to the two fields which Mike Sabin described in an earlier email (excerpted below), you would need to add one additional field to indicate the "flavor" of compression to be employed. The reason that this was no included in our draft was that the draft was LZS compression-specific. On Tuesday, October 29, 1996, Mike Sabin wrote: >Compression is greatly helped by including a field that controls two >functions: (1) whether or not the contents of the packet are compressed; >and (2) whether or not the compression state was reset prior to this packet. >Here is why: > >1) Compressing a packet sometimes actually expands its contents. This is >most common with short packets. When expansion occurs, it is better to send >the uncompressed version of the packet. This requires each packet to have a >bit that identifies the packet as compressed or not. > >2) Compression is stateful, which means that the transmitter and receiver >can get out of sync if packets are missed. To deal with this, the >transmitter frequently resets its compression state to a known starting >value, allowing an out-of-sync receiver to resync. A convenient way to >accommodate this is to include a bit in each packet that indicates whether >or not the compression state was reset prior to compressing this packet. > I hope this addresses your concerns. Bob Monsour rmonsour@earthlink.net Date: Mon, 04 Nov 1996 10:56:17 -0800 To: Stephen Kent From: Bob Monsour Subject: Re: proposed IPSEC changes/extensions Cc: ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9611041400.aa05549@neptune.TIS.COM> At 10:43 AM 11/4/96 -0500, Stephen Kent wrote: > I think the concensus is that we should NOT include compression in >ESP, for a bariety of reasons. So, the revised ESP document will not >include ANY hooks for compression, reserved fields, etc. Note, however, >that we are moving away from the notion of transforms as bundled sets of >algorithms described in a single document. Instead, we are defining the >algorithms separately, and the notion of a transform will appear only in a >document that describes the combinations of algorithms that are negotiated >during SA establishment. It will cite these algorithms by reference to >appropriate RFCs, but wil not provide processing descriptions, etc. Thus I >do not see how to include compression into ESP processing at some later >time. If we keep it as a separate protocol, that's fine, but don't count >on some more optimized version that is tightly integrated into ESP. Steve, with all due respect, I don't believe that the arguments posed to date imply concensus against the inclusion of compression in ESP. I was out of town most of last week and was not in email contact. This morning I caught up and provided answers to all of the posted objections. I think it's too soon to dismiss this. I would like to hear from any of the list members of the user community or from others who are either contemplating the use of compression or see the value in having a standard method for combining the two functions wihtin the context of ESP. Comments? Bob Monsour rmonsour@earthlink.net To: Karl Fox From: Michael Sabin Subject: Re: proposed IPSEC changes/extensions Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Date: Mon, 4 Nov 96 14:17:09 EST Message-ID: <9611041417.aa07145@neptune.TIS.COM> At 01:51 PM 11/4/96 +0000, Karl Fox wrote: >I disagree--I don't think any compression fields belong in the ESP >header. As I've said before (with no comment from others), I think >all compression header fields should be encrypted, and should be as >small as possible to reduce the amount of guessable plaintext. I think we all agree that compression header fields should be encrypted. This would be true for both cases being discussed: compression as a separate transform, encapsulated within the ESP payload; or compression as part of the ESP transform, with compression fields among the encrypted part of the ESP header. Received: from relay.hq.tis.com by neptune.TIS.COM id aa18506; 4 Nov 96 16:06 EST Received: by relay.hq.tis.com; id QAA22007; Mon, 4 Nov 1996 16:11:00 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma021959; Mon, 4 Nov 96 16:10:31 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id QAA11003 for ; Mon, 4 Nov 1996 16:12:09 -0500 (EST) Received: by relay.hq.tis.com; id QAA21946; Mon, 4 Nov 1996 16:10:29 -0500 Received: from zafu.bbn.com(128.89.0.25) by relay.tis.com via smap (V3.1.1) id xma021926; Mon, 4 Nov 96 16:10:10 -0500 Received: from [128.89.0.110] (COMSEC.BBN.COM [128.89.0.110]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id QAA28334; Mon, 4 Nov 1996 16:12:02 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 4 Nov 1996 16:13:44 -0500 To: Bob Monsour From: Stephen Kent Subject: Re: proposed IPSEC changes/extensions Cc: ipsec@TIS.COM Sender: ipsec-approval@neptune.tis.com Precedence: bulk Bob, I sent my message prior to receiving any of your responses this morning; sorry if I may have jumped the gun! The group needs to decide if we are going to try to get compression, maybe just a place holder for compression, into ESP at this juncture. One of your messages from earlier today argued that there is generic utility for IP-layer compression, independent of ESP. This might argue for a separate protocol, rather than an ESP-specific instance of a generic protocol. I'm really quite neutral here; if there is agreement that providing for compression in ESP (vs. a separate protocol) is a good idea, I'll put in the hooks for it as specified by those of you who have been working the problem. One the other hand, I do see both the concern over delaying ESP to add in the requisite hooks, or the delay associated with introducing a new compression protocol for use at the IP layer, independent of ESP. Both arguments have merit. Steve Received: from relay.hq.tis.com by neptune.TIS.COM id aa21699; 4 Nov 96 16:39 EST Received: by relay.hq.tis.com; id QAA24168; Mon, 4 Nov 1996 16:44:00 -0500 Received: from clipper.hq.tis.com(10.33.1.2) by relay.tis.com via smap (V3.1.1) id xma024162; Mon, 4 Nov 96 16:43:32 -0500 Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id QAA12569 for ; Mon, 4 Nov 1996 16:45:09 -0500 (EST) Received: by relay.hq.tis.com; id QAA24154; Mon, 4 Nov 1996 16:43:30 -0500 Received: from greece-c.it.earthlink.net(204.250.46.38) by relay.tis.com via smap (V3.1.1) id xma024144; Mon, 4 Nov 96 16:43:10 -0500 Received: from papa (max5-wc-ca-21.earthlink.net [206.149.209.71]) by greece.it.earthlink.net (8.7.5/8.7.3) with SMTP id NAA04998; Mon, 4 Nov 1996 13:44:35 -0800 (PST) Message-Id: <3.0b36.32.19961104134444.00963100@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0b36 (32) Date: Mon, 04 Nov 1996 13:44:52 -0800 To: Stephen Kent From: Bob Monsour Subject: Re: proposed IPSEC changes/extensions Cc: Bob Monsour , ipsec@TIS.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: ipsec-approval@neptune.tis.com Precedence: bulk At 04:13 PM 11/4/96 -0500, Stephen Kent wrote: >...if there is agreement that providing for compression in ESP (vs. a >separate protocol) is a good idea, I'll put in the hooks for it as >specified by those of you who have been working the problem. Steve, I've done some chatting with others working the problem. We believe that we've come up with a way to accommodate compression within ESP with minimal impact and overhead on the ESP draft (smiles erupt here). What we propose is that the ESP draft simply state that compression is one of the negotiable security association attributes (which I realize will ultimately be negotiated by whatever KMP is employed; the ISAKMP draft already includes support for turning on compression and specifying the algorithm). In addition, the ESP draft would state that when the optional compression is implemented, it is performed prior to encryption. I would suggest that the appropriate language be added to the descriptions of the "sender" and "receiver" operations in the tunnel-mode and transport-mode descriptions (sections 4.1 and 4.2 of the June 6 draft). That simple mechanism would allow for the creation of one or more separate compression transform descriptions (one for each compression algorithm) which would include the format for the compressed data, as well as the description of any compression-specific fields (such as bits for compressed/uncompressed and history reset). In the case where a particular SPI specifies NOT using a replay prevention counter, the compression transform would include a sequence counter (perhaps only 16 bits) to provide the capability for handling out of order packets. For example, the resulting ESP syntax, when using 3DES and HMAC and reply prevention would look as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- | Security Parameters Index (SPI) | ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Initialization Vector (optional) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | --- | Replay Prevention Field (count) | | ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | |HMAC | | Payload Data (compressed or uncompressed) | | | | | | | | +-+-+-+-+-+-+-+-| | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 3DES | Padding (0-7 bytes) | | CBC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Pad Length | Payload Type | v | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--- | | | | | HMAC digest | | | | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- I am hopeful that this solution provides the group with both the ability to keep the door open on the compression topic as well as the flexibility for defining compression transforms which, like encryption, will change over time to meet differing operational requirements. We are planning to develop an LZS informational draft in the form suggested prior to the 11/26 ID cutoff date. Lastly, while it may appear that compression should be orthogonal to security considerations, it is important to note that in the absence of the implementation of encryption, compression is already provided for at the data link layer (PPP). It is exactly the incorporation of security that drives the need to also include compression so as to maintain the bandwidth gains already achieved for today's network user. Comments are welcome. Bob Monsour rmonsour@earthlink.net To: ipsec@TIS.COM Path: not-for-mail From: David Wagner Newsgroups: isaac.lists.ipsec Subject: Re: proposed IPSEC changes/extensions Date: 4 Nov 1996 21:58:00 -0800 Organization: ISAAC Group, UC Berkeley Lines: 25 Message-ID: <55ml18$9pk@joseph.cs.berkeley.edu> References: <199611011912.OAA01596@thunk.orchard.medford.ma.us> Sender: ipsec-approval@neptune.tis.com Precedence: bulk [Apologies if I'm covering old, familiar ground again:] In article , Santeri Paavolainen wrote: > TCP is inherently safe > from replay prevention, and no cryptographic security is needed. The > only item of interest is authentication, eg. tamperproof connections. I disagree. TCP still needs replay protection. For one thing, TCP sequence numbers were designed for robustness against long-lived packets and network errors, not against adversaries. TCP sequence numbers can easily wrap around (and they do in some applications). Once they wrap, you're vulnerable to replays. Also, when host-pair keying is in effect, and one host has mutually distrustful users, TCP probably needs replay protection, lest one of Bellovin's attacks compromise confidentiality. (Alice binds to port 1234, receives some traffic, disconnects; Bob then binds to port 1234, replays the old traffic, and receives the decryption of Alice's data.) Who knows -- there may be other attacks, too. I say, for robustness, and for security against known attacks, TCP does need replay protection. Anyhow, maybe this doesn't change your main point. Just a nitpick. To: Stephen Kent MMDF-Warning: Unable to confirm address in preceding line at neptune.TIS.COM Cc: Karl Fox , Steven Bellovin , Hilarie Orman , ipsec@TIS.COM Subject: Re: proposed IPSEC changes/extensions In-Reply-To: Date: Mon, 04 Nov 1996 20:15:07 -0800 From: John Gilmore Sender: ipsec-approval@neptune.tis.com Precedence: bulk Message-ID: <9611050729.aa05541@neptune.TIS.COM> > Let's just work on > designing the protocols to work correctly and assume that the crypto will > be secure under assumptions of known (and chosen) plaintext attacks. This > is a sufficiently hard task. Perhaps I'm just reacting to Stephen's wording, but I think that rather than "assuming" the crypto is secure against known and chosen plaintext attacks, we should use crypto algorithms that we "strongly believe" are secure. I advocate against the use of 1DES because it is often "assumed" to be secure -- but we know it isn't, and are within months of seeing demonstration proofs of its insecurity. John Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: ipsec@TIS.COM From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-esp-3des-md5-00.txt Date: Tue, 05 Nov 1996 09:42:11 -0500 Message-ID: <9611050942.aa17948@ietf.org> Sender: ipsec-approval@neptune.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Combined 3DES-CBC, HMAC and Replay Prevention Security Transform Author(s) : N. Doraswamy Filename : draft-ietf-ipsec-esp-3des-md5-00.txt Pages : 13 Date : 11/04/1996 This draft describes a combination of privacy, authentication, integrity and replay prevention into a single packet format. This document is the result of significant work by several major contributors and the IPsec working group as a whole. These contributors, cited later in this document, provided many of the key technical details summarized in this document. [IB93] [IBK93] Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esp-3des-md5-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-esp-3des-md5-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-esp-3des-md5-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961104110923.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-3des-md5-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-3des-md5-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961104110923.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Nov 5 19:14:25 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA02415 for ipsec-outgoing; Tue, 5 Nov 1996 18:54:37 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Nov 1996 18:57:41 -0500 To: John Gilmore From: kent@bbn.com (Stephen Kent) Subject: Re: proposed IPSEC changes/extensions Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: list John, You read more into my choice of words than I intended. My point was simply that we should focus on engineering the protocols with the intent that they will be used with crypto that is believed to be sufficiently strong as to not motivate lots of work on minimizing predictble plaintext. My rule of thumb in this work has long been that the subscriber data will often contain sufficiently amounts of predictable plaintext as to make it unnecessary to worry about the header predictability. I agree that predictable header data might make the search a bit easier for a given search engine design, but in the grand scheme of things it's not that big a deal. Steve From owner-ipsec Wed Nov 6 08:06:14 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA03792 for ipsec-outgoing; Wed, 6 Nov 1996 08:01:11 -0500 (EST) Date: Wed, 6 Nov 1996 08:02:53 -0500 (EST) From: John Kelley Message-Id: <199611061302.IAA18499@clipper.hq.tis.com> To: ipsec@ex.tis.com Subject: ANNOUNCEMENT -- New majordomo server Sender: owner-ipsec@ex.tis.com Precedence: list ANNOUNCEMENT All majordomo lists, including this one, that have been maintained on neptune.hq.tis.com, have been moved to portal.ex.tis.com. This has allowed us to upgrade our software and hardware to hopefully provide much better mailing list service. There may be a few rough spots during the transition and until all the pieces are fitted together. One major temporary problem is that the access to the current list archives is not available at this time. Another announcement will not be made when they are available, but the info file for each particular list will mention that they are back. Please send any problems you may see about the new server to majordomo-owner@ex.tis.com. Commands to the majordomo@neptune address will be forwarded to the new server for the forseeable future. For the most efficient response to commands or postings, it is recommended using the majordomo@ex.tis.com or @ex.tis.com addresses. Thank you for your patience in this matter. -TIS Majordomo Administrators From owner-ipsec Wed Nov 6 16:04:30 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA05330 for ipsec-outgoing; Wed, 6 Nov 1996 16:00:43 -0500 (EST) Message-ID: From: Greg Carter To: "'ipsec@tis.com'" Cc: "'isakmp-oakley@cisco.com'" Subject: December IETF... Date: Tue, 5 Nov 1996 15:34:16 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24 Sender: owner-ipsec@ex.tis.com Precedence: list Hello All, Can we expect revised drafts for any of ISAKMP OAKLEY ISAKMP-OAKLEY before the December IETF meetings? Thanks. -- ---- Greg Carter Nortel Secure Networks - Entrust carterg@entrust.com From owner-ipsec Wed Nov 6 16:06:24 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA05380 for ipsec-outgoing; Wed, 6 Nov 1996 16:05:05 -0500 (EST) Message-Id: <199611060221.SAA19853@toad.com> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol To: kent@bbn.com (Stephen Kent) cc: John Gilmore , ipsec@tis.com, gnu@toad.com Subject: Re: proposed IPSEC changes/extensions In-reply-to: Date: Tue, 05 Nov 1996 18:21:20 -0800 From: John Gilmore Sender: owner-ipsec@ex.tis.com Precedence: list > You read more into my choice of words than I intended. My point > was simply that we should focus on engineering the protocols with the > intent that they will be used with crypto that is believed to be > sufficiently strong as to not motivate lots of work on minimizing > predictble plaintext. Yep, we agree. Thanks for the clarification. John From owner-ipsec Wed Nov 6 16:43:17 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA05547 for ipsec-outgoing; Wed, 6 Nov 1996 16:41:47 -0500 (EST) Message-Id: <2.2.32.19961106165645.009ef380@pop.hq.tis.com> X-Sender: johnk@pop.hq.tis.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Nov 1996 11:56:45 -0500 To: ipsec@tis.com From: poised-approval@tis.com (by way of "John C. Kelley" ) Subject: BOUNCE poised@neptune.tis.com: Non-member submission from ["Donald E. Eastlake 3rd" ] Sender: owner-ipsec@ex.tis.com Precedence: list Approved New.poised Date: Tue, 5 Nov 1996 12:59:36 -0500 (EST) From: "Donald E. Eastlake 3rd" To: "John W. Stewart III" Cc: poised@TIS.COM Subject: Re: The NomCom Selection In-Reply-To: <199611051657.LAA01847@postoffice.Reston.mci.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII How about replacing the current: (4) Members of the IETF community must have attended at least 2 of the last 3 IETF meetings in order to volunteer. (5) Internet Society Board of Trustees, sitting members of the IAB, and sitting members of the IESG may not volunteer. (6) The Chair randomly selects the 10 voting volunteers from the pool of names of volunteers. with: (4) Members of the IETF community must have attended at least 2 of the last 3 IETF meetings in order to volunteer. The list of volunteers shall be made public before the selection of voting volunteers. (5) Internet Society Board of Trustees, sitting members of the IAB, and sitting members of the IESG may not volunteer. (6) The Chair randomly selects the 10 voting volunteers from the pool of names of volunteers by a method publicly verifiable as unbiased and fair. For example, selecting from the pool using an exact preannounced algorithm based on future public random numbers such as public lottery winning nubmers. This leaves 5 unchanged, adds publishing the volunteer list to 4, so people can see if they have been left out and see if some they do not think eligible have been included, and adds one sentence plus a few additional words to item 6. I think this proposed wording demonstrates that the pages of specific procedures some were arguing against isn't necessary and wasn't what I had in mind anyway. If someone wants, I'd by happy to write some code into which you enter the volunteer list length and a string of digits and it spews out the list of selectees. This could be issued as informational RFC in source code so anyone could compile and run it. Donald PS: Some other comments I had after looking at the exact wording in the current RFC: I'm a bit surprised the attendance criteria have been tightened up so much. 2 out of the last 3 meetings is pretty stringent. As I recall, it was originally much more lax (like 2 meetings ever). And I think that if I was writing this, I'd exclude ISOC employees and members of the IETF secretariate, essentially anyone whose attendance at IETF was being paid for by part of the I* mechanism, from being on the nomcom. But these are minor points in my mind and I'm not suggesting changing them unless others feel it important. They don't compare with fixing the selection to be demonstrably fair. On Tue, 5 Nov 1996, John W. Stewart III wrote: > Date: Tue, 05 Nov 1996 11:57:56 -0500 > From: John W. Stewart III > To: William Allen Simpson > Cc: poised@TIS.COM > Subject: Re: The NomCom Selection > > > the topic is whether something should be added to the > nomcomm procedures such that the selection of the > nomcomm from the pool of volunteers is independantly > verifiable. the last several messages have basically > been in favor of that in principle. there's a specific > proposal on the table from donald eastlake. are we > getting to consensus on adding something to the docs > about this? does someone want to propose specific text? > > /jws > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-ipsec Wed Nov 6 16:48:09 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA05614 for ipsec-outgoing; Wed, 6 Nov 1996 16:46:46 -0500 (EST) Message-ID: From: Greg Carter To: "'ipsec@tis.com'" Cc: "'isakmp-oakley@cisco.com'" Subject: December IETF... Date: Tue, 5 Nov 1996 15:34:16 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24 Sender: owner-ipsec@ex.tis.com Precedence: list Hello All, Can we expect revised drafts for any of ISAKMP OAKLEY ISAKMP-OAKLEY before the December IETF meetings? Thanks. -- ---- Greg Carter Nortel Secure Networks - Entrust carterg@entrust.com From owner-ipsec Wed Nov 6 17:30:58 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA05874 for ipsec-outgoing; Wed, 6 Nov 1996 17:29:00 -0500 (EST) Message-Id: <199611062231.OAA24293@spook> X-Authentication-Warning: dharkins-ss20.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Greg Carter Cc: "'ipsec@tis.com'" , "'isakmp-oakley@cisco.com'" Subject: Re: December IETF... In-Reply-To: Your message of "Tue, 05 Nov 1996 15:34:16 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Nov 1996 14:31:13 -0800 From: Daniel Harkins Sender: owner-ipsec@ex.tis.com Precedence: list > Can we expect revised drafts for any of > ISAKMP > OAKLEY > ISAKMP-OAKLEY > > before the December IETF meetings? The short answer is yes; I believe so; and, yes. The ISAKMP base spec is being edited presently and once that's done I'm going to make one last cursory check of rev 2 of the ISAKMP-Oakley draft to make sure everything is coherent. I was shooting for this Friday and that may still happen. If not then 1st thing next week. I believe the Oakley draft is also being revised, but I'm not sure the timeframe. regards, Dan. ------------------------------------------------------------------------------- Dan Harkins | E-mail: dharkins@cisco.com Network Protocol Security, cisco Systems | phone: +1 (408) 526-5905 170 W. Tasman Drive | fax: +1 (408) 526-4952 San Jose, CA 95134-1706, U.S.A. | ICBM: 37.45N, 122.03W ------------------------------------------------------------------------------- For your safety and the safety of others: concealed carry, and strong crypto ------------------------------------------------------------------------------- From owner-ipsec Thu Nov 7 08:00:42 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA07741 for ipsec-outgoing; Thu, 7 Nov 1996 07:53:53 -0500 (EST) Message-Id: <199611070328.WAA00202@smb.research.att.com.research.att.com> X-Authentication-Warning: smb.research.att.com.research.att.com: smb owned process doing -bs From: Steve Bellovin To: ipsec@tis.com Subject: compression and encryption Date: Wed, 06 Nov 1996 20:54:39 -0500 Sender: owner-ipsec@ex.tis.com Precedence: list I've been thinking a lot about doing compression over a lossy medium such as IP. The problem is that the receiver can lose compression synchronization. While there may be other ways to handle this, one that has been suggested is the ``resync every n packets'' approach. That is, the sender would include a sequence number in each packet, so the receiver could detect missing packets; every so often, a flag bit would be set or the sequence number would be set to 0, and a new compression state would be initialized. This has the effect of tying together a sequence of packets -- if a packet in the sequence is lost, all subsequent packets until the next resync point are also lost, because they cannot be decompressed. This implies that compression over a lossy medium, using this resync algorithm, acts as a packet loss multiplier -- the loss of one packet will often cause the loss of other packets as well. Call the probability of loss of an individual packet 'p'. (We will assume that loss probability for separate packets is independent. Whether or not this is true may be dependent on the implementation strategies of various routers, and on the hardware error characteristics of the underlying media.) Every 'n' packets, the compression state is reset. We wish to calculate P, the fraction of packets lost out of a burst of n. The first packet is dropped with probability p, and hence arrives with probability 1-p. The second packet arrives successfully if and only (a) it isn't dropped, and (b) the packet preceeding it isn't dropped. In other words, the probability of safe arrival of the second packet in the burst is (1-p)^2. Similarly, we see that for packet 'i', 1<=i<=n, it arrives safely with probability (1-p)^i. We can calculate the average number of safely arriving packets in a burst by adding the average number of copies of each individual packet that arrive -- (i-p)^i -- and dividing by n. Subtracting that from 1 gives the loss probability: P = 1 - sum(i=1 to n) (1-p)^i / n (Btw, I've confirmed this equation via a simulation.) Here are the results of the equation for packet loss probabilities ranging from .01 to .12, and burst sizes ranging from 1 to 16: 0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 0.09 0.10 0.11 0.12 ---------------------------------------------------------------------- 1 0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 0.09 0.10 0.11 0.12 2 0.01 0.03 0.04 0.06 0.07 0.09 0.10 0.12 0.13 0.15 0.16 0.17 3 0.02 0.04 0.06 0.08 0.10 0.12 0.13 0.15 0.17 0.19 0.20 0.22 4 0.02 0.05 0.07 0.10 0.12 0.14 0.16 0.18 0.21 0.23 0.25 0.27 5 0.03 0.06 0.09 0.11 0.14 0.17 0.19 0.22 0.24 0.26 0.29 0.31 6 0.03 0.07 0.10 0.13 0.16 0.19 0.22 0.25 0.27 0.30 0.32 0.35 7 0.04 0.08 0.11 0.15 0.18 0.21 0.24 0.27 0.30 0.33 0.36 0.38 8 0.04 0.09 0.13 0.16 0.20 0.24 0.27 0.30 0.33 0.36 0.39 0.41 9 0.05 0.09 0.14 0.18 0.22 0.26 0.29 0.33 0.36 0.39 0.42 0.44 10 0.05 0.10 0.15 0.20 0.24 0.28 0.31 0.35 0.38 0.41 0.44 0.47 11 0.06 0.11 0.16 0.21 0.26 0.30 0.34 0.37 0.41 0.44 0.47 0.50 12 0.06 0.12 0.18 0.23 0.27 0.32 0.36 0.39 0.43 0.46 0.49 0.52 13 0.07 0.13 0.19 0.24 0.29 0.33 0.38 0.41 0.45 0.48 0.51 0.54 14 0.07 0.14 0.20 0.25 0.30 0.35 0.39 0.43 0.47 0.50 0.54 0.56 15 0.08 0.15 0.21 0.27 0.32 0.37 0.41 0.45 0.49 0.52 0.55 0.58 16 0.08 0.15 0.22 0.28 0.34 0.38 0.43 0.47 0.51 0.54 0.57 0.60 The first line is the loss probability; the first column is the burst size. We know empirically that a loss probability of .05 is not atypical within the U.S.; the transoceanic trunks can have loss probabilities of .15 or thereabouts. (The packet loss figure reported by 'ping' is a measure of the round trip packet loss, which is too pessimistic. If g is the loss figure reported by ping, the one-way loss can be approximated as 1-sqrt(1-g), since the packet and the response together have more or less independent loss probabilities.) We also know that when packet losses get above 10%, the TCP congestion control algorithms will serve to cut throughput drastically. (N.B. The 10% figure is based on my experience; I haven't analyzed it or even checked the literature...) Our goal, then, must be to keep P below .1, or the resulting TCP reactions will more than compensate for the gains from copmression. We can see from the chart that for p=.05, we must keep n<=4. That is, no more than every fourth packet, the compression state must be reset. For lossy links, the burst size should be 1. One more problem with larger burst sizes should be noted. Even independent of the congestion control algorithms, TCP does only a finite number of retransmissions. Depending on the stack, this number may be surprisingly low. If too many packets in a burst are lost -- or if the resync packet following a group of useless packets is lost -- it is possible that the connection will be aborted. Given all this, it isn't clear how to implement compression under IPSEC. Picking a standard now is clearly premature; we need to investigate various choices. For example, 'n' might be negotiated during the key management exchange. But it isn't clear how a host would know when to pick a large 'n' or when to pick a small 'n'. It might also be desirable to let systems adapt dynamically. For example, a receiver might note the loss rate on received packets, as determined by the sequence numbers, and send periodically send a control packet. The sender could adjust its 'n' accordingly. (Receivers don't need to know 'n'; the change can be made unilaterally by the sender.) Of course, the rate of such messages -- which are reminscent of the link quality messages in PPP -- might need to be negotiable too. But the prospect of any such messages, with the consequent implications for packet formats, is yet another reason to hold off on a compression standard. We should also analyze just how much compression will help. On a typical dial-up link -- the market for this technology -- I suspect that not much text is sent. GIF and JPEG files are already compressed, and are not further compressible. There is a potentially large gain from VJ-like header compression, which we also lose with IPSEC. It might be possible to use our cryptographic state to implement some form of this. If we use per-connection keying, much of the TCP and IP headers can be reconstructed by caching the connection ID information in the security association table, and rebuilding the headers at the far end. I'll leave it to someone else to do the detailed design, but my gut feeling is that this is a bigger win than, say, LZW data compression. A final choice, for some people, might be to let their ISP do the encryption at the POP. (Please, return to your seats. I'm well aware of the implications of this...) Suppose that someone made IPSEC-capable terminal servers, with secure cryptographic hardware. The user's travel key could be transmitted to this box via a cryptographically protected exchange. The traffic is thus protected from the POP to the user's host (or firewall). It might even be desirable to do AH end-to-end (sacrificing VJ header compression but retaining modem or PPP compression), resulting in a final packet format of IP-ESP-AH-data. (I don't remember if this was in Steve Kent's list.) For most users and most data, the threat model is such that POP-to-firewall secrecy is good enough, provided that the ISP can't impersonate them. (I would note that most people trust phone lines far more than they trust the Internet. While I suspect that the Internet isn't quite as dangerous -- nor phone lines quite as safe -- as is generally believed, I do think that on the whole, the perception is correct.) Based on all this, I make the following recommendations: a) we proceed with ESP as it is now. No changes should be made, or hooks left, for compression. b) the key management exchanges should permit the negotiation of an arbitrary set of compression parameters, for when something is defined. c) we investigate IPSEC header compression. d) the IPSEC architecture must allow for the header formats resulting from POP-based encryption. Comments? From owner-ipsec Thu Nov 7 12:16:13 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA09118 for ipsec-outgoing; Thu, 7 Nov 1996 12:13:34 -0500 (EST) Message-Id: <2.2.16.19961107171238.2607fa9c@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 2.2 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 07 Nov 1996 12:12:38 -0500 To: Steve Bellovin From: Rodney Thayer Subject: Re: compression and encryption Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: list When my customers have run compression I've seen them find acceptable benefit from using non-history-based compression, which is to say I feel it's fine to do a reset after every packet. This case side-steps your analysis. I don't have enough information at my fingertips to confirm your simulation matches the field data I have seen. If someone wants to accept the potential impact of using a history-based compression scheme I don't see any reason to architect the protocol to stop them. On the other hand, if there's not 'rough consensus' for putting compression into ESP then fine, don't put it in. There's still the 'next header' field so the stand-alone compression transform can be used. At 08:54 PM 11/6/96 -0500, you wrote: >I've been thinking a lot about doing compression over a lossy medium >such as IP. The problem is that the receiver can lose compression >synchronization. While there may be other ways to handle this, >one that has been suggested is the ``resync every n packets'' >approach. That is, the sender would include a sequence number in >each packet, so the receiver could detect missing packets; every >so often, a flag bit would be set or the sequence number would be >set to 0, and a new compression state would be initialized. This >has the effect of tying together a sequence of packets -- if a >packet in the sequence is lost, all subsequent packets until the >next resync point are also lost, because they cannot be decompressed. >This implies that compression over a lossy medium, using this resync >algorithm, acts as a packet loss multiplier -- the loss of one >packet will often cause the loss of other packets as well. > >Call the probability of loss of an individual packet 'p'. (We will assume >that loss probability for separate packets is independent. Whether or >not this is true may be dependent on the implementation strategies of >various routers, and on the hardware error characteristics of the >underlying media.) Every 'n' packets, the compression state is reset. >We wish to calculate P, the fraction of packets lost out of a burst of n. > >The first packet is dropped with probability p, and hence arrives with >probability 1-p. The second packet arrives successfully if and only >(a) it isn't dropped, and (b) the packet preceeding it isn't dropped. >In other words, the probability of safe arrival of the second packet in >the burst is (1-p)^2. Similarly, we see that for packet 'i', 1<=i<=n, >it arrives safely with probability (1-p)^i. We can calculate the average >number of safely arriving packets in a burst by adding the average number >of copies of each individual packet that arrive -- (i-p)^i -- and >dividing by n. Subtracting that from 1 gives the loss probability: > > P = 1 - sum(i=1 to n) (1-p)^i / n > >(Btw, I've confirmed this equation via a simulation.) > >Here are the results of the equation for packet loss probabilities >ranging from .01 to .12, and burst sizes ranging from 1 to 16: > > 0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 0.09 0.10 0.11 0.12 > ---------------------------------------------------------------------- > 1 0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 0.09 0.10 0.11 0.12 > 2 0.01 0.03 0.04 0.06 0.07 0.09 0.10 0.12 0.13 0.15 0.16 0.17 > 3 0.02 0.04 0.06 0.08 0.10 0.12 0.13 0.15 0.17 0.19 0.20 0.22 > 4 0.02 0.05 0.07 0.10 0.12 0.14 0.16 0.18 0.21 0.23 0.25 0.27 > 5 0.03 0.06 0.09 0.11 0.14 0.17 0.19 0.22 0.24 0.26 0.29 0.31 > 6 0.03 0.07 0.10 0.13 0.16 0.19 0.22 0.25 0.27 0.30 0.32 0.35 > 7 0.04 0.08 0.11 0.15 0.18 0.21 0.24 0.27 0.30 0.33 0.36 0.38 > 8 0.04 0.09 0.13 0.16 0.20 0.24 0.27 0.30 0.33 0.36 0.39 0.41 > 9 0.05 0.09 0.14 0.18 0.22 0.26 0.29 0.33 0.36 0.39 0.42 0.44 > 10 0.05 0.10 0.15 0.20 0.24 0.28 0.31 0.35 0.38 0.41 0.44 0.47 > 11 0.06 0.11 0.16 0.21 0.26 0.30 0.34 0.37 0.41 0.44 0.47 0.50 > 12 0.06 0.12 0.18 0.23 0.27 0.32 0.36 0.39 0.43 0.46 0.49 0.52 > 13 0.07 0.13 0.19 0.24 0.29 0.33 0.38 0.41 0.45 0.48 0.51 0.54 > 14 0.07 0.14 0.20 0.25 0.30 0.35 0.39 0.43 0.47 0.50 0.54 0.56 > 15 0.08 0.15 0.21 0.27 0.32 0.37 0.41 0.45 0.49 0.52 0.55 0.58 > 16 0.08 0.15 0.22 0.28 0.34 0.38 0.43 0.47 0.51 0.54 0.57 0.60 > >The first line is the loss probability; the first column is the >burst size. > >We know empirically that a loss probability of .05 is not atypical >within the U.S.; the transoceanic trunks can have loss probabilities >of .15 or thereabouts. (The packet loss figure reported by 'ping' is a >measure of the round trip packet loss, which is too pessimistic. >If g is the loss figure reported by ping, the one-way loss can be >approximated as 1-sqrt(1-g), since the packet and the response >together have more or less independent loss probabilities.) > >We also know that when packet losses get above 10%, the TCP congestion >control algorithms will serve to cut throughput drastically. (N.B. >The 10% figure is based on my experience; I haven't analyzed it or >even checked the literature...) Our goal, then, must be to keep >P below .1, or the resulting TCP reactions will more than compensate >for the gains from copmression. > >We can see from the chart that for p=.05, we must keep n<=4. That >is, no more than every fourth packet, the compression state must >be reset. For lossy links, the burst size should be 1. > >One more problem with larger burst sizes should be noted. Even >independent of the congestion control algorithms, TCP does only a >finite number of retransmissions. Depending on the stack, this >number may be surprisingly low. If too many packets in a burst >are lost -- or if the resync packet following a group of useless >packets is lost -- it is possible that the connection will be >aborted. > >Given all this, it isn't clear how to implement compression under >IPSEC. Picking a standard now is clearly premature; we need to >investigate various choices. For example, 'n' might be negotiated >during the key management exchange. But it isn't clear how a host >would know when to pick a large 'n' or when to pick a small 'n'. >It might also be desirable to let systems adapt dynamically. For >example, a receiver might note the loss rate on received packets, >as determined by the sequence numbers, and send periodically send >a control packet. The sender could adjust its 'n' accordingly. >(Receivers don't need to know 'n'; the change can be made unilaterally >by the sender.) Of course, the rate of such messages -- which are >reminscent of the link quality messages in PPP -- might need to be >negotiable too. But the prospect of any such messages, with the >consequent implications for packet formats, is yet another reason to >hold off on a compression standard. > >We should also analyze just how much compression will help. On a >typical dial-up link -- the market for this technology -- I suspect >that not much text is sent. GIF and JPEG files are already >compressed, and are not further compressible. > >There is a potentially large gain from VJ-like header compression, >which we also lose with IPSEC. It might be possible to use our >cryptographic state to implement some form of this. If we use >per-connection keying, much of the TCP and IP headers can be >reconstructed by caching the connection ID information in the >security association table, and rebuilding the headers at the far >end. I'll leave it to someone else to do the detailed design, but >my gut feeling is that this is a bigger win than, say, LZW data >compression. > >A final choice, for some people, might be to let their ISP do the >encryption at the POP. (Please, return to your seats. I'm well >aware of the implications of this...) Suppose that someone made >IPSEC-capable terminal servers, with secure cryptographic hardware. >The user's travel key could be transmitted to this box via a >cryptographically protected exchange. The traffic is thus protected >from the POP to the user's host (or firewall). It might even be >desirable to do AH end-to-end (sacrificing VJ header compression but >retaining modem or PPP compression), resulting in a final packet format >of IP-ESP-AH-data. (I don't remember if this was in Steve Kent's >list.) For most users and most data, the threat model is such that >POP-to-firewall secrecy is good enough, provided that the ISP can't >impersonate them. (I would note that most people trust phone lines >far more than they trust the Internet. While I suspect that the >Internet isn't quite as dangerous -- nor phone lines quite as safe -- >as is generally believed, I do think that on the whole, the perception >is correct.) > >Based on all this, I make the following recommendations: > > a) we proceed with ESP as it is now. No changes should > be made, or hooks left, for compression. > > b) the key management exchanges should permit the negotiation > of an arbitrary set of compression parameters, for when something > is defined. > > c) we investigate IPSEC header compression. > > d) the IPSEC architecture must allow for the header formats > resulting from POP-based encryption. > >Comments? > > > > Rodney Thayer +1 617 332 7292 Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA Fax: +1 617 332 7970 http://www.shore.net/~sable Communications Software Development From owner-ipsec Thu Nov 7 14:29:28 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA10119 for ipsec-outgoing; Thu, 7 Nov 1996 14:28:35 -0500 (EST) Date: Thu, 7 Nov 1996 14:30:23 -0500 (EST) Message-Id: <199611071930.OAA11081@picu.morningstar.com> From: Leonard Samuelson To: Rodney Thayer Cc: Steve Bellovin , ipsec@tis.com Subject: Re: compression and encryption In-Reply-To: <2.2.16.19961107171238.2607fa9c@pop3.pn.com> References: <2.2.16.19961107171238.2607fa9c@pop3.pn.com> Reply-To: lcs@morningstar.com (Len Samuelson) Sender: owner-ipsec@ex.tis.com Precedence: list Rodney Thayer writes: > When my customers have run compression I've seen them find acceptable > benefit from using non-history-based compression, which is to say I > feel it's fine to do a reset after every packet. This case side-steps > your analysis. I don't have enough information at my fingertips to > confirm your simulation matches the field data I have seen. Considering that compression is most likely to benefit "bulk data transfer", such as ftp & web (with relatively large packet sizes); and considering that compression doesn't help much in non-bulk activities such as telnet (with small packet sizes), perhaps non-history-based compression might be a reasonable approach. However, perhaps much of the bulk data transfer that takes place is pre-compressed for archival storage anyway, and therefore is basically incompressible. Would this remain true for secured transmissions too? > Steve Bellovin writes: > >Based on all this, I make the following recommendations: > > > > a) we proceed with ESP as it is now. No changes should > > be made, or hooks left, for compression. > > > > b) the key management exchanges should permit the negotiation > > of an arbitrary set of compression parameters, for when something > > is defined. > > > > c) we investigate IPSEC header compression. > > > > d) the IPSEC architecture must allow for the header formats > > resulting from POP-based encryption. > > > >Comments? -- Leonard Samuelson, Ascend Communications, Inc. 614-326-6824 From owner-ipsec Thu Nov 7 15:01:04 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA10231 for ipsec-outgoing; Thu, 7 Nov 1996 15:00:33 -0500 (EST) Message-ID: <01BBCCBB.B8CB4320@bill.scli.com> From: Bill Hunt To: "ipsec@tis.com" , "'Steve Bellovin'" Subject: RE: compression and encryption Date: Thu, 7 Nov 1996 14:55:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: list good analysis. one minor note: If a burst is compressed, certainly uncompressing packet k requires receipt of packets 1..k-1. But if packet k is lost, is it necessary to retransmit packets 1..k-1? Or can the history be reset and the process begun again with k set as 1? The latter would allow a higher packet loss, since the "average" packet loss would be lower. ---------- From: Steve Bellovin[SMTP:smb@research.att.com] Sent: Wednesday, November 06, 1996 5:54 PM To: ipsec@tis.com Subject: compression and encryption I've been thinking a lot about doing compression over a lossy medium such as IP. [...] From owner-ipsec Thu Nov 7 15:20:51 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA10299 for ipsec-outgoing; Thu, 7 Nov 1996 15:20:38 -0500 (EST) Message-ID: <01BBCCBC.9C2048A0@bill.scli.com> From: Bill Hunt To: Steve Bellovin , "'Rodney Thayer'" Cc: "ipsec@tis.com" Subject: RE: compression and encryption Date: Thu, 7 Nov 1996 15:01:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: list We also run compression per packet. We find that the compression easily makes up for the encapsulation headers and other security overhead. In fact that is the specific reason we implemented it. However, we don't get anywhere near typical WAN compression rates. Enabling histories to include multiple packets would be very desirable. ---------- From: Rodney Thayer[SMTP:rodney@sabletech.com] Sent: Thursday, November 07, 1996 9:12 AM To: Steve Bellovin Cc: ipsec@tis.com Subject: Re: compression and encryption When my customers have run compression I've seen them find acceptable benefit from using non-history-based compression, which is to say I feel it's fine to do a reset after every packet. [...] From owner-ipsec Thu Nov 7 17:13:30 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA10670 for ipsec-outgoing; Thu, 7 Nov 1996 17:11:45 -0500 (EST) Message-ID: X-MS-TNEF-Correlator: From: Roy Pereira To: "'isakmp-oakley'" , "'IPSEC'" Subject: S/WAN ISAKMP/Oakley testing... Date: Thu, 7 Nov 1996 17:14:39 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BBCCCF.2A4FCCB0" Sender: owner-ipsec@ex.tis.com Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BBCCCF.2A4FCCB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'd like to talk about some of the 'magic' identifiers in ISAKMP. I'm talking about the values that aren't defined in v5 of the draft. - What transform ids are used for the ISAKMP proposal? - What ids are used for the ISAKMP proposal attributes "Group Identifier", Encryption Alg", "Hash Alg", and "Auth Alg" ? - What is the format of a SA proposal TLV ? Is the type and length 16 bits each ? Or are they 8 bits each ? - What is the ESP Proposal attribute "Cryptographic Synch" used for and when? - How do we transform a 8-byte ISAKMP SPI to a 4-byte ESP/AH SPI ? - The v5 ISAKMP draft states that the "Payload Length" in the SA payload is "in 4-octet units", but this is incorrect and should by in 1-octet units. - For the Certificate Payload, there aren't any identifiers for the Certificate Type and there is only one identifier for the Certificate Authority. - What ISAKMP exchange identifiers are used for the Oakley exchange modes? - What is the Notify message error "CONNECTED" used for? - What is the Notification Data? It's contents are not defined in the Internet DOI. Thanks. ------ =_NextPart_000_01BBCCCF.2A4FCCB0 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IisWAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAAzAcLAAcAEQAOACcABAAvAQEggAMADgAAAMwHCwAH ABEADgAoAAQAMAEBCYABACEAAAAwQkMwQzdEN0VEMzdEMDExOTI2MTAwODA1RkZDNzIwMQALBwEN gAQAAgAAAAIAAgABBIABAB8AAABTL1dBTiBJU0FLTVAvT2FrbGV5IHRlc3RpbmcuLi4AiQkBA5AG ANAGAAAaAAAAAwAmAAAAAAADADYAAAAAAB4AcAABAAAAHwAAAFMvV0FOIElTQUtNUC9PYWtsZXkg dGVzdGluZy4uLgAAAgFxAAEAAAAlAAAAAbu3r1KJ/LaFVyKxEdCSXgCAX/xyAQQVWJwfATkvMNQA A6ywlQAAAAMALgAAAAAAAwAGEBAXr/gDAAcQawMAAB4ACBABAAAAZQAAAElETElLRVRPVEFMS0FC T1VUU09NRU9GVEhFTUFHSUNJREVOVElGSUVSU0lOSVNBS01QSU1UQUxLSU5HQUJPVVRUSEVWQUxV RVNUSEFUQVJFTlRERUZJTkVESU5WNU9GVEhFRFIAAAAAAwAQEAAAAAADABEQAQAAAAIBCRABAAAA mgMAAJYDAADiBgAATFpGdabceQ3/AAoBDwIVAqQD5AXrAoMAUBMDVAIAY2gKwHNldG4yBgAGwwKD MgPFAgBwhHJxEiJzdGVtAoPmMxMMD/9mNAPGBxMCg5Y1D38QhzYWv2Y3F+qIaGVsAyBEbGcCgC59 CoAIzwnZOxz/MjUeNQKACoENsQtgbmcxDDAzFJALA2xpMTTyNALRaS0g4wzQIOMLVVsWogwBYwBB E5BvFBBjIQVASSdkICDAa2WYIHRvJEAHQGsgAaCbCGAFQHMDcCQwb2YkQAkbgCAnAMBnaWMn/CBp DbACMAaQCJEEIAuAASOwU0FLTVAuIG0jsW0kcwuAZyTFJbJ27wdAClAEICWwYQVACsAJ8D4nBUAN sQuACYAnInY10SV2ZHJhAYAuCo8ib2cjcyw7IMAzNiIPLf8g6C0gVynSdCvgAIACEJ5yKBAmcAQg KhEgdRHwLyPgMqEloydkICNBcG/6cwdAPzF8Mv80DwdAJMCbAkAFEGIlAAeRIkcDYAx1cCOwJoci LCBF6m4FAHkFMGkCIBcgG+DBOjEiSGFzaDsFAHDZI+AiQSUAO7QgNT4poq8kMDKiKeElgWEGAEE3 2LhUTFY9ECOwPiR0OqArJDA8MmwJ8Gc8oTE20CBiaXQEIGUA0DuwHUBATwXANmIlsXkgOKdB+j0/ JbJFUzSQUDf/FTkQQzqSbwnAYXBodyYwEjE6cGg9ADanPDJ3pRuAbjU4SG8H4GQkYA53JDEyZz8g OC1iebdG4TRFRbBJJEI/IDRLlLFFoS9BSExTNThUKSL/K0A0RSvTJSABkDjiKcMlslAiUGF5HJBh I+BMf0FzPQAnMSWyP0JRFT4RIvsnMUzwbyOQEgA2kAMAQiD/OjE4wSWhPhFU8jpwBbAdAO8jkTwy O6AIYGwj4EugJyKuMVOqLCYx4EY3BUMEkP0msmNQEUXQURQ6QCWxNnG/KhUAcFaxJok29lj6VEDm 91pEPhECIGxDYAIgXiEmh99cD1lyPIIFsEIQeVfYMgP5NEVleBGxIABe6jZPJDB4T2FrQWBDYGLn BGJz+0RPJaNOI2AGkENgB4E1AB9jQQSQA2AFwEcQT05O4EVDVEVESFhmn2eoa1lSOtJEKeBhQEAj sHS+JwQgBaACMCaRZBRuI2AfKno3M22RBKBT4URPSf8sKC/rLi8szzCvCsFOsABw/mtXx3V8cL9x zws3GYJ3jwogHCEAexAAAEAAOQAgKZoR+cy7AQMA8T8JBAAAAgFHAAEAAAA6AAAAYz1VUzthPSA7 cD1UaW1lU3RlcCBDb3Jwb3JhO2w9VFNOVFNSVjItOTYxMTA3MjIxNDM5Wi0yMTYyAAAAAgH5PwEA AABaAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC9PPVRJTUVTVEVQIENPUlBPUkFUSU9O L09VPVRJTUVTVEVQL0NOPVJFQ0lQSUVOVFMvQ049UlBFUkVJUkEAAAAeAPg/AQAAAAwAAABSb3kg UGVyZWlyYQACAfs/AQAAAFoAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089VElNRVNU RVAgQ09SUE9SQVRJT04vT1U9VElNRVNURVAvQ049UkVDSVBJRU5UUy9DTj1SUEVSRUlSQQAAAB4A +j8BAAAADAAAAFJveSBQZXJlaXJhAEAABzDwoZgR+cy7AUAACDCgoSAS+cy7AQMADTT9PwAAAgEU NAEAAAAQAAAAVJShwCl/EBulhwgAKyolFx4APQABAAAAAQAAAAAAAAALACkAAAAAAAsAIwAAAAAA AgF/AAEAAABSAAAAPGM9VVMlYT1fJXA9VGltZVN0ZXBfQ29ycG9yYSVsPVRTTlRTUlYyLTk2MTEw NzIyMTQzOVotMjE2MkB0c250c3J2Mi50aW1lc3RlcC5jb20+AAAApOY= ------ =_NextPart_000_01BBCCCF.2A4FCCB0-- From owner-ipsec Thu Nov 7 21:17:37 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA11227 for ipsec-outgoing; Thu, 7 Nov 1996 21:13:22 -0500 (EST) Message-Id: <199611080213.VAA20427@raptor.research.att.com> To: Rodney Thayer cc: ipsec@tis.com Subject: Re: compression and encryption Date: Thu, 07 Nov 1996 21:13:04 -0500 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: list When my customers have run compression I've seen them find acceptable benefit from using non-history-based compression, which is to say I feel it's fine to do a reset after every packet. This case side-steps your analysis. I don't have enough information at my fingertips to confirm your simulation matches the field data I have seen. It's quite compatible with n=1, which is more or less my point -- that we need to use very small burst sizes. 1 is a very nice low number, and it makes the protocol a lot simpler. If someone wants to accept the potential impact of using a history-based compression scheme I don't see any reason to architect the protocol to stop them. On the other hand, if there's not 'rough consensus' for putting compression into ESP then fine, don't put it in. There's still the 'next header' field so the stand-alone compression transform can be used. Yes. If we're going to do compression at this layer, that may be the right answer. But we should measure the effectiveness of compression when you have a dictionary in each packet, and the packets are ~512 bytes uncompressed. From owner-ipsec Thu Nov 7 21:20:54 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA11248 for ipsec-outgoing; Thu, 7 Nov 1996 21:19:23 -0500 (EST) Message-Id: <199611080218.VAA21072@raptor.research.att.com> To: Bill Hunt cc: "ipsec@tis.com" Subject: Re: compression and encryption Date: Thu, 07 Nov 1996 21:18:07 -0500 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: list good analysis. one minor note: If a burst is compressed, certainly uncompressing packet k requires receipt of packets 1..k-1. But if packet k is lost, is it necessary to retransmit packets 1..k-1? Or can the history be reset and the process begun again with k set as 1? The latter would allow a higher packet loss, since the "average" packet loss would be lower. No, it isn't necessary to resend 1..k-1 -- those can be decompressed succesfully without packet k..n. You can't reset the history during the burst without a network-level ack/retransmit mechanism, which violates far too many layering assumptions in TCP/IP. My analysis was precisely for the simple case of ``I send what I want, you receive whatever you can''. From owner-ipsec Fri Nov 8 08:58:13 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA12382 for ipsec-outgoing; Fri, 8 Nov 1996 08:47:56 -0500 (EST) Date: Thu, 7 Nov 96 17:57:10 EST From: wdm@epoch.ncsc.mil (W. Douglas Maughan) Message-Id: <9611072257.AA10138@dolphin.ncsc.mil> To: isakmp-oakley@cisco.com, ipsec@tis.com, rpereira@timestep.com Subject: Re: S/WAN ISAKMP/Oakley testing... Sender: owner-ipsec@ex.tis.com Precedence: list Roy, > > I'd like to talk about some of the 'magic' identifiers in ISAKMP. I'm > talking about the values that aren't defined in v5 of the draft. > > > - What transform ids are used for the ISAKMP proposal? > - What ids are used for the ISAKMP proposal attributes "Group > Identifier", Encryption Alg", "Hash Alg", and "Auth Alg" ? > - What is the format of a SA proposal TLV ? Is the type and length 16 > bits each ? Or are they 8 bits each ? > - What is the ESP Proposal attribute "Cryptographic Synch" used for > and when? > - How do we transform a 8-byte ISAKMP SPI to a 4-byte ESP/AH SPI ? > - The v5 ISAKMP draft states that the "Payload Length" in the SA > payload is "in 4-octet units", but this is incorrect and should by in > 1-octet units. > - For the Certificate Payload, there aren't any identifiers for the > Certificate Type and there is only one identifier for the Certificate > Authority. > - What ISAKMP exchange identifiers are used for the Oakley exchange > modes? > - What is the Notify message error "CONNECTED" used for? > - What is the Notification Data? It's contents are not defined in the > Internet DOI. > As mentioned in an e-mail by Dan Harkins yesterday, there will be new drafts for ISAKMP, ISAKMP-Oakley Resolution, and the IP Security DOI early next week (i.e. Tues or Wed.). I think they will answer most, if not all, of the above "attribute" questions. Doug Maughan From owner-ipsec Fri Nov 8 10:46:43 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA12902 for ipsec-outgoing; Fri, 8 Nov 1996 10:43:26 -0500 (EST) Date: Fri, 8 Nov 1996 10:44:09 -0500 (EST) From: Ian Duncan X-Sender: iduncan@magnus2 Reply-To: Ian Duncan To: Steven Bellovin cc: ipsec@tis.com Subject: Re: compression and encryption In-Reply-To: <199611080213.VAA20427@raptor.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: list On Thu, 7 Nov 1996, Steven Bellovin wrote: > It's quite compatible with n=1, which is more or less my point -- that > we need to use very small burst sizes. 1 is a very nice low number, > and it makes the protocol a lot simpler. > > If someone wants to accept the potential impact of using a > history-based compression scheme I don't see any reason to > architect the protocol to stop them. On the other hand, if > there's not 'rough consensus' for putting compression into ESP > then fine, don't put it in. > > There's still the 'next header' field so the stand-alone > compression transform can be used. > > Yes. If we're going to do compression at this layer, that may be the > right answer. But we should measure the effectiveness of compression > when you have a dictionary in each packet, and the packets are ~512 > bytes uncompressed. A quick bit of hopefully helpful background -- A few years ago, when compression was being discussed in the context of PPP there was a proposal offered by HP for a 'stateless' compressor. I was a bit fuzzy on the details (and still am) but the essence was some clever folk had examined the nature of the available entropy in short bit streams and tuned some variant of LZ+ to focus at that level. The result claimed was better compression where "n=1". How much better and how much heat would get generated at both ends was never made clear. As well, there were some patent issues involved if memory serves. -- Ian Duncan Access Products Development Newbridge Networks Corp. From owner-ipsec Fri Nov 8 11:17:35 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA12999 for ipsec-outgoing; Fri, 8 Nov 1996 11:14:38 -0500 (EST) Date: Fri, 08 Nov 96 08:12:00 PST From: John H Wilson Message-ID: To: owner-ipsec@portal.ex.tis.com, rodney@sabletech.com cc: ipsec@tis.com Subject: Re[2]: compression and encryption Sender: owner-ipsec@ex.tis.com Precedence: list Text item: I assume all these arguments apply equally well to the use of encryption algorithms that rely on "history". (Sorry, I've only recently been following the IPSEC mailing list) Are there any proposals to use stream ciphers in IPSEC? The n=1 case would be the equivalent of treating each packet as a separate stream. Right now, I'm interested in audio/video streams (already compressed; real-time operation). Re-transmit is not an option; but re-sync (of the encryption algorithm) would be vital. For n>1, would it be possible to transmit the stream offset in each packet to allow re-sync? ____________________________ Reply Separator _________________________________ >Subject: Re: compression and encryption >Author: owner-ipsec@portal.ex.tis.com at SMTPGATE >Date: 11/7/96 9:13 PM > > When my customers have run compression I've seen them find > acceptable benefit from using non-history-based compression, > which is to say I feel it's fine to do a reset after every > packet. This case side-steps your analysis. I don't have > enough information at my fingertips to confirm your simulation > matches the field data I have seen. > >It's quite compatible with n=1, which is more or less my point -- that >we need to use very small burst sizes. 1 is a very nice low number, >and it makes the protocol a lot simpler. > > If someone wants to accept the potential impact of using a > history-based compression scheme I don't see any reason to > architect the protocol to stop them. On the other hand, if > there's not 'rough consensus' for putting compression into ESP > then fine, don't put it in. > > There's still the 'next header' field so the stand-alone > compression transform can be used. > >Yes. If we're going to do compression at this layer, that may be the >right answer. But we should measure the effectiveness of compression >when you have a dictionary in each packet, and the packets are ~512 >bytes uncompressed. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Precedence: list Sender: owner-ipsec@ex.tis.com From: Steven Bellovin Date: Thu, 07 Nov 1996 21:13:04 -0500 Subject: Re: compression and encryption cc: ipsec@tis.com To: Rodney Thayer Message-Id: <199611080213.VAA20427@raptor.research.att.com> Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA112 27 for ipsec-outgoing; Thu, 7 Nov 1996 21:13:22 -0500 (EST) Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mailbag .jf.intel.com (8.8.2/8.7.3) with ESMTP id UAA29956 for ; Thu, 7 Nov 1996 20:22:08 -0800 (PST) Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4]) by relay.jf.intel.com (8.8.2/8.7.3) with ESMTP id UAA08086 for ; Thu, 7 Nov 1996 20:19:35 -0800 (PST) Return-Path: owner-ipsec@portal.ex.tis.com From owner-ipsec Fri Nov 8 13:13:52 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA13331 for ipsec-outgoing; Fri, 8 Nov 1996 13:10:17 -0500 (EST) Message-Id: <199611081808.NAA26663@raptor.research.att.com> To: John H Wilson cc: ipsec@tis.com Subject: Re: Re[2]: compression and encryption Date: Fri, 08 Nov 1996 13:08:09 -0500 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: list I assume all these arguments apply equally well to the use of encryption algorithms that rely on "history". Yup. (Sorry, I've only recently been following the IPSEC mailing list) Are there any proposals to use stream ciphers in IPSEC? There have been some such proposals. The n=1 case would be the equivalent of treating each packet as a separate stream. Right now, I'm interested in audio/video streams (already compressed; real-time operation). Re-transmit is not an option; but re-sync (of the encryption algorithm) would be vital. For n>1, would it be possible to transmit the stream offset in each packet to allow re-sync? All of the stream ciphers proposed include the current offset as part of each packet. From owner-ipsec Fri Nov 8 13:43:41 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA13403 for ipsec-outgoing; Fri, 8 Nov 1996 13:40:18 -0500 (EST) Date: Fri, 8 Nov 1996 13:40:14 -0500 Message-Id: <199611081840.NAA20494@relay.hq.tis.com> X-Sender: mike.sabin@postoffice.worldnet.att.net X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Steven Bellovin From: Michael Sabin Subject: Re: compression and encryption Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: list At 02:13 AM 11/8/96 +0000, Steven Bellovin wrote: > When my customers have run compression I've seen them find > acceptable benefit from using non-history-based compression, > which is to say I feel it's fine to do a reset after every > packet. This case side-steps your analysis. I don't have > enough information at my fingertips to confirm your simulation > matches the field data I have seen. > >It's quite compatible with n=1, which is more or less my point -- that >we need to use very small burst sizes. 1 is a very nice low number, >and it makes the protocol a lot simpler. > > If someone wants to accept the potential impact of using a > history-based compression scheme I don't see any reason to > architect the protocol to stop them. On the other hand, if > there's not 'rough consensus' for putting compression into ESP > then fine, don't put it in. > > There's still the 'next header' field so the stand-alone > compression transform can be used. > >Yes. If we're going to do compression at this layer, that may be the >right answer. But we should measure the effectiveness of compression >when you have a dictionary in each packet, and the packets are ~512 >bytes uncompressed. > Below is a table of numbers that shows an example of the tradeoff between compression efficiency and the parameter n in a "reset after n packets" strategy. The table is from an appendix in . It is based on the LZS compression algorithm. Here's the row of the table that corresponds to 512-byte payloads: n: 1 2 4 8 16 32 Compression ratio: 1.58 1.73 1.89 2.01 2.08 2.11 In the case n=1, the compression boosts throughput by about 60%. (Headers are neglected here.) Larger values of n give better compression, obviously. ----------------------------------- >From : 9. Appendix: Guidelines for Resetting Compression Histories The following table offers some guidance on how frequently an LZS compression history can be reset. The table considers two parameters: "payload_bytes," the number of bytes in each payload; and "reset_bytes," the number of bytes between history resets. Reset_bytes is a multiple of payload_bytes, since an integer number of payloads is processed between resets. Each entry in the table shows the compression ratio that was achieved when compressing a test file with the corresponding values of payload_bytes and reset_bytes. The test file was the University of Calgary Text Compression Corpus [Calgary]. The length of the file prior to compression was 3,278,000 bytes. When the entire file was compressed as a single payload, a compression ratio of 2.34 resulted. | reset_bytes | 64 128 256 512 1024 2048 4096 8192 16384 ------------+----------------------------------------------------- packet_bytes| 64 | 1.18 1.26 1.37 1.48 1.61 1.74 1.84 1.89 1.92 128 | 1.28 1.40 1.53 1.67 1.82 1.93 1.99 2.03 256 | 1.43 1.56 1.71 1.86 1.98 2.05 2.08 512 | 1.58 1.73 1.89 2.01 2.08 2.11 1024 | 1.74 1.90 2.02 2.09 2.13 2048 | 1.91 2.03 2.10 2.14 4096 | 2.04 2.10 2.14 8192 | 2.11 2.14 16384 | 2.14 The table suggests that not there is not much degradation in compression ratio if the compression history is reset after several thousand bytes have been processed. Resetting after less than 1,000 bytes is probably too soon -- the compression ratio degrades significantly. But waiting longer than about 8,000 bytes gains little -- the compression ratio does not increase much. From owner-ipsec Fri Nov 8 17:14:58 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA13997 for ipsec-outgoing; Fri, 8 Nov 1996 17:09:31 -0500 (EST) Message-Id: <3.0.32.19961108141107.00929b90@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 08 Nov 1996 14:11:14 -0800 To: Steve Bellovin From: Bob Monsour Subject: Re: compression and encryption Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: list Steve, that was a very thoughtful analysis. Thank you for spending the time and energy on it. Here are my thoughts on your recommendations. At 08:54 PM 11/6/96 -0500, Steve Bellovin wrote: > a) we proceed with ESP as it is now. No changes should > be made, or hooks left, for compression. Based on the data provided by Mike Sabin earlier today regarding the compression performance of stateless compression (repeated here): On 11/6, Mike Sabin wrote: >Here's the row of the table that corresponds to 512-byte payloads: > > n: 1 2 4 8 16 32 > Compression ratio: 1.58 1.73 1.89 2.01 2.08 2.11 > >In the case n=1, the compression boosts throughput by about 60%. >(Headers are neglected here.) Larger values of n give better >compression, obviously. I would suggest that we allow for statless compression to be implemented within the context of ESP. I would further suggest, as I did in an earlier posting (11/4) that this be done with some minor language changes to ESP: "...that the ESP draft simply state that compression is one of the negotiable security association attributes...In addition, the ESP draft would state that when the optional compression is implemented, it is performed prior to encryption. I would suggest that the appropriate language be added to the descriptions of the "sender" and "receiver" operations in the tunnel-mode and transport-mode descriptions (sections 4.1 and 4.2 of the June 6 draft)." This allows stateless compression functionality to be optionally deployed in the near term> It also allows the working group the necessary time and consideration needed to properly evaluate mechanisms for implementing statfull, multi-packet compression. I would suggest to you that this qualifies as "no changes or hooks", since the ESP transform is not modified in any way. > b) the key management exchanges should permit the negotiation > of an arbitrary set of compression parameters, for when something > is defined. Agree. > c) we investigate IPSEC header compression. In tunnel mode, the tunnelled headers are part of the payload that will be compressed. This will boost compression efficiency, since the headers are presumably very compressible. > d) the IPSEC architecture must allow for the header formats > resulting from POP-based encryption. > Agree. Thanks to all for listening. I look forward to comments from all (supporters and non-supporters alike). Bob Monsour rmonsour@earthlink.net From owner-ipsec Sun Nov 10 02:10:19 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA15768 for ipsec-outgoing; Sun, 10 Nov 1996 02:01:41 -0500 (EST) Message-Id: Date: Tue, 5 Nov 96 15:24 PST From: Phil Karn To: smb@research.att.com CC: ipsec@tis.com Reply-To: karn@qualcomm.com In-reply-to: <199611070328.WAA00202@smb.research.att.com.research.att.com> (message from Steve Bellovin on Wed, 06 Nov 1996 20:54:39 -0500) Subject: Re: compression and encryption Sender: owner-ipsec@ex.tis.com Precedence: list I generally agree with Steve's analysis showing the intractability of doing compression at the IPSEC layer. Especially with the widespread use of application-level compression in the Internet, the lack of compression in IPSEC just doesn't strike me as a serious problem. I think VJ header compression is not nearly as important as once was, for several reasons: 1. Van originally designed his scheme when he had a 2400bps dialup modem and read his netnews over a telnet session. Today if you have 14.4kb/s, you're behind the curve. 2. Many of the things you used to do over a telnet/rlogin type session (where header overhead is most significant) are now done with intelligent local agents. Examples include email, netnews and web surfing. Most of these agents speak various client/server protocols over the wire with much larger average packet sizes as compared to character-at-a-time telnet. This makes header overhead much less significant. So while there's no reason to take out VJ header compression now that it exists, I no longer consider it essential. Phil From owner-ipsec Tue Nov 12 13:21:18 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA20434 for ipsec-outgoing; Tue, 12 Nov 1996 13:11:13 -0500 (EST) To: IETF-Announce:;;;;@tis.com@tis.com;;; cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-hmac-md5-01.txt Date: Tue, 12 Nov 1996 11:52:19 -0500 Message-ID: <9611121152.aa23440@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: list --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : HMAC: Keyed-Hashing for Message Authentication Author(s) : H. Krawczyk, M. Bellare, R. Canetti Filename : draft-ietf-ipsec-hmac-md5-01.txt Pages : 8 Date : 11/08/1996 This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-hmac-md5-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-hmac-md5-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-hmac-md5-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961108101246.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-hmac-md5-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-hmac-md5-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961108101246.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Nov 12 20:39:27 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA21453 for ipsec-outgoing; Tue, 12 Nov 1996 20:36:15 -0500 (EST) Message-Id: <199611130138.RAA00770@red.ipsilon.com> X-Mailer: exmh version 1.6.4 10/10/95 To: karn@qualcomm.com cc: smb@research.att.com, ipsec@tis.com Subject: Re: compression and encryption In-reply-to: Your message of "Tue, 05 Nov 1996 15:24:00 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Nov 1996 17:38:41 -0800 From: Greg Minshall Sender: owner-ipsec@ex.tis.com Precedence: list Phil, > (where header overhead is most significant) are now done with > intelligent local agents. Examples include email, netnews and web > surfing. Most of these agents speak various client/server protocols > over the wire with much larger average packet sizes as compared to > character-at-a-time telnet. This makes header overhead much less > significant. I think there continue to be protocols (RTP comes to mind) in which the header:payload ratio tends to be too high (even on 28.8 links). I'm not arguing that we need compression in ipsec; i'm just making the point that *compression* isn't necessarily a dead end, even in today's internet. Greg From owner-ipsec Wed Nov 13 13:22:28 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA23213 for ipsec-outgoing; Wed, 13 Nov 1996 13:13:54 -0500 (EST) Date: Wed, 13 Nov 96 10:12:00 PST From: John H Wilson Message-ID: To: ipsec@tis.com Subject: Re-keying RTP streams Sender: owner-ipsec@ex.tis.com Precedence: list In H.323 (A/V conferencing as defined by the ITU), the media streams are transported by RTP; each stream also having a corresponding RTCP channel. Both the RTP and the RTCP channels are (of course) unreliable. H.323 also has a reliable (TCP) control channel (H.245) which is used to set up the RTP/RTCP channels and to control the conference. This channel remains open for the duration. [In a multipoint conference, each endpoint has a separate H.245 channel to the Conference Controller (the MC), and the RTP/RTP channels are multicast. In general, the H.245 channel cannot be used to communicate amongst endpoints; between transmitter and receivers]. In extending H.323 to provide private communications, the H.245 channel becomes secure (using TLS), and the security parameters for an RTP channel [the RTCP channel is not encrypted] are negotiated on it(them). In particular, the keys for the RTP channel are distributed on the H.245 channel(s) by the MC. All before thr RTP/RTCP sessions are established. The problem arises when the MC needs to distribute fresh keys after some period (or because the old key has been compromised for some reason). There's no problem in distributing the new keys (this is done on the reliable, secure H.245 channel). But how should the Transmitter and Receiver (or multiple receivers, in the multicast case) synchronize on the new key? The H.245 channel cannot be used for this purpose, since it does not (at least in the multipoint case) connect the transmitter to all receivers. We are left with just the RTP and RTCP channels. The RTP headers contain both sequence numbers and timestamps. There are two proposals: 1. There is a bit in all RTCP packets which flips when a new key starts being used on the RTP stream (and remains in the new state until the next key change). The first packet of the new state also contains the sequence number of the RTP stream at which the new key starts to apply. (This packet could be sent several times). A receiver will always see the bit flip but, if it misses the sequence number, it can immediately start using the new key; some number of RTP packets may have been indecipherable before this point. 2. The bit (as described above) would be in the RTP header (probably requiring an extended header). The receivers would change key as soon as they see the bit flip. I would very much like to hear opinions on these solutions, but preferrably, better proposals. john_h_wilson@ccm.jf.intel.com From owner-ipsec Wed Nov 13 20:42:15 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA24078 for ipsec-outgoing; Wed, 13 Nov 1996 20:40:41 -0500 (EST) Date: Wed, 13 Nov 1996 17:42:07 -0800 (PST) From: Phil Karn Message-Id: <199611140142.RAA14477@servo.qualcomm.com> To: minshall@ipsilon.com CC: smb@research.att.com, ipsec@tis.com In-reply-to: <199611130138.RAA00770@red.ipsilon.com> (message from Greg Minshall on Tue, 12 Nov 1996 17:38:41 -0800) Subject: Re: compression and encryption Sender: owner-ipsec@ex.tis.com Precedence: list >I think there continue to be protocols (RTP comes to mind) in which the >header:payload ratio tends to be too high (even on 28.8 links). I'm not >arguing that we need compression in ipsec; i'm just making the point that >*compression* isn't necessarily a dead end, even in today's internet. In its present form, VJ header compression only works for TCP/IP. There are some proposals for UDP/IP header compression, but I don't think they're widely deployed. The fundamental problem with any real time application over IP is the hard tradeoff that has to be made between header overhead and store-and-forward delay. This is a very difficult tradeoff, and systems where it is really important (like digital cellular) are designed from the ground up along very different lines. It may well be that it will never be possible to build one integrated network that can handle both realtime and nonrealtime traffic with an acceptable degree of efficiency and delay performance for both. Phil From owner-ipsec Wed Nov 13 20:55:19 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA24092 for ipsec-outgoing; Wed, 13 Nov 1996 20:55:10 -0500 (EST) Message-Id: <199611140157.RAA05553@cornpuffs.cisco.com> From: rja@cisco.com (Ran Atkinson) Date: Wed, 13 Nov 1996 17:57:00 PST X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipsec@tis.com Subject: Combined ESP transform Sender: owner-ipsec@ex.tis.com Precedence: list The Combined ESP transform completed its WG Last Call. There appears to be smooth consensus that it should advance to Proposed Standard and that RFC-1829 be moved to Historic status at the time the Combined ESP transform is published as a standards-track RFC. Ran Atkinson rja@cisco.com Paul Lambert palamber@us.oracle.com co-chairs, IP Security WG -- From owner-ipsec Thu Nov 14 09:57:11 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA24690 for ipsec-outgoing; Thu, 14 Nov 1996 09:54:09 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-arch-sec-01.txt Date: Thu, 14 Nov 1996 09:27:10 -0500 Message-ID: <9611140927.aa04031@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: list --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Security Architecture for the Internet Protocol Author(s) : R. Atkinson Filename : draft-ietf-ipsec-arch-sec-01.txt Pages : 24 Date : 11/12/1996 This memo describes the security protocols for IP version 4 (IPv4) and IP version 6 (IPv6) and the services that they provide. Each security protocol is specified in a separate document. This document also describes key management requirements for systems implementing these security protocols. This document is not an overall Security Architecture for the Internet; it addresses only IP-layer security. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-arch-sec-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-arch-sec-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-arch-sec-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961112150209.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-arch-sec-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-arch-sec-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961112150209.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu Nov 14 10:53:04 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA24787 for ipsec-outgoing; Thu, 14 Nov 1996 10:52:39 -0500 (EST) Message-ID: <01BBD211.132E50A0@webster.unety.net> From: Jim Fleming To: "'Phil Karn'" , "minshall@ipsilon.com" Cc: "ipsec@tis.com" , "smb@research.att.com" Subject: RE: compression and encryption Date: Thu, 14 Nov 1996 09:49:04 -0600 Sender: owner-ipsec@ex.tis.com Precedence: list On Wednesday, November 13, 1996 11:42 AM, Phil Karn[SMTP:karn@qualcomm.com] wrote: @ @ It may well be that it will never be possible to build one integrated @ network that can handle both realtime and nonrealtime traffic with an @ acceptable degree of efficiency and delay performance for both. @ Phil, In my opinion, I think that depends on how you define "integrated". If everyone assumes that the flat addressing and equal peer model of the Internet is the only way to scale the system, then I would agree with you. Imagine if everyone on the "toll" telephone network was allowed to plug everything from a phone, to a PBX, to a 5ESS into the network, this model would have problems scaling and being properly "integrated". In my opinion, the existing IPv4 network needs to be migrated to become a hardened, centralized, highly-reliable, "core" that primarily provides two things: 1. Low-cost bit transport to many regions of the world. 2. A distributed DNS system for mapping symbolic names to binary quantities (a.k.a. DNS). Once this "core" is stable it can be made more secure by encouraging the migration of users to better integrated layers which can designed around the edges of the core. The layers can be engineered based on "application" requirements as opposed to transport requirements. After it becomes more clear what the application requirements are (based on customer demands), the core can be evolved to more efficiently handle the outer layers. This type of integration assumes a separation of the transport core from the application layers. In my opinion, this can be viewed as "one" network, although I can see how some people might view it as more than one. -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8) From owner-ipsec Thu Nov 14 13:44:25 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA24949 for ipsec-outgoing; Thu, 14 Nov 1996 13:40:03 -0500 (EST) From: Michael Richardson Message-Id: <199611141840.NAA08261@lox.sandelman.ottawa.on.ca> Subject: Re: compression and encryption To: JimFleming@unety.net (Jim Fleming) Date: Thu, 14 Nov 1996 13:40:18 -0500 (EST) Cc: ipsec@tis.com In-Reply-To: <01BBD211.132E50A0@webster.unety.net> from "Jim Fleming" at Nov 14, 96 09:49:04 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipsec@ex.tis.com Precedence: list > In my opinion, I think that depends on how you define "integrated". > > If everyone assumes that the flat addressing and equal peer model > of the Internet is the only way to scale the system, then I would > agree with you. It is the most democratic and the hardest to regulate and thus the safest from the influence of political and financial powers. No matter what the "core" does there are those of us that will stick to the tools we can control rather recreate the telephone system. There is a group of us in Ottawa that is trying to wein our community network away from the telephone system to wireless technology. From owner-ipsec Thu Nov 14 15:07:18 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA25030 for ipsec-outgoing; Thu, 14 Nov 1996 15:03:32 -0500 (EST) Message-ID: <01BBD234.678C4940@webster.unety.net> From: Jim Fleming To: "'Michael Richardson'" Cc: "ipsec@tis.com" Subject: RE: compression and encryption Date: Thu, 14 Nov 1996 14:01:58 -0600 Sender: owner-ipsec@ex.tis.com Precedence: list On Thursday, November 14, 1996 7:40 AM, Michael Richardson[SMTP:mcr@sandelman.ottawa.on.ca] wrote: @ > In my opinion, I think that depends on how you define "integrated". @ > @ > If everyone assumes that the flat addressing and equal peer model @ > of the Internet is the only way to scale the system, then I would @ > agree with you. @ @ It is the most democratic and the hardest to regulate and thus @ the safest from the influence of political and financial powers. Yes, and that same attribute can be enjoyed by the outer layers. Just because there is a Legacy Core, control does not, naturally, implode into the center. @ No matter what the "core" does there are those of us that will @ stick to the tools we can control rather recreate the telephone @ system. There is a group of us in Ottawa that is trying to wein our @ community network away from the telephone system to wireless technology. @ Yes, in an ideal world, the core is optical or wireless or a combination of the two, and there is very little there. I would offer that the current core is only scaffolding to be used to provide a place to "stand" while the next layers are built. Once the next layers are worked out, the core can be phased out and eventually removed. Imagine taking a ballon and covering it with wet plaster. Once the plaster drys, you can stick a pin in the balloon and poof, the core disappears, but the plaster remains. Once you have that shell structure, then you continue to build outward, not inward. Optical sensors can be drilled down through the thin plaster to be able to "see" all of the other sites being built on the other side of the plaster shell. Just think, if the Earth were built that way, you might have a nice line-of-sight connection to Australia or an Island in the Caribbean. As it stands now, you still have to contend with gravity and the shape and structure of the Earth. Of course, if we could all just figure out how to achieve a low orbit with wireless connections between the sites, then the Earth could be turned into a nature preserve where we vacation when we are not "working" on our communication network. ..back to work...;-) -- Jim Fleming UNETY Systems, Inc. Naperville, IL e-mail: JimFleming@unety.net JimFleming@unety.net.s0.g0 (EDNS/IPv8) From owner-ipsec Thu Nov 14 20:15:15 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA25280 for ipsec-outgoing; Thu, 14 Nov 1996 20:13:05 -0500 (EST) Date: Thu, 14 Nov 1996 17:09:52 -0800 (PST) From: Phil Karn Message-Id: <199611150109.RAA28123@servo.qualcomm.com> To: JimFleming@unety.net CC: minshall@ipsilon.com, ipsec@tis.com, smb@research.att.com In-reply-to: <01BBD211.132E50A0@webster.unety.net> (message from Jim Fleming on Thu, 14 Nov 1996 09:49:04 -0600) Subject: RE: compression and encryption Sender: owner-ipsec@ex.tis.com Precedence: list >In my opinion, I think that depends on how you define "integrated". By "integrated" I mean "have a common network-layer protocol". This includes addressing. It does not include directory services, physical media, transport layer protocol, etc. In the case of the Internet, it means just IP (and perhaps ICMP). IP is *the* protocol that defines the Internet. The fundamental difference between a voice network (even a digital one) and a computer network is most clear in the network layer design. The limitations of the traditional circuit-switched telephony network for computer networking are well known, as they led to the creation of the Internet. And conversely, there are limitations of the Internet for conversational voice telephony. A lot of people dwell on the guaranteed service aspects of voice, and yes this is an issue -- but it's one that's likely to be solved by various real time protocols. A much more fundamental issue is the efficiency/delay tradeoff of using a connectionless network protocol for conversational voice. As speech coders get better and better, fewer bits have to be sent per unit time to provide good speech quality. Since people have a definite limit to how much propagation delay they can tolerate, this means smaller and smaller packets. They are now so small that the IP header overhead is now very significant. For example, the variable-rate vocoder we use in CDMA digital cellular generates one of 4 sizes of frames every 20 ms, and the largest of these is only 171 bits. That's only slightly larger than a 20-byte IP header (and you thought ATM frames were tiny). So you have a hard choice to make between taking a rather severe hit on overhead or bunching up packets and increasing delay as a result. Yes, various header compression schemes could be used over slow links when assumptions can be made about the lack of reordering, but these schemes aren't likely to work in the Internet as a whole. All this makes me believe that we will have separate network layer protocols for computer networking and conversational voice for some time. They may each pick up attributes of the other, but I doubt that just one will take over -- unless connectionless networks get so fast and cheap (or conversational voice becomes so unimportant) that efficiency becomes unimportant. This may happen someday on fiber, but it's unlikely to happen on the radio channels I work with. Phil From owner-ipsec Tue Nov 19 10:26:17 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA00752 for ipsec-outgoing; Tue, 19 Nov 1996 10:13:49 -0500 (EST) Message-Id: <2.2.32.19961119152137.00bbec34@mailserv-H.ftp.com> X-Sender: naganand@mailserv-H.ftp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Nov 1996 10:21:37 -0500 To: ipsec@tis.com From: Naganand Doraswamy Subject: AH in IPv6 Sender: owner-ipsec@ex.tis.com Precedence: bulk In case of IPv6, if the packet were to fragemented on the end host, do we calculate AH before fragmentation or after fragmentation? RFC says that AH is calculated before fragmentation on the sending side and after reassembly on the receiving side. I guess it is possible to calculate AH after fragmentation as the packets are not fragmented by the intermediate routers in case of IPv6 and wanted to clarify which is the right thing to do. Am I correct in saying that AH is calculated before fragmentation on sending side and after reassembly on the receiving side even in IPv6? Thanks, --Naganand ---------------------------------------------------------------- naganand@ftp.com Tel #: (508)684-6743 (O) From owner-ipsec Tue Nov 19 11:16:51 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00984 for ipsec-outgoing; Tue, 19 Nov 1996 11:14:50 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-oakley-01.txt Date: Tue, 19 Nov 1996 10:01:15 -0500 Message-ID: <9611191001.aa15589@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The resolution of ISAKMP with Oakley Author(s) : D. Harkins, D. Carrel Filename : draft-ietf-ipsec-isakmp-oakley-01.txt Pages : 27 Date : 10/18/1996 [MSST96] (ISAKMP) provides a framework for authentication and key exchange but does not define them. ISAKMP is designed to be key exchange independant; that is, it is designed to support many different key exchanges. [Orm96] (Oakley) describes a series of key exchanges-- called "modes"-- and details the services provided by each (e.g. perfect forward secrecy for keys, identity protection, and authentication). This document describes a proposal for using the Oakley Key Exchange Protocol in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-oakley-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-oakley-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961118135721.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-oakley-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118135721.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Nov 19 11:16:54 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA00983 for ipsec-outgoing; Tue, 19 Nov 1996 11:14:49 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ipsec-ipsec-doi-00.txt Date: Tue, 19 Nov 1996 10:01:09 -0500 Message-ID: <9611191001.aa15568@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Internet IP Security Domain of Interpretation for ISAKMP Author(s) : D. Piper Filename : draft-ipsec-ipsec-doi-00.txt Pages : 15 Date : 11/18/1996 The Internet Security Association and Key Management Protocol (ISAKMP) defines a framework for security association management and cryptographic key establishment for the Internet. This framework consists of defined exchanges and processing guidelines that occur within a given Domain of Interpretation (DOI). This document details the Internet IP Security DOI, which is defined to cover the IP security protocols that use ISAKMP to negotiate their security associations. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ipsec-ipsec-doi-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ipsec-ipsec-doi-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ipsec-ipsec-doi-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961118135339.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ipsec-ipsec-doi-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ipsec-ipsec-doi-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118135339.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Nov 19 14:44:31 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA01732 for ipsec-outgoing; Tue, 19 Nov 1996 14:38:31 -0500 (EST) From: dan.mcdonald@eng.sun.com (Dan McDonald) Message-Id: <199611191926.LAA26149@kebe.eng.sun.com> Subject: Re: AH in IPv6 To: naganand@ftp.com Date: Tue, 19 Nov 1996 11:26:36 -0800 (PST) Cc: ipsec@tis.com In-Reply-To: <2.2.32.19961119152137.00bbec34@mailserv-H.ftp.com> from "Naganand Doraswamy" at Nov 19, 96 10:21:37 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk > In case of IPv6, if the packet were to fragemented on the end host, do we > calculate AH before fragmentation or after fragmentation? RFC says that AH > is calculated before fragmentation on the sending side and after reassembly > on the receiving side. I guess it is possible to calculate AH after > fragmentation as the packets are not fragmented by the intermediate routers > in case of IPv6 and wanted to clarify which is the right thing to do. Stick with the spec! Authentication before fragmentation is CLEARLY the right thing to do. All sorts of trickinesses happen if you authenticate fragments. Think about fragment size if you don't know the SA before fragmenting. If I have the SA a priori, I might as well do it. If I don't have an SA, I shouldn't fragment because I don't know what algorithm key management (or algorithm discovery for you in-line keying folks) will negotiate. I can't determine the fragment size in that case because I don't necessarily know the size of the AH. > Am I correct in saying that AH is calculated before fragmentation on sending > side and after reassembly on the receiving side even in IPv6? Absolutely correct! -- Daniel L. McDonald | Mail: danmcd@eng.sun.com Phone: (415) 786-6815 + Software Engineer | *** My opinions aren't necessarily Sun's opinions! *** | SunSoft Internet | "rising falling at force ten | Engineering| we twist the world and ride the wind" - Rush + From owner-ipsec Wed Nov 20 10:37:27 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA04194 for ipsec-outgoing; Wed, 20 Nov 1996 10:31:54 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ipsec-ipsec-doi-01.txt Date: Wed, 20 Nov 1996 09:56:50 -0500 Message-ID: <9611200956.aa14139@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Internet IP Security Domain of Interpretation for ISAKMP Author(s) : D. Piper Filename : draft-ipsec-ipsec-doi-01.txt Pages : 15 Date : 11/19/1996 The Internet Security Association and Key Management Protocol (ISAKMP) defines a framework for security association management and cryptographic key establishment for the Internet. This framework consists of defined exchanges and processing guidelines that occur within a given Domain of Interpretation (DOI). This document details the Internet IP Security DOI, which is defined to cover the IP security protocols that use ISAKMP to negotiate their security associations. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ipsec-ipsec-doi-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ipsec-ipsec-doi-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ipsec-ipsec-doi-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961119101447.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ipsec-ipsec-doi-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ipsec-ipsec-doi-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961119101447.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Nov 20 10:37:27 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA04192 for ipsec-outgoing; Wed, 20 Nov 1996 10:31:53 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; From: Internet-Drafts@ietf.org cc: ipsec@tis.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-mcdonald-pf-key-v2-00.txt Date: Wed, 20 Nov 1996 09:57:41 -0500 Message-ID: <9611200957.aa14213@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PF_KEY Key Management API, Version 2 Author(s) : D. McDonald, C. Metz, B Phan Filename : draft-mcdonald-pf-key-v2-00.txt Pages : 43 Date : 11/19/1996 This memo documents a user-to-kernel interface for key management applications. It is derived from the 4.x BSD routing socket, and it operates in a very similar fasion. This document is informational, and not meant to specify a standard. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mcdonald-pf-key-v2-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-mcdonald-pf-key-v2-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-mcdonald-pf-key-v2-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961119151230.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mcdonald-pf-key-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mcdonald-pf-key-v2-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961119151230.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Nov 20 10:55:45 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA04298 for ipsec-outgoing; Wed, 20 Nov 1996 10:54:11 -0500 (EST) Date: Wed, 20 Nov 1996 10:54:11 -0500 (EST) From: owner-ipsec@ex.tis.com Message-Id: <199611201521.RAA02438@del.tla.org> X-Mailer: exmh version 1.6.2 7/18/95 To: linux-ipsec@clinet.fi Cc: ipsec@tis.com Subject: New release of IPSEC for Linux. Reply-To: ji@hol.gr Organization: La maison qui rend fou. Mime-Version: 1.0 Content-Type: application/pgp; format=mime; x-action=signclear; x-originator=2D3EEAD5 Content-Transfer-Encoding: 7bit Date: Wed, 20 Nov 1996 17:21:21 +0200 From: John Ioannidis Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Content-Type: text/plain; charset=us-ascii Release 0.3 is out. Some bug fixes, more examples, better release engineering. It should appear in ftp://ftp.funet.fi/pub/unix/security/net/ip/ in a few hours (theoretically, shortly after 96/11/21 03:05 UTC). The impatient can get it from http://users.prometheus.gr/~ji/ipsec/. Read README.1st first. Get ipsec-0.3.tar.gz. Verify it against the PGP signature in ipsec-0.3.pgp. As usual, report any problems to me (ji@hol.gr). /ji -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQCVAgUBMpMh78+A0YctPurVAQF/gAQAownuVE9TsMAnoS96XfCgMM1td3kQXziN JRNDYmcODoMKR7+R8rSDSviAYKq9kzW+XmRM57eSAOTqec+rAxwfSv9NBQAT4Xxn n2r5H0N/8VHq2qEETvxBiNbACpH3754vj178Jm+fd3j5o3Wj6c/lcOKMI2b7GxBN 52yRsM2eS2c= =ceb6 -----END PGP SIGNATURE----- From owner-ipsec Wed Nov 20 10:57:31 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA04335 for ipsec-outgoing; Wed, 20 Nov 1996 10:56:11 -0500 (EST) Date: Wed, 20 Nov 1996 10:56:11 -0500 (EST) From: owner-ipsec@ex.tis.com Message-Id: <199611201536.RAA02515@del.tla.org> X-Mailer: exmh version 1.6.2 7/18/95 To: linux-ipsec@clinet.fi Cc: ipsec@tis.com Subject: Re: New release of IPSEC for Linux. In-Reply-To: Your message of "Wed, 20 Nov 1996 17:21:21 +0200." <199611201521.RAA02438@del.tla.org> Reply-To: ji@hol.gr Organization: La maison qui rend fou. Mime-Version: 1.0 Content-Type: application/pgp; format=mime; x-action=signclear; x-originator=2D3EEAD5 Content-Transfer-Encoding: 7bit Date: Wed, 20 Nov 1996 17:35:58 +0200 From: John Ioannidis Sender: owner-ipsec@portal.ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Content-Type: text/plain; charset=us-ascii > The impatient can get it from http://users.prometheus.gr/~ji/ipsec/. I meant http://users.hol.gr/~ji/ipsec/. Sorry about that! /ji -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQCVAgUBMpMlXM+A0YctPurVAQEu6gQAroCFZ/xXI981YA44OnpCXhTQ0JYk+dtA 17ctIgeh+KQgB8oUv0po9cL2d50w/sHHNrYUYLKe6vtFmpBgdqt7c5E7FmTJL8f4 k6HRGxC1/l+cc0rO/d/5Zjnc53V12MOlk5XvplWu8PsHaIZA8dt9P+PRDSUhc2QN lkrLlHzIZfE= =eO3w -----END PGP SIGNATURE----- From owner-ipsec Wed Nov 20 14:00:04 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA04945 for ipsec-outgoing; Wed, 20 Nov 1996 13:56:46 -0500 (EST) Date: Wed, 20 Nov 96 10:56:00 PST From: John H Wilson Message-ID: To: owner-ipsec@portal.ex.tis.com cc: ipsec@tis.com Subject: Re: I-D ACTION:draft-ipsec-ipsec-doi-01.txt Sender: owner-ipsec@ex.tis.com Precedence: bulk Text item: I believe the name should be: draft-ietf-ipsec-ipsec-doi-01.txt ______________________________ Reply Separator _________________________________ Subject: I-D ACTION:draft-ipsec-ipsec-doi-01.txt Author: owner-ipsec@portal.ex.tis.com at SMTPGATE Date: 11/20/96 9:56 AM --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Internet IP Security Domain of Interpretation for ISAKMP Author(s) : D. Piper Filename : draft-ipsec-ipsec-doi-01.txt Pages : 15 Date : 11/19/1996 The Internet Security Association and Key Management Protocol (ISAKMP) defines a framework for security association management and cryptographic key establishment for the Internet. This framework consists of defined exchanges and processing guidelines that occur within a given Domain of Interpretation (DOI). This document details the Internet IP Security DOI, which is defined to cover the IP security protocols that use ISAKMP to negotiate their security associations. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ipsec-ipsec-doi-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ipsec-ipsec-doi-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ipsec-ipsec-doi-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961119101447.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ipsec-ipsec-doi-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ipsec-ipsec-doi-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961119101447.I-D@ietf.org> --OtherAccess-- --NextPart-- Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Precedence: bulk Sender: owner-ipsec@ex.tis.com Message-ID: <9611200956.aa14139@ietf.org> Date: Wed, 20 Nov 1996 09:56:50 -0500 Subject: I-D ACTION:draft-ipsec-ipsec-doi-01.txt Reply-to: Internet-Drafts@ietf.org From: Internet-Drafts@ietf.org cc: ipsec@tis.com To: IETF-Announce:;;;;;;@tis.com@tis.com;;;;;;;;;;;;;;;;;;; Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA041 94 for ipsec-outgoing; Wed, 20 Nov 1996 10:31:54 -0500 (EST) Received: from portal.ex.tis.com (portal.ex.tis.com [192.94.214.101]) by mailbag .jf.intel.com (8.8.3/8.7.3) with ESMTP id KAA02561 for ; Wed, 20 Nov 1996 10:22:59 -0800 (PST) Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4]) by relay.jf.intel.com (8.8.2/8.7.3) with ESMTP id KAA00859 for ; Wed, 20 Nov 1996 10:20:26 -0800 (PST) Return-Path: owner-ipsec@portal.ex.tis.com From owner-ipsec Wed Nov 20 14:04:34 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA04958 for ipsec-outgoing; Wed, 20 Nov 1996 14:03:16 -0500 (EST) Message-ID: <3293566E.2781@cs.umass.edu> Date: Wed, 20 Nov 1996 14:05:19 -0500 From: Lewis McCarthy Organization: Theoretical Computer Science Group, UMass-Amherst, X-Mailer: Mozilla 3.0 (X11; I; OSF1 V3.0 alpha) MIME-Version: 1.0 To: Internet-Drafts@ietf.org CC: ipsec@tis.com Subject: Re: I-D ACTION:draft-ipsec-ipsec-doi-01.txt References: <9611200956.aa14139@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk Internet-Drafts@ietf.org wrote: [...] > Title : The Internet IP Security Domain of Interpretation for > ISAKMP > Author(s) : D. Piper > Filename : draft-ipsec-ipsec-doi-01.txt > Pages : 15 > Date : 11/19/1996 [...] > A URL for the Internet-Draft is: > ftp://ds.internic.net/internet-drafts/draft-ipsec-ipsec-doi-01.txt There's a "-ietf" missing from the draft name -- it actually appears to be: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ipsec-doi-01.txt -Lewis From owner-ipsec Thu Nov 21 04:48:01 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id EAA05856 for ipsec-outgoing; Thu, 21 Nov 1996 04:41:24 -0500 (EST) Date: Thu, 21 Nov 1996 10:42:15 +0100 From: saiz@gc.ssr.upm.es ("LUIS SAIZ GIMENO") Message-Id: <199611210942.AA25881@orfeo.gc.ssr.upm.es> To: ipsec@tis.com Subject: Any work in IPsec multicast key management? Sender: owner-ipsec@ex.tis.com Precedence: bulk I would like to know if there is some work in progress in multicast/anycast key management in this WG. Any idea about which kind of cryptographic protocol is suitable to be adopted? TIA. Luis Saiz Gimeno saiz@gc.ssr.upm.es Grupo de Circuitos, SSR, Polytechnical University of Madrid --------------------------------------------------------------------- Protocol cryptanalysis is essentially formalized paranoia. -- G. Simmons. --------------------------------------------------------------------- From owner-ipsec Thu Nov 21 10:23:13 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA06664 for ipsec-outgoing; Thu, 21 Nov 1996 10:19:39 -0500 (EST) Message-Id: <2.2.32.19961121152124.00af7be4@pop.hq.tis.com> X-Sender: freeves@pop.hq.tis.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Nov 1996 10:21:24 -0500 To: ipsec@tis.com From: owner-ipsec@tis.com (by way of Frank Reeves ) Subject: BOUNCE ipsec@portal.ex.tis.com: Non-member submission from [Internet-Drafts@ietf.org] Sender: owner-ipsec@ex.tis.com Precedence: bulk To: IETF-Announce@ietf.org; cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ipsec-doi-01.txt Date: Thu, 21 Nov 1996 09:39:33 -0500 Sender: cclark@ietf.org Message-ID: <9611210939.aa04253@ietf.org> --NextPart Note: This announcement is being re-sent with a new filename. A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The Internet IP Security Domain of Interpretation for ISAKMP Author(s) : D. Piper Filename : draft-ietf-ipsec-ipsec-doi-01.txt Pages : 15 Date : 11/19/1996 The Internet Security Association and Key Management Protocol (ISAKMP) defines a framework for security association management and cryptographic key establishment for the Internet. This framework consists of defined exchanges and processing guidelines that occur within a given Domain of Interpretation (DOI). This document details the Internet IP Security DOI, which is defined to cover the IP security protocols that use ISAKMP to negotiate their security associations. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ipsec-doi-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ipsec-doi-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ipsec-doi-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961120140904.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ipsec-doi-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ipsec-doi-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961120140904.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu Nov 21 10:23:18 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA06658 for ipsec-outgoing; Thu, 21 Nov 1996 10:18:08 -0500 (EST) Message-Id: <2.2.32.19961121151946.00ae7934@pop.hq.tis.com> X-Sender: freeves@pop.hq.tis.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Nov 1996 10:19:46 -0500 To: ipsec@tis.com From: owner-ipsec@tis.com (by way of Frank Reeves ) Subject: BOUNCE ipsec@portal.ex.tis.com: Non-member submission from [Internet-Drafts@ietf.org] Sender: owner-ipsec@ex.tis.com Precedence: bulk To: IETF-Announce@ietf.org; cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ah-hmac-md5-04.txt Date: Thu, 21 Nov 1996 09:40:33 -0500 Sender: cclark@ietf.org Message-ID: <9611210940.aa04321@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : HMAC-MD5 IP Authentication with Replay Prevention Author(s) : M. Oehler, R. Glenn Filename : draft-ietf-ipsec-ah-hmac-md5-04.txt Pages : 8 Date : 11/20/1996 This document describes a keyed-MD5 transform to be used in conjunction with the IP Authentication Header [RFC-1826]. The particular transform is based on [HMAC-MD5]. An option is also specified to guard against replay attacks. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ah-hmac-md5-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ah-hmac-md5-04.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-md5-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961120141711.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-md5-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ah-hmac-md5-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961120141711.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu Nov 21 10:23:42 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA06671 for ipsec-outgoing; Thu, 21 Nov 1996 10:21:08 -0500 (EST) Message-Id: <2.2.32.19961121152307.00ae92b4@pop.hq.tis.com> X-Sender: freeves@pop.hq.tis.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Nov 1996 10:23:07 -0500 To: ipsec@tis.com From: owner-ipsec@tis.com (by way of Frank Reeves ) Subject: BOUNCE ipsec@portal.ex.tis.com: Non-member submission from [Internet-Drafts@ietf.org] Sender: owner-ipsec@ex.tis.com Precedence: bulk To: IETF-Announce@ietf.org; cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ah-hmac-sha-04.txt Date: Thu, 21 Nov 1996 09:40:39 -0500 Sender: cclark@ietf.org Message-ID: <9611210940.aa04339@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : HMAC-SHA IP Authentication with Replay Prevention Author(s) : S. Chang, R. Glenn Filename : draft-ietf-ipsec-ah-hmac-sha-04.txt Pages : 8 Date : 11/20/1996 This document describes a keyed-SHA transform to be used in conjunction with the IP Authentication Header [RFC-1826]. The particular transform is based on [HMAC-MD5]. An option is also specified to guard against replay attacks. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ah-hmac-sha-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-ah-hmac-sha-04.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-sha-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961120141941.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ah-hmac-sha-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ah-hmac-sha-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961120141941.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu Nov 21 10:25:43 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA06690 for ipsec-outgoing; Thu, 21 Nov 1996 10:23:09 -0500 (EST) Message-Id: <2.2.32.19961121152503.00b07a28@pop.hq.tis.com> X-Sender: freeves@pop.hq.tis.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Nov 1996 10:25:03 -0500 To: ipsec@tis.com From: owner-ipsec@tis.com (by way of Frank Reeves ) Subject: BOUNCE ipsec@portal.ex.tis.com: Non-member submission from [Internet-Drafts@ietf.org] Sender: owner-ipsec@ex.tis.com Precedence: bulk To: IETF-Announce@ietf.org; cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-oakley-02.txt Date: Thu, 21 Nov 1996 09:41:08 -0500 Sender: cclark@ietf.org Message-ID: <9611210941.aa04456@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : The resolution of ISAKMP with Oakley Author(s) : D. Harkins, D. Carrel Filename : draft-ietf-ipsec-isakmp-oakley-02.txt Pages : 27 Date : 11/20/1996 [MSST96] (ISAKMP) provides a framework for authentication and key exchange but does not define them. ISAKMP is designed to be key exchange independant; that is, it is designed to support many different key exchanges. [Orm96] (Oakley) describes a series of key exchanges-- called "modes"-- and details the services provided by each (e.g. perfect forward secrecy for keys, identity protection, and authentication). This document describes a proposal for using the Oakley Key Exchange Protocol in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-oakley-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-oakley-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961121090052.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-oakley-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-oakley-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961121090052.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Thu Nov 21 14:47:08 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA07165 for ipsec-outgoing; Thu, 21 Nov 1996 14:38:43 -0500 (EST) Message-Id: <3.0.32.19961121114020.00979840@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 21 Nov 1996 11:40:27 -0800 To: ipsec@tis.com From: Bob Monsour Subject: Packet-by-packet compression within IPSec Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Here's a recap of recent history on this topic and a specific proposal to bring the discussion to closure. In recent weeks there has been some good debate regarding the use of lossless data compression within the context of the IP security framework. Having reviewed the wg list comments, here's an extremely brief recap. [For those new to the list, please see the list archives for details.] 1. concept was initially embraced by a few 2. suggestion was made to add fields to ESP to support stateful compression (i.e., compression history retained across multiple IP datagrams) 3. some suggested the use of a separate compression header to support it (as opposed to fields within ESP) 4. stateful nature of compression raised some concerns 5. issue of a sequence counter, redundant with the replay ctr raised concerns 6. issue of the lossyness of the IP media raised concerns 7. need for negotiating SA parameters to support statefulness was stated 8. analysis of packet loss raised serious concerns over stateful compression 9. comments that stateless compression had benefit were stated 10. packet loss concerns seemed to depart in the face of stateless compression 11. proposal made to allow for stateless compression within ESP Since that time, there has been little or no additional comment on the subject. I would like to clarify my most recent proposal and provide specific language to support its implementation. I fully understand that the working group is moving full steam ahead to get the IPSec documents ready for the San Jose meeting and to move toward wide-spread interoperable deployments during the coming year. I do not believe that this proposal or its implementation will hinder those efforts and am willing to provide any support needed to assist. Before going into the specifics of my proposal, I would like to point out a subtlety involving the use of compression with encryption. The reduced payload resulting from compression also reduces the amount of work (i.e., CPU cycles) required for subsequent encryption operations. Clearly, the CPU cost of compression must be low enough to realize a net gain, but in our tests, this bears out in enough cases to make it interesting. This speaks directly to second paragraph of section 1.1 of the ESP draft regarding the increased communications latency expected due to the encryption and decryption operations. MY PROPOSAL The essence of my proposal is to add simple, straightforward language (provided below) to the ESP draft which allows compression to be performed on a packet-by-packet basis (keeping *NO* history or state information across packets). The use of compression would be negotiated as an security association parameter along with the algorithm to be employed. The ESP payload data would simply be either compressed or uncompressed and *NO* additional fields (in the header *OR* in the payload) would be required to support it. This is the simplest form of compression support. I would further suggest that, at some later time, the working group undertake the effort to examine methods for supporting stateful compression. Nothing in the proposed language is intended to preclude such efforts. SPECIFIC LANGUAGE The proposed changes are relative to draft-ietf-ipsec-payload-00.txt, dated June 6, 1996 by Ran Atkinson. I understand that a revisoion of the draft is in progress am confident that, given the nature of the changes specified below, they could be easily be mapped into the new draft. Section 1.1 (Overview) Add the following sentence to the end of the first paragraph: The encrypted user data portion of the payload may be compressed prior to encryption. Security association parameters, negotiated by the key management mechanism, are used to determine whether or not compression is used and which compression algorithm will be used. Section 3. (ENCAPSULATING SECURITY PAYLOAD SYNTAX) Add the following sentence to first paragraph, making it the second to the last sentence in the section (prior to "A high-level..."). The protected user data portion of the payload may be compressed prior to encryption. Immediately following the second ESP header diagram, change the sentence to read: Encryption, authentication and optional compression algorithms, and the precise... Section 4.1 (ESP in Tunnel-mode) Change the first sentence of the second paragraph to read: ...to locate the corect Security Association, optionally applies the appropriate compression transform, and then applies the appropriate encryption transform. Change the first sentence of the fifth paragraph to read: If decryption succeeds, optional decompression is performed as necessary, and the original IP datagram... Section 4.2 (ESP in Transport-mode) Change the first sentence of the second paragraph to read: ...to locate the corect Security Association, optionally applies the appropriate compression transform, and then applies the appropriate encryption transform. Change the first sentence of the fifth paragraph to read: If decryption succeeds, optional decompression is performed as necessary, and the original transport layer... We will be producing a draft compression transform which adheres to the proposed "new model" for transforms. It will contain no fields, but will simply specify how to transform a variabble sized data block from an uncompressed block to a compressed block. I would very much like to hear comments from those interested in the subject and from the authors and/or co-chairs of the group regarding their suggestions and guidance. Bob Monsour rmonsour@earthlink.net From owner-ipsec Thu Nov 21 15:26:01 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA07278 for ipsec-outgoing; Thu, 21 Nov 1996 15:25:13 -0500 (EST) Message-Id: <199611212023.PAA03158@raptor.research.att.com> To: Bob Monsour cc: ipsec@tis.com Subject: Re: Packet-by-packet compression within IPSec Date: Thu, 21 Nov 1996 15:23:00 -0500 From: Steven Bellovin Sender: owner-ipsec@ex.tis.com Precedence: bulk I think your proposal is quite acceptable. I'm willing to go a step further -- the key management protocol should allow for negotiation of currently-unspecified parameters for some future compression scheme. From owner-ipsec Thu Nov 21 16:36:58 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA07348 for ipsec-outgoing; Thu, 21 Nov 1996 16:35:14 -0500 (EST) Message-Id: <3.0b36.32.19961121163033.0093be20@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0b36 (32) Date: Thu, 21 Nov 1996 16:35:41 -0500 To: ipsec@tis.com From: Robert Moskowitz Subject: IPsec Interoperability Week #1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id QAA07345 Sender: owner-ipsec@ex.tis.com Precedence: bulk The following is a proposal from the AIAG to all IPSec implementors. We are very serious about getting product. To the extent that we will supply resources to get interoperablity. Below is the general plan for an interoperability week. Please discuss it here, amongst yourselves and with us. We are open to fleshing out (ie nailing down) what ever details are appropriate. Of course, I will be at IETF to take what ever blooding deemed appropriate, just remember that I have to leave on friday ;) IPsec Interoperability Week #1 TO: All implementers of the Ipsec protocols From: The Automotive Industry Action Group ANX Security work group What: 1st working session for IPsec interoperability Where: MCI’s Richardson Texas test facilities When: January 6th - 10th, 1997 Participation Contact: fbowdon@mcimail.com (810 351-5124), cwinter@mcimail.com (810 351-5257) RSVP by: Dec 10th, 1997 Document Questions/Issues: rgm3@chrysler.com by Dec 6th, 1996 GOALS: Determine the current state of deployablity of IPsec components for the Auto industry. At this time, demonstration of Key management via Oakley/ISAKMP is very important to the ANX work group. The intention is to create as close to a real world inter-company environment for vendor testing. Multiple scenario testing will be desired. Work on the basis that firewalls, split DNS, and private addressing is common. Subsets of these situations will be documented. Participants minimally need to have product that uses RFCs 1825-9, Oakley aggressive or main mode with authentication with pre-shared keys Border-to-border via tunneling Consider access to ‘trade zones’ or entire company network. Remote-to-border Remote-to-interior Interior-to-foreign border Through local border Interior-to-interior Technology to demonstrate interoperability: Basic IPsec protocols, emphasis on ESP-HMAC (add draft name here) Keying material for IPsec setup with Key Management exchange via Oakley/ISAKMP (Choice of ANX wg) (all three drafts) Proxy modes Please provide Oakley modes demonstrable at this time. Public key format of X.509v3 Keys can be cached X.509 key retrieval via LDAP CA will be provided for testing Subsets of these will be documented by product. A more compete testing matrix and success criteria will be developed between now and Dec 8th. Policy issues will be sorted out as well is operational: Unintended routing through multiple tunnels Access control granularity Oakley and ESP options as X.509 extensions Des vs 3Des, Compression supported, others The test facility will be connected to the Internet, so vendors unable to attend are encouraged to contact the MCI coordination team (TBN) to work out arrangements for remote participation. Follow up testing will be planned for 2Q97. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-ipsec Thu Nov 21 17:25:25 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA07423 for ipsec-outgoing; Thu, 21 Nov 1996 17:24:44 -0500 (EST) Message-Id: <2.2.16.19961121222412.2f57500c@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 2.2 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Nov 1996 17:24:12 -0500 To: ipsec@tis.com From: Rodney Thayer Subject: compression transform conclusions Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- [response to Bob Monsour's proposal] I believe his charactarization of the discussion so far is accurate. I believe it is the rough consensus of the group that compression should be part of the ESP transform, one way or the other, with or without statefulness, parameter negotiation, sequence numbers, etc. I myself think the ESP transform is excessively complex as it is, regardless of the compression features. I think this will interfere with deployment and will increase the risk of security problems due to buggy implementations. But, I do think Bob's proposal represents the view of the group, so I think that's what we should go with. -----BEGIN PGP SIGNATURE----- Version: 4.0 Business Edition Comment: PGP by ViaCrypt iQCVAgUBMpTWPMKmlvJNktGxAQGoywQAgAhOO/aGTYhZsqfZvspaGq9Azcgrr+F6 ZeWZf08n157opre07UTVr98wujdJs+PFo0/1IWApGioQUwV4tV9tbN062SSu3+F1 x29e954kB5C801pA1IG1MwXa1vtdQsA8El4D5igRg4ug1iHCMaYags8frCgLP9co xxSXdN8qhFg= =Uq+S -----END PGP SIGNATURE----- Rodney Thayer +1 617 332 7292 Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA Fax: +1 617 332 7970 http://www.shore.net/~sable Communications Software Development From owner-ipsec Thu Nov 21 18:11:33 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA07449 for ipsec-outgoing; Thu, 21 Nov 1996 18:10:48 -0500 (EST) Message-ID: <3294E1E1.ABD@cs.umass.edu> Date: Thu, 21 Nov 1996 18:12:33 -0500 From: Lewis McCarthy Organization: Theoretical Computer Science Group, UMass-Amherst, X-Mailer: Mozilla 3.0 (X11; I; OSF1 V3.2 alpha) MIME-Version: 1.0 To: Luis Saiz Gimeno CC: ipsec@tis.com Subject: Re: Any work in IPsec multicast key management? References: <199611210942.AA25881@orfeo.gc.ssr.upm.es> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk LUIS SAIZ GIMENO writes: > I would like to know if there is some work in progress in > multicast/anycast key management in this WG. Any idea about which > kind of cryptographic protocol is suitable to be adopted? The most recent mail I've seen about this on the list was from Ran on Sept.9 ("Subject: FYI: Multicast Key Management documents") -- check the archives. He mentions GKMP [Harney et al.] and RFC 1949 [Ballardie]. Ran Atkinson wrote on Sept. 9: >>> I'm told that work is underway at several places (e.g. ORNL) on a >>> PF_KEY-based freely distributable implementation of GKMP technology >>> inside the ISAKMP framework. The survey essay Secure Multicast [Pessi], , is already rather out of date, but you might find the discussion of an old version of SKIP (draft-...-skip-03) w.r.t. multicast to be worth reading. -- Lewis http://www.cs.umass.edu/~lmccarth/lmkey.asc From owner-ipsec Thu Nov 21 18:23:55 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA07485 for ipsec-outgoing; Thu, 21 Nov 1996 18:23:51 -0500 (EST) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3.0.32.19961121114020.00979840@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Nov 1996 18:25:28 -0500 To: Bob Monsour From: Stephen Kent Subject: Re: Packet-by-packet compression within IPSec Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Bob, I have no objections to your proposal, and it certainly can be easily integrated into the newly revised ESP spec. We also can allow for an optional, variable length field in front of the payload, that contains any per-packet data needed for a specific algorithm. This is easy to include in the ESP spec, with SA negotiation determining the presence or absence of the field and its size. The only issue,is how we deal with the possible requirement to support any specific compression protocols. From an interoperability perspective, we need to address this aspect of the standards, and that, I believe, is the basis for concern in terms of delaying deployment of this technology. Steve From owner-ipsec Thu Nov 21 19:00:35 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA07513 for ipsec-outgoing; Thu, 21 Nov 1996 19:00:19 -0500 (EST) Message-Id: <199611211956.TAA15713@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost.lkg.dec.com didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: rgm3@chrysler.com Cc: ipsec@tis.com Subject: Re: IPsec Interoperability Week #1 In-Reply-To: Your message of "Thu, 21 Nov 1996 16:35:41 EST." <3.0b36.32.19961121163033.0093be20@pop3hub.is.chrysler.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Nov 1996 19:56:21 +0000 From: Matt Thomas Sender: owner-ipsec@ex.tis.com Precedence: bulk I don't about others but Jan 6th is effectively the week after next for me. Nov 25th Thanksgiving week Dec 2st UNH IPv6 testing Dec 9th the IETF in San Jose Dec 16th nothing Dec 23rd Christmas Dec 30th New Years Jan 6th IPsec testing To get travel, systems, etc. ready by Jan 6th is going to be difficult at best. I think you should really consider moving the testing date out 2 week if you can. -- Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. From owner-ipsec Thu Nov 21 19:22:46 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA07538 for ipsec-outgoing; Thu, 21 Nov 1996 19:21:50 -0500 (EST) Message-Id: <3.0.32.19961121162316.00939ea0@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 21 Nov 1996 16:23:35 -0800 To: Stephen Kent From: Bob Monsour Subject: Re: Packet-by-packet compression within IPSec Cc: Bob Monsour , ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 06:25 PM 11/21/96 -0500, Stephen Kent wrote: >Bob, > > I have no objections to your proposal, and it certainly can be >easily integrated into the newly revised ESP spec. We also can allow for >an optional, variable length field in front of the payload, that contains >any per-packet data needed for a specific algorithm. This is easy to >include in the ESP spec, with SA negotiation determining the presence or >absence of the field and its size. Thanks. FYI, the only per-packet data I am imagining for our particular proposal would be a single byte to contain a compressed/uncompressed bit. This is needed to handle the case where the source data expands and you want to instead send the original uncompressed data. In this case, you would set the bit saying that the particular packet is uncompressed, even though the SPI specifies that compression is an active function for this channel. >The only issue,is how we deal with the >possible requirement to support any specific compression protocols. When you say, "...possible requirement to support any specific compression protocols.", I'm not sure I understand the issue. Do you mean the minimum or mandatory support levels for compression in IPSec/ESP? If so, I would expect that its optional nature precludes any such requirement. If you mean support for specific compression algorithms, I would suggest that we treat that issue in a similar manner as was done with PPP, where any number algorithms can be supported as long as there is a draft/standard document to describe how it is done in the context of IPSec/ESP. Since the specific compression algorithm that we will be proposing will be based on the LZS algorithm, it will ultimately result in an informational RFC (which is what happened in the PPP case for LZS as well). >From an interoperability perspective, we need to address this aspect of the >standards, and that, I believe, is the basis for concern in terms of >delaying deployment of this technology. Are you refering to the requirement for two interoperable implementations of compressed ESP before the document can be moved to the Draft Standard stage? Having done some recent homework on the IETF standards process, I'm guessing this is the concern. If that is indeed the case, I believe that we could easily achieve such a goal. -Bob From owner-ipsec Fri Nov 22 13:04:19 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA08702 for ipsec-outgoing; Fri, 22 Nov 1996 13:00:43 -0500 (EST) Message-Id: <2.2.32.19961122180014.00cab134@netcom8.netcom.com> X-Sender: dpalma@netcom8.netcom.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Nov 1996 10:00:14 -0800 To: ipsec@neptune.hq.tis.com From: Derek Palma Subject: Unexpected silence (Test posting) Sender: owner-ipsec@ex.tis.com Precedence: bulk Either I am now longer receiving messages for this list or there is very little discussion before an IETF. This is a test! From owner-ipsec Fri Nov 22 16:06:41 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA09104 for ipsec-outgoing; Fri, 22 Nov 1996 16:01:10 -0500 (EST) Message-Id: <3.0.32.19961122125905.00e47f40@netcom8.netcom.com> X-Sender: dpalma@netcom8.netcom.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 22 Nov 1996 12:59:54 -0800 To: ipsec@tis.com From: Derek Palma Subject: Decoupling compression and security Cc: dpalma@netcom.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk Some recent IPSEC implementation experiences and the current discussion has caused me to consider the virtues of coupling compression transforms with security. No doubt use of compression has benefits, even if only applied to a single packet. I see no problem with having compression be part of an SA. But I think it lacks some generality. The output of a compression algorithm can be larger than the input, the sender will no doubt like to selectively compress. This means the receiver must be able to receive compressed and uncompressed data. This seems independent from the SA. Howeverm, the SA setup can be used to select the compression algorithm. Generic (probably PPP like) compression transforms which stand on their own (apart from IPSEC) seemslike a more general solution. However, IPSEC is the only group who can justify using compression on a per packet basis. Would a set of IP-COMP transforms (vs IPSEC) be more appropriate? Derek From owner-ipsec Fri Nov 22 23:57:15 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id XAA09490 for ipsec-outgoing; Fri, 22 Nov 1996 23:54:51 -0500 (EST) Message-Id: <3.0.32.19961122205654.0099c100@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 22 Nov 1996 20:57:01 -0800 To: Derek Palma From: Bob Monsour Subject: Re: Decoupling compression and security Cc: ipsec@tis.com, dpalma@netcom.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 12:59 PM 11/22/96 -0800, Derek Palma wrote: >Some recent IPSEC implementation experiences and the current discussion >has caused me to consider the virtues of coupling compression >transforms with security. No doubt use of compression has >benefits, even if only applied to a single packet. > >I see no problem with having compression be part of an SA. >But I think it lacks some generality. The output of a compression >algorithm can be larger than the input, the sender will no >doubt like to selectively compress. This means the receiver >must be able to receive compressed and uncompressed data. >This seems independent from the SA. Howeverm, the SA setup >can be used to select the compression algorithm. When using packet-by-packet compression within IPSec, while an SA parameter will exist to define the compression algorithm and whether or not compression is enabled for a particular sender to receiver, the sender (as you suggest) will not want to send data when it expands. We have suggested that each compressed payload include a bit (within a one-byte field) which indicates whether or not the IP datagram is compressed or not. So, in effect, the sender operates as follows: compress the packet if it gets smaller compressed = true send it compressed else compressed = false send the packet in uncompressed form On the reciever side, it just checks the compressed/uncompressed bit to decide whether or not to attempt decompression. >Generic (probably PPP like) compression transforms which stand >on their own (apart from IPSEC) seemslike a more general solution. >However, IPSEC is the only group who can justify using compression >on a per packet basis. Would a set of IP-COMP transforms (vs IPSEC) >be more appropriate? The attractive part of PPP-like compression solutions is that operate over a connection-oriented protocol and therefore can compress across multiple packets, realizing greater efficiencies than by doing it a packet at a time. Unfortunately, we don't have that luxury in IP. At an even higher layer, say SSL, there again is a connection-oriented protocol and compression can indeed be done over a series of transmitted packets. Once equipped with the packet-by-packet mode of compression, I would suspect that if there is sufficient interest and energy in the working group, some effort could be put forth to figure out how to reliably compress across multiple IP datagrams. How would you see an IP-COMP transform operating? Bob Monsour rmonsour@earthlink.net From owner-ipsec Sat Nov 23 16:25:14 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA09748 for ipsec-outgoing; Sat, 23 Nov 1996 16:18:53 -0500 (EST) Message-Id: <2.2.16.19961123211820.2e271408@pop3.pn.com> X-Sender: rodney@pop3.pn.com X-Mailer: Windows Eudora Pro Version 2.2 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 23 Nov 1996 16:18:20 -0500 To: dpalma@netcom.com From: Rodney Thayer Subject: Re: Decoupling compression and security Cc: ipsec@tis.com Sender: owner-ipsec@ex.tis.com Precedence: bulk Have you looked at the draft I did in July? What you're talking about sounds like the direction I was headed. How would you add/change what I proposed? >X-Sender: rmonsour@earthlink.net >Date: Fri, 22 Nov 1996 20:57:01 -0800 >To: Derek Palma >From: Bob Monsour >Subject: Re: Decoupling compression and security >Cc: ipsec@tis.com, dpalma@netcom.com >Sender: owner-ipsec@ex.tis.com > >At 12:59 PM 11/22/96 -0800, Derek Palma wrote: >>Some recent IPSEC implementation experiences and the current discussion >>has caused me to consider the virtues of coupling compression >>transforms with security. No doubt use of compression has >>benefits, even if only applied to a single packet. >> >>I see no problem with having compression be part of an SA. >>But I think it lacks some generality. The output of a compression >>algorithm can be larger than the input, the sender will no >>doubt like to selectively compress. This means the receiver >>must be able to receive compressed and uncompressed data. >>This seems independent from the SA. Howeverm, the SA setup >>can be used to select the compression algorithm. > >When using packet-by-packet compression within IPSec, while an SA parameter >will exist to define the compression algorithm and whether or not >compression is enabled for a particular sender to receiver, the sender (as >you suggest) will not want to send data when it expands. We have suggested >that each compressed payload include a bit (within a one-byte field) which >indicates whether or not the IP datagram is compressed or not. So, in >effect, the sender operates as follows: > > compress the packet > if it gets smaller > compressed = true > send it compressed > else > compressed = false > send the packet in uncompressed form > >On the reciever side, it just checks the compressed/uncompressed bit to >decide whether or not to attempt decompression. > >>Generic (probably PPP like) compression transforms which stand >>on their own (apart from IPSEC) seemslike a more general solution. >>However, IPSEC is the only group who can justify using compression >>on a per packet basis. Would a set of IP-COMP transforms (vs IPSEC) >>be more appropriate? > >The attractive part of PPP-like compression solutions is that operate over >a connection-oriented protocol and therefore can compress across multiple >packets, realizing greater efficiencies than by doing it a packet at a >time. Unfortunately, we don't have that luxury in IP. At an even higher >layer, say SSL, there again is a connection-oriented protocol and >compression can indeed be done over a series of transmitted packets. Once >equipped with the packet-by-packet mode of compression, I would suspect >that if there is sufficient interest and energy in the working group, some >effort could be put forth to figure out how to reliably compress across >multiple IP datagrams. > >How would you see an IP-COMP transform operating? > > >Bob Monsour >rmonsour@earthlink.net > > Rodney Thayer +1 617 332 7292 Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA Fax: +1 617 332 7970 http://www.shore.net/~sable Communications Software Development From owner-ipsec Mon Nov 25 03:40:13 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA10369 for ipsec-outgoing; Mon, 25 Nov 1996 03:32:24 -0500 (EST) Date: Mon, 25 Nov 1996 10:34:24 +0200 (EET) From: Santeri Paavolainen X-Sender: santtu@hutcs To: ipsec@tis.com Subject: Re: Decoupling compression and security In-Reply-To: <3.0.32.19961122205654.0099c100@earthlink.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk > When using packet-by-packet compression within IPSec, while an SA parameter > will exist to define the compression algorithm and whether or not > compression is enabled for a particular sender to receiver, the sender (as > you suggest) will not want to send data when it expands. We have suggested > that each compressed payload include a bit (within a one-byte field) which > indicates whether or not the IP datagram is compressed or not. So, in > effect, the sender operates as follows: > > compress the packet > if it gets smaller > compressed = true > send it compressed > else > compressed = false > send the packet in uncompressed form > > On the reciever side, it just checks the compressed/uncompressed bit to > decide whether or not to attempt decompression. If the compression was another IPSEC transformation there would be no need for such a "bit" in the actual _security_ transformation data. Have everybody forgotten that applying transformations on a packet is still optional? If I want an option of not applying a packet compression transformation I can just not apply it -- no need for any information bits in the packet. As an example, there is two transformations defined, COMP for compression and CRYPT for some crypto. If I get a acceptable compression ratio for a packet, I leave the compression transformation on and pass the packet to the rest of the transformation chain, finally giving a packet like CRYPT(COMP(packet)) OTOH, if the compression ratio is unacceptable, just leave the compression layer off: CRYPT(packet) Because the receiver sees only SPIs of the various layers, it will first decrypt and either get a regular (not compressed) packet, or a compressed packet which will then have to be uncompressed to gain the final packet. Of course, this would mean there is overhead of SPI vs. "bit", but I think the generality is a clear plus. What if you later find out the cryptographic transformation you have embedded the compression layer is not secure? Also, there is no clear way how to interoperate between different transformations which have the same compression engine (you must remember that each transformation should be self-contained from the coding point of view). Also, some persons might want compression, and only that. I imagine there would be plenty of situations (two computers connected by a secure network/line) where getting "compression" out of IPSEC layer could not be justified because of the extra costs because the compression would imply (cpu-intensive) cryptographic methods. Of course, it is another matter whether compression should be included in the IPSEC layer at all. PS. In the IP Authentication Header draft (4 June 1996, are there newer versions?) at chapter 3, the combination of AH(AH(...)) is said to be invalid at all times. Why? Take the following situation as an example where AH(AH(...)) could be used: A VPN network, eg. an intranet created by establishing a secure tunnel between two separate networks. Typically, the VPN routers apply some IPSEC AH+ESP transformation on a packet before sending it through the internet network. But, there can be a case when the VPN router does not want to encrypt a packet, but still requires authentication. If there are IPSEC-capable hosts within these two parts of the intranet talking to each other with some AH+ESP transformations the VPN routers will get packets in the form of AH(ESP(...)). If the VPN routers have knowledge about the used ESP (by acting as a middlemen in key management routine, for example) an deem it as "secure enough" they might not want to apply a second layer of ESP, because it would be unnecessary. Still they want to apply an AH, so that the other VPN router can confirm the authenticity of the packet coming from the internet (that it really is coming from the other VPN router). This leads to a situation where the packet would look like AH(AH(ESP(...))) when send to the internet. But this seems not to be allowed by the draft! -- sjpaavol@cc.Helsinki.FI I have become death, destroyer of the worlds. From owner-ipsec Mon Nov 25 07:20:22 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA10567 for ipsec-outgoing; Mon, 25 Nov 1996 07:18:20 -0500 (EST) Date: 25 Nov 96 09:27:26 +0300 From: "RIITTINEN HEIKKI" Subject: RE:Packet-by-packet compression within IPSec Reply-To: heikki.riittinen@icl.fi In-Reply-To: Packet-by-packet compression within IPSec Message-Id: <9611250927.aa26@fin1401.icl.fi> To: ipsec@tis.com, rmonsour@earthlink.net Content-Type: text/plain; charset=US-ASCII Sender: owner-ipsec@ex.tis.com Precedence: bulk Bob Monsour: >MY PROPOSAL > >The essence of my proposal is to add simple, straightforward language >(provided below) to the ESP draft which allows compression to be performed >on a packet-by-packet basis (keeping *NO* history or state information >across packets). The use of compression would be negotiated as an security >association parameter along with the algorithm to be employed. The ESP >payload data would simply be either compressed or uncompressed and *NO* >additional fields (in the header *OR* in the payload) would be required to >support it. This is the simplest form of compression support. >Bob Monsour >rmonsour@earthlink.net I fully support the proposal. We have implemented a prototype of a proprietary "encryption" (stateless compression and standard encryption) that fulfills all the requirements set by the proposal. Heikki.Riittinen@teamw.com from Europe From owner-ipsec Mon Nov 25 10:06:21 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA11013 for ipsec-outgoing; Mon, 25 Nov 1996 10:02:53 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; From: Internet-Drafts@ietf.org cc: ipsec@tis.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-mcdonald-simple-ipsec-api-00.txt Date: Mon, 25 Nov 1996 09:38:09 -0500 Message-ID: <9611250938.aa05672@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Simple IP Security API Extension to BSD Sockets Author(s) : D. McDonald Filename : draft-mcdonald-simple-ipsec-api-00.txt Pages : 9 Date : 11/22/1996 In order to take advantage of the IP Security Architecture [Atk95], an application should be able to tell the system what IP-layer security services it needs to function with some degree of confidence. A simple API that also allows simple security association policy to be set is presented here. This document descends from earlier work performed in the U. S. Naval Research Laboratory's IPv6 and IP security implementation [AMPMC96]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mcdonald-simple-ipsec-api-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-mcdonald-simple-ipsec-api-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-mcdonald-simple-ipsec-api-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961122151515.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mcdonald-simple-ipsec-api-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mcdonald-simple-ipsec-api-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961122151515.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Mon Nov 25 15:38:13 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA11709 for ipsec-outgoing; Mon, 25 Nov 1996 15:35:58 -0500 (EST) Message-ID: <329A0357.15FB@mit.edu> Date: Mon, 25 Nov 1996 15:36:39 -0500 From: "Jeffrey I. Schiller" Organization: Massachusetts Institute of Technology X-Mailer: Mozilla 3.0 (X11; U; IRIX 5.2 IP22) MIME-Version: 1.0 To: ipsec@tis.com Subject: Documents Approved at last IESG Telechat Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@ex.tis.com Precedence: bulk >From the IESG (as yet unpublished) minutes. This is an *unofficial* announcement: o The IESG approved publication of HMAC-MD5 IP Authentication with Replay Prevention as a Proposed Standard. Steve to send announcement. o The IESG approved publication of HMAC-SHA IP Authentication with Replay Prevention as a Proposed Standard. Steve to send announcement. o The IESG approved the reclassification of RFC1828, IP Authentication using Keyed MD5, from Proposed Standard to Historic status. o The IESG approved publication of HMAC: Keyed-Hashing for Message Authentication as an Informational RFC. Steve to send announcement. -Jeff From owner-ipsec Tue Nov 26 07:24:44 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA12729 for ipsec-outgoing; Tue, 26 Nov 1996 07:18:40 -0500 (EST) Date: Mon, 25 Nov 96 18:59:16 EST From: "Whelan, Bill" Message-Id: <9610258489.AA848977264@netx.nei.com> To: ipsec@tis.com Subject: AH (without ESP) on a secure gateway Sender: owner-ipsec@ex.tis.com Precedence: bulk Last month there was a question regarding ESP and AH on a secure gateway as in the following model. secure (untrusted) secure hostA gatewayA---------------------------gatewayB hostB | | | | ---------- ----------- (trusted subnet) (trusted subnet) My question is whether AH on a secure gateway even makes sense at all if ESP is not being performed. Consider hostA sending a packet to hostB. If gatewayA places an AH on the packet, it would appear as if it was authenticated by hostA, not a good idea in my mind. How do other secure gateway implementations handle this situation? Bill Whelan From owner-ipsec Tue Nov 26 10:23:32 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13855 for ipsec-outgoing; Tue, 26 Nov 1996 10:21:01 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-isakmp-06.txt, .ps Date: Tue, 26 Nov 1996 09:19:21 -0500 Message-ID: <9611260919.aa19100@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Internet Security Association and Key Management Protocol (ISAKMP) Author(s) : D. Maughan, M. Schertler, M. Schneider, J. Turner Filename : draft-ietf-ipsec-isakmp-06.txt, .ps Pages : 78 Date : 11/25/1996 This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. A Security Association protocol that negotiates, establishes, modifies and deletes Security Associations and their attributes is required for an evolving Internet, where there will be numerous security mechanisms and several options for each security mechanism. The key management protocol must be robust in order to handle public key generation for the Internet community at large and private key requirements for those private networks with that requirement. The Internet Security Association and Key Management Protocol (ISAKMP) defines the procedures for authenticating a communicating peer, creation and management of Security Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks). All of these are necessary to establish and maintain secure communications (via IP Security Service or any other security protocol) in an Internet environment. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-isakmp-06.txt". Or "get draft-ietf-ipsec-isakmp-06.ps". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-isakmp-06.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-isakmp-06.txt". Or "FILE /internet-drafts/draft-ietf-ipsec-isakmp-06.ps". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125101043.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-isakmp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-isakmp-06.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125101043.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Tue Nov 26 10:28:38 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA13886 for ipsec-outgoing; Tue, 26 Nov 1996 10:28:30 -0500 (EST) Message-Id: <199611261528.KAA13886@portal.ex.tis.com> From: Greg Carter To: "'ipsec@tis.com'" Cc: "'isakmp-oakley@cisco.com'" Subject: PF_KEY Date: Tue, 26 Nov 1996 10:12:49 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24 Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi All, Can anyone give me an idea of the exceptance of PF_KEY and the platforms it is/will be supported on. Thanks. ---- Greg Carter Nortel Secure Networks - Entrust carterg@entrust.com From owner-ipsec Tue Nov 26 11:11:22 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14141 for ipsec-outgoing; Tue, 26 Nov 1996 11:11:02 -0500 (EST) Message-Id: <199611261611.LAA14141@portal.ex.tis.com> From: Greg Carter To: "'ipsec@tis.com'" Cc: "'isakmp-oakley@cisco.com'" Subject: sorry, spelling... Date: Tue, 26 Nov 1996 11:01:09 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24 Sender: owner-ipsec@ex.tis.com Precedence: bulk Obviously I can't spell and I should really reread before I hit send, I meant "acceptance" of PF_KEY. Bye. ---- Greg Carter Nortel Secure Networks - Entrust carterg@entrust.com From owner-ipsec Tue Nov 26 11:20:13 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA14229 for ipsec-outgoing; Tue, 26 Nov 1996 11:20:09 -0500 (EST) Message-Id: <96Nov26.112218est.30786-1@janus.border.com> To: ipsec@tis.com Subject: Re: I-D ACTION:draft-ipsec-ipsec-doi-01.txt References: <9611200956.aa14139@ietf.org> In-reply-to: Internet-Drafts's message of "Wed, 20 Nov 1996 09:56:50 -0500". <9611200956.aa14139@ietf.org> From: "C. Harald Koch" Organization: Secure Computing Canada Ltd. Phone: +1 416 368 7157 X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Tue, 26 Nov 1996 11:22:20 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk Some quibbles regarding the IPsec DOI definitions, that I just tripped over while trying to define a text-based SA exchange format. Basically, if we're going to a) name and b) number protocol entities, we need to ensure that the list is both intelligible and complete. 4.4.3 IPSEC AH Transform Values Transform Value --------- ----- RESERVED 0 AH_1828 1 AH_HMAC_MD5_REPLAY 2 AH_MHAC_SHA_REPLAY 3 I object to the use of RFC numbers in the name of the transform; it's either meaningless or obscure, depending on who you ask. AH_MD5 would be better than AH_1828. The "AH_HMAC_MD5" transform is missing from the list. While this transform never became an RFC, it is in use by several vendors, and so needs an identifier for proper interoperability. (Yes, it's a proper subset of AH_HMAC_MD5_REPLAY, But to support historical implementations, I think it needs to be kept separate. I'm willing to negotiate on this one :-) 4.4.4 IPSEC ESP Transform Identifiers Transform ID Value ------------ ----- RESERVED 0 ESP_1829_TRANSPORT 1 ESP_1829_TUNNEL 2 ESP_DES_CBC_HMAC_REPLAY 3 Again, I object to the use of RFC numbers in the name; IMHO, these should be "ESP_DES_CBC_TRANSPORT" and "ESP_DES_CBC_TUNNEL". (And I though the "transport" v.s. "tunnel" distinction was an RFC 1827 thing; if so, shouldn't we be consistent here?) ESP_3DES_CBC is missing (RFC 1851). Again, there are vendors using this already; an ID and number are required for interoperability. :-) -- C. Harald Koch | Senior System Developer, Secure Computing Canada Ltd. chk@border.com | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8 +1 416 368 7157 (voice) | "Madness takes its toll. Please have exact change." +1 416 368 7789 (fax) | -Karen Murphy From owner-ipsec Tue Nov 26 12:56:36 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA14512 for ipsec-outgoing; Tue, 26 Nov 1996 12:54:00 -0500 (EST) Date: Tue, 26 Nov 1996 11:24:51 -0600 (CST) From: Tom Markham Message-Id: <199611261724.LAA29519@jasmin.sctc.com> To: bwhelan@nei.com CC: ipsec@tis.com Subject: RE: AH (without ESP) on a secure gateway Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill BW> Last month there was a question regarding ESP and AH on a secure gateway as in the following model. secure (untrusted) secure hostA gatewayA---------------------------gatewayB hostB | | | | ---------- ----------- (trusted subnet) (trusted subnet) BW> My question is whether AH on a secure gateway even makes sense at all if ESP is not being performed. Consider the case where one gateway is in a country like France which does not allow encryption. An organization could still use AH to authenticate that the source of the packets was another secure gateway belonging to the organization. BW> Consider hostA sending a packet to hostB. If gatewayA places an AH on the packet, it would appear as if it was authenticated by hostA, not a good idea in my mind. The receiving gateway/host knows (should know) that the AH keying material is held by Gateway A and not Host A. If the receiving gateway/host does not know which devices it shares keying material with, you have a key management problem. Tom Markham From owner-ipsec Tue Nov 26 13:01:17 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA14528 for ipsec-outgoing; Tue, 26 Nov 1996 13:01:00 -0500 (EST) Message-Id: <3.0.32.19961126100305.00987ae0@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 26 Nov 1996 10:03:12 -0800 To: Santeri Paavolainen From: Bob Monsour Subject: Re: Decoupling compression and security Cc: ipsec@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk At 10:34 AM 11/25/96 +0200, Santeri Paavolainen wrote: ... >If the compression was another IPSEC transformation there would be no >need for such a "bit" in the actual _security_ transformation >data. Have everybody forgotten that applying transformations on a >packet is still optional? If I want an option of not applying a packet >compression transformation I can just not apply it -- no need for any >information bits in the packet. As an example, > >there is two transformations defined, COMP for compression and CRYPT >for some crypto. If I get a acceptable compression ratio for a packet, >I leave the compression transformation on and pass the packet to the >rest of the transformation chain, finally giving a packet like > > CRYPT(COMP(packet)) > >OTOH, if the compression ratio is unacceptable, just leave the >compression layer off: > > CRYPT(packet) > >Because the receiver sees only SPIs of the various layers, it will >first decrypt and either get a regular (not compressed) packet, or a >compressed packet which will then have to be uncompressed to gain the >final packet. > >Of course, this would mean there is overhead of SPI vs. "bit", but I >think the generality is a clear plus. What if you later find out the >cryptographic transformation you have embedded the compression layer >is not secure? Also, there is no clear way how to interoperate between >different transformations which have the same compression engine (you >must remember that each transformation should be self-contained from >the coding point of view). ... This is more than just an issue of the overhead of an SPI vs. a "bit". Let me explain by way of example. Let's say that a security association has been set up for traffic traveling from a sender to a receiver. Thus the SPI for traffic in that direction is specified. Let's also say that the SPI specifies the use of a particular set of compression, encryption and authentication algorithms. Then, let's say that the sender wants to send a datagram to the receiver. Suppose the data expands. The sender would then want to send the original uncompressed form of the data. Under our proposal, all the sender would have to do is to change a bit at the start of the payload. Under what you propose, the SPI is no longer valid since the reciever will erroneously attempt to decompress raw data. Your method would thus require that a new SPI be used which would likely require some renegotiation between the sender and receiver as to which algorithms and modes are to be used for the connection. Bob Monsour rmonsour@earthlink.net From owner-ipsec Tue Nov 26 14:29:18 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id OAA14778 for ipsec-outgoing; Tue, 26 Nov 1996 14:28:06 -0500 (EST) Message-Id: <199611261929.OAA01715@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: "Whelan, Bill" Cc: ipsec@tis.com Subject: Re: AH (without ESP) on a secure gateway In-Reply-To: bwhelan's message of Mon, 25 Nov 1996 18:59:16 -0500. <9610258489.AA848977264@netx.nei.com> Date: Tue, 26 Nov 1996 14:28:31 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > My question is whether AH on a secure gateway even makes sense at all > if ESP is not being performed. > > Consider hostA sending a packet to hostB. If gatewayA places an AH on > the packet, it would appear as if it was authenticated by hostA, not a > good idea in my mind. If a router places an AH on the packet, it must do so using an outbound SPI to some other host/router. The corresponding inbound SPI on that host should specify that the sender is a gateway, not a host. The "policy engines" on each end need to be sophisticated enough to deal with things like this. In particular, if ip-address based access controls are in use, then the policy engine should probably do consistency checks between the SPI and the source address.. - Bill From owner-ipsec Tue Nov 26 15:27:52 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA15076 for ipsec-outgoing; Tue, 26 Nov 1996 15:27:03 -0500 (EST) To: IETF-Announce:;;;;@tis.com@tis.com;;; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipsec@tis.com From: The IESG Subject: Protocol Action: HMAC-MD5 IP Authentication with Replay Prevention to Proposed Standard Date: Tue, 26 Nov 1996 13:09:54 -0500 Message-ID: <9611261309.aa11679@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk The IESG has approved the Internet-Drafts 1. HMAC-MD5 IP Authentication with Replay Prevention and 2. HMAC-SHA IP Authentication with Replay Prevention as Proposed Standards. The IESG also approved the reclassification of RFC1828, IP Authentication using Keyed MD5, from Proposed Standard to Historic. These documents are the product of the IP Security Protocol Working Group. The IESG contact person is Jeffrey Schiller. Technical Summary These documents describe two similar Keyed Hashes (one based on MD5 and the other based on SHA) for use in IP Security's Authentication Header (both IPv4 and IPv6). Hashes such as MD5 and SHA were designed to be used as "keyless" hashes which can be used in digital signature systems such as the RSA system and the U.S. Digital Signature Standard (DSS). An obvious approach to using them as "keyed" hashes has involved either prepending the data to be hashed with a secret value (key) or appending the secret value after the data to be hashed (or both). However recently significant analysis work has been carried out by cryptographers as to security of keyed modes of these hashes. The keyed hash mechanism described in these documents benefits from this analytical experience and is therefore believed to be much stronger than the simplistic approaches taken to date in the Internet community (both in AH and SNMP). Working Group Summary These documents are the work product of the IP Security Working Group. The group has come to consensus that these hashes are good approaches to the keyed hash function required by the Authentication Header. Protocol Quality This protocol has been reviewed by Jeffrey I. Schiller, Security Area Director. From owner-ipsec Tue Nov 26 16:35:03 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA15139 for ipsec-outgoing; Tue, 26 Nov 1996 16:31:38 -0500 (EST) Message-Id: <9611262133.AA20640@hpcc103.corp.hp.com> To: Tom Markham Cc: ipsec@tis.com Subject: Re: AH (without ESP) on a secure gateway In-Reply-To: Your message of Tue, 26 Nov 1996 11:24:51 -0600. <199611261724.LAA29519@jasmin.sctc.com> Date: Tue, 26 Nov 1996 13:33:49 -0800 From: "\"\"Yan-Fa LI \"\"" Sender: owner-ipsec@ex.tis.com Precedence: bulk Hi Bill and Tom, > > Bill > > BW> Last month there was a question regarding ESP and AH on a secure > gateway as in the following model. > > > secure (untrusted) secure > hostA gatewayA---------------------------gatewayB hostB > | | | | > ---------- ----------- > (trusted subnet) (trusted subnet) > > > BW> My question is whether AH on a secure gateway even makes sense at all > if ESP is not being performed. > > > Consider the case where one gateway is in a country like France which > does not allow encryption. An organization could still use AH to > authenticate that the source of the packets was another secure gateway > belonging to the organization. This is exactly what I would like AH only support for. It would give us the extra capabilities of Anti-Spoofing and Integrity checking which would be a big win over today's infrastructure. There are some instances where privacy is not a big deal, or where export/import usage restrictions forbid the use of strong cryptography. > > BW> Consider hostA sending a packet to hostB. If gatewayA places an AH on > the packet, it would appear as if it was authenticated by hostA, not a > good idea in my mind. > > The receiving gateway/host knows (should know) that the AH keying material > is held by Gateway A and not Host A. If the receiving gateway/host > does not know which devices it shares keying material with, you have a > key management problem. > > Tom Markham I don't believe this is the case in some of the gateway products which are available today. Some of the gateway products transparently proxy for hosts in the trusted network. This is the fundamental weak spot in gateway solutions. They assume: - your trusted network is secure - you do not have users spoofing the addresses of other users within the trusted network. The strength of this approach is you can support legacy devices without making any changes to them. Gateways are a compromise between security and medium-term implementation realities. Does anyone know if there are specific set up messages in the ISAKMP-OAKLEY protocol to identify which architectural case a pair of communicating peers is in ? i.e. Host-to-Host, Host-to-Gateway, and Gateway-to-Gateway. For example, if one knew the conversation was between two gateways, one could accept the risks of this architectural model and just negotiate a pair of SAs for the communication with all traffic between the networks being multiplexed over a single TCP/IP connection. Much more efficient for the gateways. However if we do this are we making it easier for an attacker to perform cryptanalysis on our connection ? If you implement the reverse situation, where a new SA pair is negotiated for every IP pair that attempts communication between the networks, this could quickly bog down the gateways while they authenticate public keys exchanges, context switch between secret session keys and encrypt and decrypt packets. One could argue that this will happen anyway in the Host-to-Gateway scenario, and one needs to engineer for this case, so why not make it the general one ? Right now, with gateway solutions, I think that Host-to-Host is how they operated. I would interested in finding out if there is a way to identify which model is in use. Also, if I have made any gross conceptual mistakes in this text, I would appreciate being helped to understand why. Thanks for your time. Sincerely, Yan ___________________________________________________________________ My views do not necessarily represent those of the Hewlett Packard Company and should be taken with a large dose of salt or whatever passes for sodium in your neck of the woods/universe/continuum/etc... ___________________________________________________________________ From owner-ipsec Tue Nov 26 16:53:00 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA15168 for ipsec-outgoing; Tue, 26 Nov 1996 16:51:34 -0500 (EST) Date: Tue, 26 Nov 96 13:44:00 PST From: John H Wilson Message-ID: To: ipsec@tis.com Subject: ipsec implementations Sender: owner-ipsec@ex.tis.com Precedence: bulk I would like to get an idea of what Win95 or NT implementations of IPSEC are either planned or are available already..... ......Company, availability date, content, API, If any implementers would be willing to provide this type of information, I'd apreciate it. john_h_wilson@ccm.jf.intel.com From owner-ipsec Tue Nov 26 17:29:50 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA15215 for ipsec-outgoing; Tue, 26 Nov 1996 17:28:04 -0500 (EST) Date: Tue, 26 Nov 1996 17:30:19 -0500 (EST) Message-Id: <199611262230.RAA27739@carp.morningstar.com> From: Ben Rogers To: Bill Sommerfeld Cc: "Whelan, Bill" , ipsec@tis.com Subject: Re: AH (without ESP) on a secure gateway In-Reply-To: <199611261929.OAA01715@thunk.orchard.medford.ma.us> References: <9610258489.AA848977264@netx.nei.com> <199611261929.OAA01715@thunk.orchard.medford.ma.us> Reply-To: ben@ascend.com (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill Sommerfeld writes: > > My question is whether AH on a secure gateway even makes sense at all > > if ESP is not being performed. > > > > Consider hostA sending a packet to hostB. If gatewayA places an AH on > > the packet, it would appear as if it was authenticated by hostA, not a > > good idea in my mind. > It seems to me that gatewayA should never try to place an AH, nor do an ESP encapsulation on the packet using transport mode (assuming that gatewayA did not originate the packet). A gateway that put IPSEC headers on packets in transport mode would not only cause confusing problems like this, but would have severe problems dealing with fragmented packets. > The "policy engines" on each end need to be sophisticated enough to > deal with things like this. In particular, if ip-address based access > controls are in use, then the policy engine should probably do > consistency checks between the SPI and the source address.. Why? I believe the RFC states that the Security Association(SA) is chosen using only the destination address and the SPI. It doesn't seem to be illegal for several hosts to send us packets using the same Security Association (SPI). It makes sense to only check the headers on packets that are destined for the local machine. Otherwise, we would be intercepting (and probably modifying) packets not destined to that machine, and violating many of the ideas that make IP work. Thus, I don't see any reason that a gateway could use transport mode to tack on an AH to a packet from hostA to hostB. To address the original question, using the following scenario: > secure (untrusted) secure > hostA gatewayA---------------------------gatewayB hostB > | | | | > ---------- ----------- > (trusted subnet) (trusted subnet) the packets should look like (on the untrusted segment) hostA -> hostB : IP_HEADER(gateA->gateB) AH(gateA->gateB) IP_HEADER(hostA->gateB) AH(hostA->gateB) IP_HEADER(hostA->hostB) PACKET hostA -> gateB : IP_HEADER(gateA->gateB) AH(gateA->gateB) IP_HEADER(hostA->gateB) AH(hostA->gateB) PACKET or IP_HEADER(gateA->gateB) AH(gateA->gateB) IP_HEADER(hostA->gateB) AH(hostA->gateB) IP_HEADER(hostA->gateB) PACKET gateA -> gateB : IP_HEADER(gateA->gateB) AH(gateA->gateB) PACKET or IP_HEADER(gateA->gateB) AH(gateA->gateB) IP_HEADER(gateA->gateB) PACKET gateA -> hostB IP_HEADER(gateA->gateB) AH(gateA->gateB) IP_HEADER(gateA->hostB) PACKET to avoid any ambiguity. Note that this never allows AH, AH and assumes that no machine will attempt to de-encapsulate a packet whose destination address is not assigned to that machine. As a result, none of the machines ever has to make any complicated policy decisions (on whether to look at the AH, or how to handle the assignment of SPI's). I feel that this is the best way to handle all such multiple encapsulations. ben From owner-ipsec Tue Nov 26 18:02:29 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15279 for ipsec-outgoing; Tue, 26 Nov 1996 18:00:36 -0500 (EST) Message-Id: <199611262302.SAA01876@thunk.orchard.medford.ma.us> X-Authentication-Warning: thunk.orchard.medford.ma.us: sommerfeld owned process doing -bs To: ben@ascend.com (Ben Rogers) Cc: "Whelan, Bill" , ipsec@tis.com Subject: Re: AH (without ESP) on a secure gateway In-Reply-To: ben's message of Tue, 26 Nov 1996 17:30:19 -0500. <199611262230.RAA27739@carp.morningstar.com> Date: Tue, 26 Nov 1996 18:02:47 -0500 From: Bill Sommerfeld Sender: owner-ipsec@ex.tis.com Precedence: bulk > > The "policy engines" on each end need to be sophisticated enough to > > deal with things like this. In particular, if ip-address based access > > controls are in use, then the policy engine should probably do > > consistency checks between the SPI and the source address.. > > Why? I believe the RFC states that the Security Association(SA) is > chosen using only the destination address and the SPI. It doesn't seem > to be illegal for several hosts to send us packets using the same > Security Association (SPI). All things which aren't illegal aren't necessarily also good ideas. > It makes sense to only check the headers on packets that are destined > for the local machine. Otherwise, we would be intercepting (and > probably modifying) packets not destined to that machine, and violating > many of the ideas that make IP work. Thus, I don't see any reason that > a gateway could use transport mode to tack on an AH to a packet from > hostA to hostB. Let's consider the case where you're attempting to add AH/ESP protection to an existing network which *currently uses IP-address based access controls*. Naturally, you don't want to create security holes while doing this. Let's assume you have a network of cooperating but mutually suspicious organizations, like the auto industry net which Bob Moskowitz is building. For simplicity, let's assume orgs A, B, and C, connected in a "full mesh" of leased lines (A-B, A-C, and B-C). Assume filtering routers on each leased line, so that C can't impersonate B when communicating with A. We now want to migrate to IPSEC without causing a flag day. Let's start by replacing the leased line between C and A with a tunnel over an untrusted network protected with AH or ESP. What stops C from tunnelling a packet to A with a source address on B's network? You need a policy check that the packet emerging from the tunnel is from a source address which is allowed to use that particular tunnel.. For a particularly extreme example, assume that A and B are divisions of the same company, and that C is a division of a different company which is simultaneously a supplier and a competitor of the first company. - Bill From owner-ipsec Tue Nov 26 18:19:11 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15305 for ipsec-outgoing; Tue, 26 Nov 1996 18:19:05 -0500 (EST) Date: Tue, 26 Nov 1996 18:19:34 -0500 (EST) Message-Id: <199611262319.SAA27893@carp.morningstar.com> From: Ben Rogers To: Bill Sommerfeld Cc: ben@ascend.com (Ben Rogers), "Whelan, Bill" , ipsec@tis.com Subject: Re: AH (without ESP) on a secure gateway In-Reply-To: <199611262302.SAA01876@thunk.orchard.medford.ma.us> References: <199611262230.RAA27739@carp.morningstar.com> <199611262302.SAA01876@thunk.orchard.medford.ma.us> Reply-To: ben@ascend.com (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill Sommerfeld writes: > > Why? I believe the RFC states that the Security Association(SA) is > > chosen using only the destination address and the SPI. It doesn't seem > > to be illegal for several hosts to send us packets using the same > > Security Association (SPI). > > All things which aren't illegal aren't necessarily also good ideas. Well... It seems to me that it might be a good idea to allow IPSEC to be used over multicast packets. Then, your destination address (that of the multicast group) would be constant, but there would be many source addresses. You would need to use an AH, but that should be sufficient to verify the sender. I don't see what security a check on source address of authenticated packets adds. Of course this all changes if you are talking about the packet after it has been extracted from the tunnel. > Let's consider the case where you're attempting to add AH/ESP > protection to an existing network which *currently uses IP-address > based access controls*. Naturally, you don't want to create security > holes while doing this. > > Let's assume you have a network of cooperating but mutually suspicious > organizations, like the auto industry net which Bob Moskowitz is > building. > > For simplicity, let's assume orgs A, B, and C, connected in a "full > mesh" of leased lines (A-B, A-C, and B-C). Assume filtering routers > on each leased line, so that C can't impersonate B when communicating > with A. We now want to migrate to IPSEC without causing a flag day. > > Let's start by replacing the leased line between C and A with a tunnel > over an untrusted network protected with AH or ESP. > > What stops C from tunnelling a packet to A with a source address on > B's network? You need a policy check that the packet emerging from > the tunnel is from a source address which is allowed to use that > particular tunnel.. Unfortunately, I misinterpreted this the first time it came around. I'll diagram several "packets" to illustrate : original packet : IP_HEADER(gateC->gateA) AH(gateC->gateA) IP_HEADER(hostB->hostA) PACKET de-encapsulated packet : IP_HEADER(hostB->hostA) PACKET There are no checks that we want to do on the original packet. I was assuming that you wanted to check the source address on the original packet, which is made immaterial by checking the AH. The policy decision you are talking about is on the source address of the de-encapsulated packet, which I agree is necessary. In most cases it wouldn't be necessary because you share the tunnel with a *trusted* gateway. But in this case, there is certainly need for additional machinery to do the policy work. ben From owner-ipsec Tue Nov 26 18:28:40 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA15319 for ipsec-outgoing; Tue, 26 Nov 1996 18:28:36 -0500 (EST) Date: Tue, 26 Nov 1996 15:29:12 -0800 Message-Id: <199611262329.PAA21941@spud.ascend.com> From: Karl Fox To: Bill Sommerfeld Cc: ben@ascend.com (Ben Rogers), "Whelan, Bill" , ipsec@tis.com Subject: Re: AH (without ESP) on a secure gateway In-Reply-To: <199611262302.SAA01876@thunk.orchard.medford.ma.us> References: <199611262230.RAA27739@carp.morningstar.com> <199611262302.SAA01876@thunk.orchard.medford.ma.us> Reply-To: Karl Fox Organization: Ascend Communications Sender: owner-ipsec@ex.tis.com Precedence: bulk Bill Sommerfeld writes: > For simplicity, let's assume orgs A, B, and C, connected in a "full > mesh" of leased lines (A-B, A-C, and B-C). Assume filtering routers > on each leased line, so that C can't impersonate B when communicating > with A. We now want to migrate to IPSEC without causing a flag day. > > Let's start by replacing the leased line between C and A with a tunnel > over an untrusted network protected with AH or ESP. > > What stops C from tunnelling a packet to A with a source address on > B's network? You need a policy check that the packet emerging from > the tunnel is from a source address which is allowed to use that > particular tunnel.. Yes, that's indeed what we do. Any encrypting gateway that didn't would have a huge hole in it. I assume we're not alone in anticipating this. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 From owner-ipsec Tue Nov 26 19:11:04 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA15395 for ipsec-outgoing; Tue, 26 Nov 1996 19:10:35 -0500 (EST) Message-Id: <96Nov26.191251est.30786-1@janus.border.com> To: ben@ascend.com (Ben Rogers) cc: Bill Sommerfeld , "Whelan, Bill" , ipsec@tis.com Subject: Re: AH (without ESP) on a secure gateway References: <9610258489.AA848977264@netx.nei.com> <199611261929.OAA01715@thunk.orchard.medford.ma.us> <199611262230.RAA27739@carp.morningstar.com> In-reply-to: ben's message of "Tue, 26 Nov 1996 17:30:19 -0500". <199611262230.RAA27739@carp.morningstar.com> From: "C. Harald Koch" Organization: Secure Computing Canada Ltd. Phone: +1 416 368 7157 X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Tue, 26 Nov 1996 19:12:50 -0500 Sender: owner-ipsec@ex.tis.com Precedence: bulk In message <199611262230.RAA27739@carp.morningstar.com>, Ben Rogers writes: > > It seems to me that gatewayA should never try to place an AH, nor do an > ESP encapsulation on the packet using transport mode (assuming that > gatewayA did not originate the packet). A gateway that put IPSEC > headers on packets in transport mode would not only cause confusing > problems like this, but would have severe problems dealing with > fragmented packets. and > It makes sense to only check the headers on packets that are destined > for the local machine. Otherwise, we would be intercepting (and > probably modifying) packets not destined to that machine, and violating > many of the ideas that make IP work. Thus, I don't see any reason that > a gateway could use transport mode to tack on an AH to a packet from > hostA to hostB. I disagree. The counter example: firewalls (or John Gilmore's "cryptowalls"). I see an incredible advantage for firewalls to add IPsec information to packets, acting as proxies for the machines they're protecting. Keeps all your Security Association information in one place, where it can be easily configured and monitored. People aren't going to start ripping out their firewalls just because they have IPsec support on their hosts; firewalls allow much more security control than IPsec does. (Analogy: you don't unlock the front door just because everyone can lock their own filing cabinets). You also write: > Why? I believe the RFC states that the Security Association(SA) is > chosen using only the destination address and the SPI. It doesn't seem > to be illegal for several hosts to send us packets using the same > Security Association (SPI). A security association is *indexed* by destination address and SPI. However, It can include information about the source, including strong authentication checks, and instructions to reject packets from an invalid IP address. It's not illegal for several hosts to using the same SPI, but it's also not secure (it would allow all hosts with the same keying information to spoof each other, for example). I think it's much more likely that a host would enforce the use of different SPIs (and different keys) for each different source host. -- C. Harald Koch | Senior System Developer, Secure Computing Canada Ltd. chk@border.com | 20 Toronto Street, Suite 400, Toronto ON M5C 2B8 +1 416 368 7157 (voice) | "Madness takes its toll. Please have exact change." +1 416 368 7789 (fax) | -Karen Murphy From owner-ipsec Tue Nov 26 20:45:13 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA15500 for ipsec-outgoing; Tue, 26 Nov 1996 20:43:37 -0500 (EST) Message-Id: <199611270145.UAA06847@amaterasu.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: AH (without ESP) on a secure gateway In-reply-to: Your message of "Tue, 26 Nov 1996 18:02:47 EST." <199611262302.SAA01876@thunk.orchard.medford.ma.us> Date: Tue, 26 Nov 1996 20:44:51 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk >>>>> "Bill" == Bill Sommerfeld writes: Bill> Let's consider the case where you're attempting to add Bill> AH/ESP protection to an existing network which *currently Bill> uses IP-address based access controls*. Naturally, you Bill> don't want to create security holes while doing this. Bill> Let's assume you have a network of cooperating but mutually Bill> suspicious organizations, like the auto industry net which Bill> Bob Moskowitz is building. Let's not forget that Bob's problem is more complicated that you actually describe :-) [Bob said he was going to write a requirements document up in June. Did anyone see this from him?] But it is a good problem. Bill> What stops C from tunnelling a packet to A with a source Bill> address on B's network? You need a policy check that the Bill> packet emerging from the tunnel is from a source address Bill> which is allowed to use that particular tunnel.. The way I like to do this is to consider all tunnels to be virtual interfaces. You can make add routes, etc.. Alas, I still haven't had a chance to investigate how close that aspect (the "route add -net x.y tunnel q.r") of the NRL code is to this assumption. IP spoof checks (which you say are already in place) can handle this case without a problem. Good IP spoof checks are essentially: 1. if1 = calculate route to take to reach ip->ip_src if we had to reply. 2. if interface we received ip on == if1, then okay, otherwise it is a spoof. These checks would have to be done anyway for the leased line case for your assumption (C can not impersonate A to B) to be true. :!mcr!: | Network security consulting and Michael Richardson | contract programming WWW: mcr@sandelman.ottawa.on.ca. PGP key available. From owner-ipsec Tue Nov 26 20:46:39 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id UAA15516 for ipsec-outgoing; Tue, 26 Nov 1996 20:46:36 -0500 (EST) Message-Id: <199611270148.UAA07307@amaterasu.sandelman.ottawa.on.ca> To: ipsec@tis.com Subject: Re: AH (without ESP) on a secure gateway In-reply-to: Your message of "Tue, 26 Nov 1996 18:02:47 EST." <199611262302.SAA01876@thunk.orchard.medford.ma.us> Date: Tue, 26 Nov 1996 20:48:27 -0500 From: Michael Richardson Sender: owner-ipsec@ex.tis.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bill" == Bill Sommerfeld writes: Bill> Let's consider the case where you're attempting to add Bill> AH/ESP protection to an existing network which *currently Bill> uses IP-address based access controls*. Naturally, you Bill> don't want to create security holes while doing this. Bill> Let's assume you have a network of cooperating but mutually Bill> suspicious organizations, like the auto industry net which Bill> Bob Moskowitz is building. Let's not forget that Bob's problem is more complicated that you actually describe :-) [Bob said he was going to write a requirements document up in June. Did anyone see this from him?] But it is a good problem. Bill> What stops C from tunnelling a packet to A with a source Bill> address on B's network? You need a policy check that the Bill> packet emerging from the tunnel is from a source address Bill> which is allowed to use that particular tunnel.. The way I like to do this is to consider all tunnels to be virtual interfaces. You can make add routes, etc.. Alas, I still haven't had a chance to investigate how close that aspect (the "route add -net x.y tunnel q.r") of the NRL code is to this assumption. IP spoof checks (which you say are already in place) can handle this case without a problem. Good IP spoof checks are essentially: 1. if1 = calculate route to take to reach ip->ip_src if we had to reply. 2. if interface we received ip on == if1, then okay, otherwise it is a spoof. These checks would have to be done anyway for the leased line case for your assumption (C can not impersonate A to B) to be true. :!mcr!: | Network security consulting and Michael Richardson | contract programming WWW: mcr@sandelman.ottawa.on.ca. PGP key available. -----BEGIN PGP SIGNATURE----- Version: 2.6.2i iQBVAwUBMpudONTTll4efmtZAQHP2wIAlMI3CxpmJQAJJjGO6L7M3HhsLgudhr3L i8x4jUusxwi52NOKYvOlANCxknTLrLtxuV6N58UFFBl29v7Z9btUCQ== =bQB3 -----END PGP SIGNATURE----- From owner-ipsec Tue Nov 26 21:35:52 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id VAA15576 for ipsec-outgoing; Tue, 26 Nov 1996 21:35:20 -0500 (EST) Message-Id: <9611270235.AA11031@sol.hq.tis.com> To: cat-ietf@MIT.EDU, e-payment@bellcore.com, firewalls@greatcircle.com, ids@uow.edu.au, ietf-otp@bellcore.com, ietf-pkix@tandem.com, ietf-tls@w3.org, ietf@cnri.reston.va.us, ipsec@ans.net, pem-dev@tis.com, psrg@isi.edu, sndss-authors@isi.edu, sndss-chairs@tis.com, spki@c2.net, virus-l@lehigh.edu, www-buyinfo@allegra.att.com, www-security@ns2.rutgers.edu Subject: ANNOUNCEMENT: ISOC 1997 SYMPOSIUM NETWORK & DISTRIBUTED SYSTEM SECURITY Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <11027.849062106.1@tis.com> Date: Tue, 26 Nov 1996 21:35:11 -0500 From: "David M. Balenson" Sender: owner-ipsec@ex.tis.com Precedence: bulk --------------------------------------------------------------------------- THE INTERNET SOCIETY 1997 SYMPOSIUM ON NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS '97) 10-11 FEBRUARY 1997 SAN DIEGO PRINCESS RESORT, SAN DIEGO, CALIFORNIA This fourth annual symposium will bring together researchers, implementors, and users of network and distributed system security technologies to discuss today's important security issues and challenges. It will provide a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical, and to the extent possible, have been implemented. We hope to foster the exchange of technical information and encourage the Internet community to deploy available security technologies and develop new solutions to unsolved problems. WHY YOU SHOULD ATTEND The use of the Internet is rapidly growing and expanding into all aspects of our society. Commercial organizations are coming under increasing pressure to make their services available on-line. This in turn is increasing the need for rapid and widespread deployment of usable and effective network and distributed system security technologies. High visibility attacks on the Internet underscore the vulnerabilities of the Internet and the need to solve its security problems. There is growing concern for securing the network infrastructure itself. Recent trends in software distribution (such as Java and ActiveX technologies) have made certain attacks easier to carry out. Privacy has become an important issue for the Internet. NDSS '97 will bring together researchers, implementors, and users of network and distributed system technologies to discuss today's important security issues and challenges. We have selected the technical papers and panel presentations that describe promising new approaches to security problems that are practical, and to the extent possible, have been implemented. Topics to be addressed include Internet infrastructure and routing security, security for the World Wide Web, Java and ActiveX security, cryptographic protocols, public key management, and protection of privacy. The symposium will have a positive impact on the state of Internet security. You will have the opportunity to actively participate in the dialog. Ask questions of the speakers, raise your important issues during the panel sessions, and let other participants know of your requirements, observations, and experience in this important area. We hope to encourage the wide-scale deployment of security technologies and to promote new research that can address the currently unmet security needs of the Internet community. CONTENTS Preliminary Program Organizing Committee San Diego Princess Resort Registration Information Registration Form --------------------------------------------------------------------------- P R E L I M I N A R Y P R O G R A M SUNDAY, FEBRUARY 9 6:00 P.M. - 8:00 P.M. RECEPTION - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MONDAY, FEBRUARY 10 7:30 A.M. CONTINENTAL BREAKFAST 8:30 A.M. OPENING REMARKS 9:00 A.M. SESSION 1: THINGS THAT GO BUMP IN THE NET Chair: Stephen T. Kent (BBN Corporation, USA) Experimental Results of Covert Channel Elimination in One-Way Communication Systems, Nick Ogurtsov, Hilarie Orman, Richard Schroeppel, Sean O'Malley, and Oliver Spatscheck (University of Arizona, USA) Blocking Java Applets at the Firewall, David M. Martin Jr., Sivaramakrishnan Rajagopalan and Aviel D. Rubin (Bellcore, USA) Continuous Assessment of a Unix Configuration: Integrating Intrusion Detection & Configuration Analysis, Abdelaziz Mounji and Baudouin Le Charlier (Institut D'Informatique, Namur, BELGIUM) 10:30 A.M. BREAK 11:00 A.M. SESSION 2: PANEL: SECURITY OF DOWNLOADABLE EXECUTABLE CONTENT Chair: Aviel Rubin (Bellcore, USA) 12:30 NOON LUNCH 2:00 P.M. SESSION 3: PROTOCOL IMPLEMENTATION AND ANALYSIS Chair: Christoph Schuba (Purdue University, USA) An Interface Specification Language for Automatically Analyzing Cryptographic Protocols, Stephen H. Brackin (Arca Systems, USA) Probable Plaintext Cryptanalysis of the IP Security Protocols, Steven M. Bellovin (AT&T Research, USA) Misplaced Trust: Kerberos Version 4 Session Keys, Bryn Dole (Sun Microsystems), Steve Lodin (Delco Electronics), and Eugene Spafford (Purdue University, USA) 3:30 P.M. BREAK 4:00 P.M. SESSION 4: PANEL: SECURITY OF THE INTERNET INFRASTRUCTURE Chair: Russ Mundy (Trusted Information Systems, USA) 7:00 P.M. DINNER BANQUET - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - TUESDAY, FEBRUARY 11 7:30 A.M. CONTINENTAL BREAKFAST 8:30 A.M. SESSION 5: ROUTING SECURITY Chair: Hilarie Orman (DARPA, USA) Securing the Nimrod Routing Architecture, Karen E. Sirois and Stephen T. Kent (BBN Corporation, USA) Securing Distance-Vector Routing Protocols, Bradley R. Smith, Shree Murthy and J.J. Garcia-Luna-Aceves (University of California Santa Cruz, USA) Reducing the Cost of Security in Link-State Routing, R. Hauser, A. Przygienda and G. Tsudik (IBM and USC/ISI, USA) 10:00 A.M. BREAK 10:30 A.M. SESSION 6: SECURITY FOR THE WORLD WIDE WEB Chair: Win Treese (OpenMarket, USA) Securing Web Access with DCE, Brian C. Schimpf (Gradient Technologies, USA) PANEL: SECURITY FOR THE WORLD WIDE WEB Chair: Win Treese (OpenMarket, USA) 12:00 A.M. LUNCH 1:30 P.M. SESSION 7: PUBLIC KEY MANAGEMENT Chair: Jonathan Trostle (CyberSafe, USA) Hierarchical Organization of Certification Authorities for Secure Environments, Lourdes Lopez (Universidad Politecnica de Madrid, SPAIN) Trust Models in ICE-TEL, Andrew Young and Nada Kapidzic Cicovic (Univeristy of Salford, UNITED KINGDOM) Distributed Authentication in Kerberos Using Public Key Cryptography, Marvin Sirbu and John Chung-I Chuang (Carnegie Mellon University, USA) 3:00 P.M. BREAK 3:30 P.M. SESSION 8: PANEL: WEB PRIVACY AND ANONYMITY Chair: (To Be Determined) --------------------------------------------------------------------------- O R G A N I Z I N G C O M M I T T E E GENERAL CHAIR David Balenson, Trusted Information Systems PROGRAM CHAIRS Clifford Neuman, USC Information Sciences Institute Matt Bishop, University of California at Davis PROGRAM COMMITTEE Steve Bellovin, AT&T Research Tom Berson, Anagram Laboratories Doug Engert, Argonne National Laboratory Warwick Ford, Verisign Richard Graveman, Bellcore Li Gong, JavaSoft Burt Kaliski, RSA Laboratories Steve Kent, BBN Corporation Tom Longstaff, CERT Doug Maughan, National Security Agency Dan Nessett, 3Com Corporation Hilarie Orman, DARPA/ITO Michael Roe, University of Cambridge Christoph Schuba, Purdue University Jonathan Trostle, CyberSafe Theodore Ts'o, Massachusetts Institute of Technology Doug Tygar, Carnegie Mellon University Vijay Varadharajan, University of W. Sydney Roberto Zamparo, Telia Research PUBLICATIONS CHAIR Steve Welke, Institute for Defense Analyses LOCAL ARRANGEMENTS CHAIR Thomas Hutton, San Diego Supercomputer Center REGISTRATIONS CHAIR Torryn Brazell, Internet Society STEERING GROUP Internet Research Task Force, Privacy and Security Research Group SPONSORED BY THE INTERNET SOCIETY Donald M. Heath, President & CEO Martin Burack, Executive Director --------------------------------------------------------------------------- S A N D I E G O P R I N C E S S R E S O R T LOCATION The Symposium venue is the San Diego Princess Resort, a tropical paradise on a forty-four acre island in Mission Bay, ten minutes from the international airport. Lush gardens landscaped with hundreds of species of tropical and subtropical plants are always ablaze with color and perfect for themed group events. Charming pathways wander among sparkling waterfalls, across quaint footbridges and sleepy lagoons filled with water lilies and waterfowl. A white sand beach curves around the island for over a mile, and the award-winning grounds encompass five swimming pools and six lighted tennis courts. Spouses and family members can catch a convenient Harbor Hopper for a quick trip to Sea World. Plan to visit La Jolla, the world famous San Diego Zoo or Mexico, only 30 minutes by car or Trolley. HOUSING INFORMATION We have reserved a special block of sleeping rooms at the San Diego Princess Resort at the following rates: Lanai Patio Rooms $ 81* Lanai Garden Rooms $114 * This represents the Government Rate for San Diego. A limited number of rooms are available at this rate. Reservations must be made no later than January 13, 1997. You must present a valid government id upon check-in. Based on room type and space availability, the special group rates are applicable two days prior to and two days after the symposium. Current Room Tax is 10.5%. Check-in availability cannot be committed prior to 4:00 p.m. Check-out time is 12:00 noon. The San Diego Princess Resort will make every effort to accommodate any early arrivals, so make sure you give them your arrival time when you make your reservation. TO MAKE A RESERVATION Contact the San Diego Princess Resort at +1-800-344-2626 (+1-619-274-4630 if outside the United States). To receive the special group rates, reservations must be made no later than January 20, 1997. To receive the special goverment rate, you must make your reservation by January 13, 1997. CLIMATE February weather in San Diego is normally very pleasant. Early morning temperatures average 55 degrees while afternoon temperatures average 67 degrees. Generally, a light jacket or sweater is adequate, although, occasionally it rains. --------------------------------------------------------------------------- R E G I S T R A T I O N I N F O R M A T I O N FEES ISOC Non- Members Member* Early registration (postmarked on/before Jan. 22) $305 $345 Late registration $375 $415 REGISTRATION INCLUDES - Attendance - Symposium Proceedings - Two luncheons - Reception - Banquet - Coffee Breaks * Non-Member fee includes one year Internet Society membership. FOR MORE INFORMATION Contact Carol Gray at the Internet Society at +1-703-648-9888 or send E-mail to Ndss97reg@isoc.org. WEB PAGE Additional information about the symposium and San Diego, plus on-line registration, are available via the Web at: http://www.isoc.org/conferences/ndss97 SPONSORSHIP OPPORTUNITIES AVAILABLE! Contact Torryn Brazell at the Internet Society at +1-703-648-9888 or send E-mail to Ndss97reg@isoc.org. --------------------------------------------------------------------------- R E G I S T R A T I O N F O R M INTERNET SOCIETY SYMPOSIUM ON NETWORK AND DISTRIBUTED SYSTEM SECURITY 10-11 FEBRUARY, 1997 SAN DIEGO, CALIFORNIA, USA Fill out this form and FAX it to NDSS'97 Registration at +1-703-648-9887, send it via E-mail to Ndss97reg@isoc.org, or mail it to NDSS97, 12020 Sunrise Valley Drive, Suite 210, Reston, VA, 20191, USA PERSONAL INFORMATION __Mr __Ms __Mrs __Dr __Prof __M __Prof Dr __Dip Ing __Ing __Miss __Mlle First Name: ________________________________ MI: ____________________ Family Name: ___________________________________ __Sr __Jr __II __III Badge Name: __________________________________________________________ Please enter your name as you would like it to appear on your name tag. CONTACT INFORMATION Title: _______________________________________________________________ Organization: ________________________________________________________ Street address: ______________________________________________________ ______________________________________________________________________ City: ________________________________________________________________ State/Province: ___________________________ Postal Code: ____________ Country: _____________________________________________________________ Telephone Number (work): _____________________________________________ Telephone Number (home): _____________________________________________ Fax Number: __________________________________________________________ E-mail address: ______________________________________________________ SPECIAL NEEDS? (Vegetarian meals, wheelchair access, etc?) ______________________________________________________________________ ______________________________________________________________________ APPEAR ON REGISTRANTS LIST? ___ Please check here if you would NOT like your name included in the list of registrants. PAYMENT INFORMATION All Payments must be in United States Dollars. Conference Fee -------------- If you are an Internet Society member, you are eligible for a reduced conference registration fee. Non-member symposium attendees will receive a one year Internet Society membership as part of the non-member registration fees. Check one: On/Before After January 22 January 22 ---------- ---------- ___ Internet Society Member Fee US$ 305.00 US$ 375.00 ___ Non-Member Fee US$ 345.00 US$ 415.00 Method of Payment ----------------- Payment must be received on/before February 7, 1997 or we will be unable to pre-register you. 1. ___ Check. Make payable to the Internet Society. 2. ___ Credit Card. ___ American Express ___ Visa ___ Mastercard Name on Credit Card: ____________________________________ Credit Card Number: _____________________________________ Expiration Date: ________________________________________ 3. ___ CyberCash. Account Number: _____________________________ 4. ___ First Virtual. Account Number: _________________________ 5. ___ Wire Transfer* Bank ABA Number: 054000030 Account Number: Internet Society 148 387 10 Riggs National Bank of Virginia 950 Herndon Parkway Herndon, VA 20171 USA Wire Transfer Confirmation Number: ______________________ * Please process wire transfer before sending registration form. 6. ___ U.S. Government Purchase Order* P.O. Number: ____________________________________________ * Please fax or mail a copy of your purchase order along with your registration form. Cancellation Policy ------------------- Refunds (less a $25 processing fee) will be issued for cancellations received on/before February 7, 1997. No refunds will be issued after February 7, 1997. ------------------------------------------------------------------------ From owner-ipsec Wed Nov 27 07:25:54 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA15967 for ipsec-outgoing; Wed, 27 Nov 1996 07:20:51 -0500 (EST) To: IETF-Announce:; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipsec@tis.com From: The IESG Subject: Document Action: HMAC-MD5: Keyed-MD5 for Message Authentication to Informational Date: Tue, 26 Nov 1996 13:13:51 -0500 Message-ID: <9611261313.aa11926@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk The IESG has reviewed the Internet-Draft "HMAC: Keyed-Hashing for Message Authentication" and recommends that it be published by the RFC Editor as an Informational RFC. This document is the product of the IP Security Protocol Working Group. The IESG contact person is Jeffrey Schiller. -- John C. Kelley System Administrator (301) 854-6889 Trusted Information Systems, Inc. (301) 854-5363 FAX 3060 Washington Road johnk@tis.com (work) Glenwood, MD 21738 johnk@radix.net (play) From owner-ipsec Wed Nov 27 11:29:19 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA17029 for ipsec-outgoing; Wed, 27 Nov 1996 11:23:12 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;@tis.com@tis.com;;; cc: ipsec@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-inline-isakmp-00.txt Date: Wed, 27 Nov 1996 10:17:08 -0500 Message-ID: <9611271017.aa24153@ietf.org> Sender: owner-ipsec@ex.tis.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Inline Keying within the ISAKMP Framework. Author(s) : B. Sommerfeld Filename : draft-ietf-ipsec-inline-isakmp-00.txt Pages : 9 Date : 11/26/1996 The current proposal for IP-layer key management [ISAKMP, OAKLEY, ISAOAK] has fairly high overhead. Before a security association can be established, at least one pair of messages need to be exchanged between the communicating peers. For efficiency, this suggests that ISAKMP setup should be infrequent. However, general principles of key management suggest that individual keys should be used as little as practical and changed as frequently as possible. Steve Bellovin has suggested that, ideally, different security associations should be used for each different transport-level connection[BADESP]. This document discusses different ways of structuring a protocol to permit this to happen with minimal overhead, both in round-trip delay at connection setup, and in bandwidth once the connection is established. Portions of this protocol have been inspired by SKIP, which is fundamentally built around the concept of inline keying[SKIP]. SKIP's approach is burdened by the addition of an extra intermediate header of perhaps 20 to 28 bytes to every protected packet, essentially doubling the overhead of protected traffic compared with ESP with manual keying. Ideally, an inline keying header would be used only until the desired security association is established, at which point the peers will fall back to pure ESP/AH. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-inline-isakmp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipsec-inline-isakmp-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-inline-isakmp-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961126110919.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-inline-isakmp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-inline-isakmp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961126110919.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec Wed Nov 27 13:07:01 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id NAA17200 for ipsec-outgoing; Wed, 27 Nov 1996 13:02:25 -0500 (EST) Date: Wed, 27 Nov 1996 13:02:52 -0500 (EST) Message-Id: <199611271802.NAA29680@carp.morningstar.com> From: Ben Rogers To: "C. Harald Koch" Cc: Bill Sommerfeld , "Whelan, Bill" , ipsec@tis.com Subject: Re: AH (without ESP) on a secure gateway In-Reply-To: <96Nov26.191251est.30786-1@janus.border.com> References: <9610258489.AA848977264@netx.nei.com> <199611261929.OAA01715@thunk.orchard.medford.ma.us> <199611262230.RAA27739@carp.morningstar.com> <96Nov26.191251est.30786-1@janus.border.com> Reply-To: ben@ascend.com (Ben Rogers) Sender: owner-ipsec@ex.tis.com Precedence: bulk C. Harald Koch writes: > In message <199611262230.RAA27739@carp.morningstar.com>, Ben Rogers writes: > > > > It seems to me that gatewayA should never try to place an AH, nor do an > > ESP encapsulation on the packet using transport mode (assuming that > > gatewayA did not originate the packet). A gateway that put IPSEC > > headers on packets in transport mode would not only cause confusing > > problems like this, but would have severe problems dealing with > > fragmented packets. > > and > > > It makes sense to only check the headers on packets that are destined > > for the local machine. Otherwise, we would be intercepting (and > > probably modifying) packets not destined to that machine, and violating > > many of the ideas that make IP work. Thus, I don't see any reason that > > a gateway could use transport mode to tack on an AH to a packet from > > hostA to hostB. > > I disagree. The counter example: firewalls (or John Gilmore's "cryptowalls"). > > I see an incredible advantage for firewalls to add IPsec information to > packets, acting as proxies for the machines they're protecting. Keeps all > your Security Association information in one place, where it can be easily > configured and monitored. > > People aren't going to start ripping out their firewalls just because they > have IPsec support on their hosts; firewalls allow much more security > control than IPsec does. (Analogy: you don't unlock the front door just > because everyone can lock their own filing cabinets). Hmmm.... This statement doesn't seem to disagree with my original statement. I said that the gateway should never do encapsulation in *transport* mode. Tunnel mode is still acceptable, and would be the perfect thing to use in this case -- the "cryptowall" would ben one of the tunnel endpoints. The problem in using transport mode on a gateway lies mainly in the fragmentation of packets. Imagine that the "cryptowall" receives a 1500 byte fragment, and adds a header to it. The authenticated packet is then again too big to send out on ether, and so it must be fragmented again. The problem is that we changed the size of the total packet by adding the AH to it. You *cannot* calculate fragment offsets in an unambiguous manner without keeping the enough state to calculate new offsets for all the other fragments. > You also write: > > > Why? I believe the RFC states that the Security Association(SA) is > > chosen using only the destination address and the SPI. It doesn't seem > > to be illegal for several hosts to send us packets using the same > > Security Association (SPI). > > A security association is *indexed* by destination address and SPI. However, > It can include information about the source, including strong authentication > checks, and instructions to reject packets from an invalid IP address. It's > not illegal for several hosts to using the same SPI, but it's also not > secure (it would allow all hosts with the same keying information to spoof > each other, for example). > > I think it's much more likely that a host would enforce the use of different > SPIs (and different keys) for each different source host. This is definitely the more secure method, and should be used when you are dealing with untrustworthy peers. However, if you trust your peers, there is no reason to disallow a priori several "source" hosts sending you packets on the same security association. If all you want to do is to authenticate that someone sending to the multicast address is allowed to, and not to authenticate their individual identity, then this should be sufficient, and should save space (in not having to have seperate security associations for a large number of "identical" peers). You can still check on source address if you want (for example, in a "cryptowall"), but it seems that this should be a policy decision, and should be separated from plain vanilla IP security. ben From owner-ipsec Wed Nov 27 15:14:07 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17538 for ipsec-outgoing; Wed, 27 Nov 1996 15:10:28 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 27 Nov 1996 12:11:44 -0800 From: CJ Lee To: ipsec@tis.com Subject: Re: replay counter size Sender: owner-ipsec@ex.tis.com Precedence: bulk Derrell Piper wrote sometime back: > The latest HMAC AH draft (the one following Montreal) specifies a 64-bit > replay field. The latest Combined ESP draft uses only a 32-bit field. > > Jim, was it your intention for these specs to diverge like this? I > would like to understand why these fields need to be different for AH > and ESP. I would rather see them be the same. I personally believe that > 2^32 packets is too much data to encrypt under one key anyway, so I > think 32-bits is the right number. But I'm more concerned that AH and > ESP be equally protected. > > I recall some discussion in Montreal about the performance of replay > window checks being dependent on the underlying hardware register size, > which supports our desire to make this implementation dependent. I do > not recall discussing changing the replay counter from 32 to 64 bits, > though I confess to being a bit late for the first working group meeting, > due to not being able to get into the room due to overcrowding. I don't remember that I saw an explanation about the question on the mailing list. To me, different replay counter size for different AH/ESP transforms would definitely complicate an IPsec implementation in terms of storing and using the per session (SA) replay checking state - the largest counter seen so far. I'd appreciate that someone could enlighten me on this. CJ Lee (cj_lee@novell.com) From owner-ipsec Wed Nov 27 15:48:50 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA17619 for ipsec-outgoing; Wed, 27 Nov 1996 15:48:21 -0500 (EST) From: pau@watson.ibm.com Date: Wed, 27 Nov 1996 15:53:29 -0500 Message-Id: <9611272053.AA22380@secpwr.watson.ibm.com> To: ipsec@tis.com Subject: Re: AH (without ESP) on a secure gateway Cc: isakmp-oakley@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Md5: b4Ny6eHOqoEJQTvjvj0zEA== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id PAA17616 Sender: owner-ipsec@ex.tis.com Precedence: bulk I have a question triggered by the discussion : If two firewalls (gateways), IDii and IDir, did a successful ISAKMP phase-II proxy negotiation for IDui and IDur. Then, which one is the right usage of the SA resulting from the negotiation : 1. The SA is shared between IDii and IDir (the gateways), and IDii IDir are performing IPSEC protection on traffic between IDui and IDur. In this case, IDui and IDur are unware of the IPSEC protection. 2. The SA is shared between IDui and IDur and IDui and IDur perform IPSEC by themselves. IDii and IDir (the gateways) become more or less (IPSEC) transparent. Pau-Chen From owner-ipsec Wed Nov 27 16:20:30 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA17662 for ipsec-outgoing; Wed, 27 Nov 1996 16:18:18 -0500 (EST) Message-Id: <199611272118.QAA17662@portal.ex.tis.com> From: Greg Carter To: "'ipsec@tis.com'" Cc: "'isakmp-oakley@cisco.com'" Subject: ISAKMP & IPSEC DOI Drafts - Notify Payload - Certificate Authorities Date: Wed, 27 Nov 1996 15:50:35 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24 Sender: owner-ipsec@ex.tis.com Precedence: bulk Questions on ISAKMP draft: Can Notify Payloads be sent in any exchange or are they valid only in Informational Exchanges? What action should be taken when a Notify Payload is received and the Message Type is not known. i.e. My ISAKMP server is using some of the private Message Types to exchange Environment information, but the peer ISAKMP server has no concept of this info (and hence the private message types). Section 3.10 Certificate Request Payload of ISAKMP - draft 6 For the Certificate Authorities field it references the IPSEC DOI document, however I couldn't find any reference to 'Distinguished Name Attribute Type' value in the IPSEC DOI doc. Could someone expand on this? Thanks. ---- Greg Carter Nortel Secure Networks - Entrust carterg@entrust.com From owner-ipsec Fri Nov 29 11:37:15 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA19253 for ipsec-outgoing; Fri, 29 Nov 1996 11:24:00 -0500 (EST) Message-ID: From: Greg Carter To: "'ipsec@tis.com'" Cc: "'isakmp-oakley@cisco.com'" Subject: Certificate Request Payload Date: Fri, 29 Nov 1996 11:16:34 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24 Sender: owner-ipsec@ex.tis.com Precedence: bulk >From draft 6 of ISAKMP 3.10 Certificate Request Payload ..."The responder to the Certificate Request payload MUST send its immediate certificate, if certificates are supported, and SHOULD send as much of its certificate chain as possible." As part of the certificate chain can we send Certificate Revocation Lists (CRL) and Authority Revocation Lists (ARL)? Or was it intended that the certificate chain only include the immediate certificates of the users/CAs in question? Thanks ---- Greg Carter Nortel Secure Networks - Entrust carterg@entrust.com From owner-ipsec Sat Nov 30 19:18:17 1996 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA19768 for ipsec-outgoing; Sat, 30 Nov 1996 19:09:29 -0500 (EST) Message-Id: <3.0.32.19961130161135.0093ca00@earthlink.net> X-Sender: rmonsour@earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sat, 30 Nov 1996 16:11:40 -0800 To: ipsec@tis.com From: Bob Monsour Subject: I-D ACTION:draft-sabin-lzs-payload-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipsec@ex.tis.com Precedence: bulk For those on the list who might not be on the "announce" list. -Bob >To: IETF-Announce: ; >Sender: ietf-announce-request@ietf.org >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-sabin-lzs-payload-00.txt >Date: Wed, 27 Nov 1996 10:18:23 -0500 >X-Orig-Sender: cclark@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : LZS Payload Compression Transform for ESP > Author(s) : M. Sabin, R. Monsour > Filename : draft-sabin-lzs-payload-00.txt > Pages : 7 > Date : 11/26/1996 > >This memo proposes a "payload compression transform" based on the LZS >compression algorithm. The transform can be used to compress the payload >field of an IP datagram that uses the Encapsulating Security Payload (ESP) >format. The compression transform proposed here is stateless, meaning that >a datagram can be decompressed independently of any other datagram. >Compression is performed prior to the encryption operation of ESP, which >has the side benefit of reducing the amount of data that must be encrypted. > >This memo anticipates a forthcoming draft of ESP that will supercede >[Atkins96]. The forthcoming draft will allow for ESP payloads to be >compressed via transforms such as the one described in this memo. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-sabin-lzs-payload-00.txt". >A URL for the Internet-Draft is: >ftp://ds.internic.net/internet-drafts/draft-sabin-lzs-payload-00.txt > >Internet-Drafts directories are located at: > > o Africa: ftp.is.co.za > > o Europe: nic.nordu.net > ftp.nis.garr.it > > o Pacific Rim: munnari.oz.au > > o US East Coast: ds.internic.net > > o US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ds.internic.net. In the body type: > "FILE /internet-drafts/draft-sabin-lzs-payload-00.txt". > >NOTE: The mail server at ds.internic.net can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e., documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version >of the Internet-Draft. > > >