Packet-by-packet compression within IPSec
Bob Monsour <rmonsour@earthlink.net> Thu, 21 November 1996 19:55 UTC
Received: from cnri by ietf.org id aa27139; 21 Nov 96 14:55 EST
Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa18409; 21 Nov 96 14:55 EST
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 <rmonsour@earthlink.net>
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
- Packet-by-packet compression within IPSec Bob Monsour