Re: proposed IPSEC changes/extensions

Michael Sabin <msabin@netcom.com> Mon, 04 November 1996 19:17 UTC

To: Karl Fox <karl@ascend.com>
From: Michael Sabin <msabin@netcom.com>
Subject: Re: proposed IPSEC changes/extensions
Cc: ipsec@TIS.COM
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Date: Mon, 04 Nov 1996 14:17:09 -0500
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 <ipsec@tis.com>; 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: <v02130513aea3f782b10f@[128.89.0.110]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 4 Nov 1996 16:13:44 -0500
To: Bob Monsour <rmonsour@earthlink.net>
From: Stephen Kent <kent@bbn.com>
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 <ipsec@tis.com>; 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 <kent@bbn.com>
From: Bob Monsour <rmonsour@earthlink.net>
Subject: Re: proposed IPSEC changes/extensions
Cc: Bob Monsour <rmonsour@earthlink.net>, 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