Re: proposed IPSEC changes/extensions

[Steven Bellovin <[e-mail]>]

	 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 <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: proposed IPSEC changes/extensions
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Organization: cisco Systems
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

In article <[e-mail]>, 
	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
[e-mail]





Date: Mon, 4 Nov 1996 13:18:45 +0200 (EET)
From: Santeri Paavolainen <[e-mail]>
To: [e-mail]
Subject: Re: proposed IPSEC changes/extensions 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
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? :-)

--
[e-mail]          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 ([e-mail] [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id IAA03147 for <[e-mail]>; 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: <[e-mail]>
From: Karl Fox <[e-mail]>
To: Steven Bellovin <[e-mail]>
Cc: Hilarie Orman <[e-mail]>, [e-mail], [e-mail]
Subject: Re: proposed IPSEC changes/extensions 
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Reply-To: Karl Fox <[e-mail]>
Organization: Ascend Communications
Sender: [e-mail]
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   [phone]

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 ([e-mail] [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id JAA04994 for <[e-mail]>; 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 <[e-mail]>; Mon, 4 Nov 1996 15:13:22 +0100 (MET)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
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: [e-mail]
From: Sergio Esposito <[e-mail]>
Subject: IPsec implementations
Sender: [e-mail]
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		: [phone]
FAX		: [phone]
Interests	: IPv6, IPSec, VPN
e-mail		: [e-mail]
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 ([e-mail] [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id KAA12959 for <[e-mail]>; 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: <[e-mail]>
To: Hilarie Orman <[e-mail]>
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: [e-mail], [e-mail]
Subject: Re: proposed IPSEC changes/extensions 
References: <[e-mail]>
In-reply-to: ho's message of "Fri, 01 Nov 1996 16:02:53 -0500".
	 <[e-mail]> 
From: "C. Harald Koch" <[e-mail]>
MMDF-Warning:  Unable to confirm address in preceding line at neptune.TIS.COM
Organization: Secure Computing Canada Ltd.
Phone: [phone]
X-uri: <URL:http://www.eng.border.com/homes/chk/>
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: [e-mail]
Precedence: bulk


In message <[e-mail]>, 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
[e-mail]

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 ([e-mail] [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id KAA13747 for <[e-mail]>; 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 <[e-mail]>; Mon, 4 Nov 1996 10:41:29 -0500 (EST)
X-Sender: [e-mail]
Message-Id: <v02130510aea3bc01b554@[128.89.0.110]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 4 Nov 1996 10:43:07 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: proposed IPSEC changes/extensions
Sender: [e-mail]
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 ([e-mail] [10.33.1.1]) by clipper.hq.tis.com (8.7.5/8.7.3) with SMTP id KAA13902 for <[e-mail]>; 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: [e-mail]
Message-Id: <v02130511aea3bd9313c1@[128.89.0.110]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 4 Nov 1996 10:43:11 -0500
To: Karl Fox <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: proposed IPSEC changes/extensions
Cc: Steven Bellovin <[e-mail]>, Hilarie Orman <[e-mail]>, 
    [e-mail]
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: [e-mail]
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 <[e-mail]>
From: Bob Monsour <[e-mail]>
Subject: Re: proposed IPSEC changes/extensions 
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
Message-ID:  <[e-mail]>

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
[e-mail]




Date: Mon, 04 Nov 1996 10:28:14 -0800
To: Karl Fox <[e-mail]>
From: Bob Monsour <[e-mail]>
Subject: Re: proposed IPSEC changes/extensions
Cc: Stephen Kent <[e-mail]>, Hilarie Orman <[e-mail]>, 
    [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
Message-ID:  <[e-mail]>

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
[e-mail]




Date: Mon, 04 Nov 1996 10:41:05 -0800
To: Stephen Kent <[e-mail]>
From: Bob Monsour <[e-mail]>
Subject: Re: proposed IPSEC changes/extensions
Cc: Hilarie Orman <[e-mail]>, [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
Message-ID:  <[e-mail]>

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
[e-mail]





Date: Mon, 04 Nov 1996 10:49:00 -0800
To: Steven Bellovin <[e-mail]>
From: Bob Monsour <[e-mail]>
Subject: Re: proposed IPSEC changes/extensions 
Cc: Hilarie Orman <[e-mail]>, [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
Message-ID:  <[e-mail]>

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
[e-mail]




Date: Mon, 04 Nov 1996 10:56:17 -0800
To: Stephen Kent <[e-mail]>
From: Bob Monsour <[e-mail]>
Subject: Re: proposed IPSEC changes/extensions
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
Message-ID:  <[e-mail]>

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
[e-mail]