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
- proposed IPSEC changes/extensions Stephen Kent
- Re: proposed IPSEC changes/extensions David Wagner
- Re: proposed IPSEC changes/extensions Ran Atkinson
- Re: proposed IPSEC changes/extensions Hilarie Orman
- Re: proposed IPSEC changes/extensions pau
- Re: proposed IPSEC changes/extensions Michael Sabin
- Re: proposed IPSEC changes/extensions Stephen Kent
- Re: proposed IPSEC changes/extensions pau
- Re: proposed IPSEC changes/extensions Bill Sommerfeld
- Re: proposed IPSEC changes/extensions pau
- Re: proposed IPSEC changes/extensions Santeri Paavolainen
- Re: proposed IPSEC changes/extensions Rodney Thayer
- Re: proposed IPSEC changes/extensions Santeri Paavolainen
- Re: proposed IPSEC changes/extensions Stephen Kent
- Re: proposed IPSEC changes/extensions David Wagner
- Re: proposed IPSEC changes/extensions Steven Bellovin
- Re: proposed IPSEC changes/extensions Michael Sabin
- Re: proposed IPSEC changes/extensions John Gilmore