Compression in ESP
Bob Monsour <rmonsour@earthlink.net> Thu, 23 January 1997 22:38 UTC
Received: from cnri by ietf.org id aa02531; 23 Jan 97 17:38 EST
Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa23753; 23 Jan 97 17:38 EST
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA26839 for ipsec-outgoing; Thu, 23 Jan 1997 17:29:24 -0500 (EST)
Message-Id: <3.0.32.19970123143228.009826b0@earthlink.net>
X-Sender: rmonsour@earthlink.net
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 23 Jan 1997 14:32:30 -0800
To: ipsec@tis.com
From: Bob Monsour <rmonsour@earthlink.net>
Subject: Compression in ESP
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
At the December IETF meeting, the IPSEC working group consensus was to undertake compression as a work item. Recapping the motivation for putting compression in IPSEC: (1) PPP compression will be rendered ineffective on encrypted IPSEC payloads, (2) compression can reduce encryption and MAC processing, (3) compression can reduce the likelihood of packet fragmentation. Two proposals were presented at the meeting and a number of issues were raised regarding the best technical approach to use. I will attempt to summarize the issues that were raised and describe the available alternatives. I comments and suggestions from the group. Note that while no editors have been assigned to this task as of yet, I think it is important to get some input from the working group to keep the process from dying. The April meeting is Memphis will be here before we know it. TWO PROPOSALS 1. Make compression an optional feature of ESP 2. Create a separate (IPSEC independent) transform to support compression METHOD 1: OPTIONAL FEATURE OF ESP DRAFTS: draft-sabin-esp-des3-lzs-md5-00.txt draft-sabin-lzs-payload-00.txt In this method, compression would be added as an optional feature of ESP. The compression algorithm would be determined through KMP negotiation for each connection. It was proposed that a single byte field be used to determine whether or not the payload data is compressed (prior to encrypting). This byte would use a single bit to indicate compressed/not-compressed. Other bits could be assigned in the future to support additional compression functionality. Issue 1: Placement of the single byte field There were significant objections to the proposed placement of the byte at the start of the payload data for word-alignment reasons. Options for placement: 1. Steve Kent suggested that it could be placed at the end of the payload, between the Pad Length and the Payload Type bytes. 2. There was a suggestion that a byte not be used at all, but that an upper bit of the Pad Length field be allocated for this purpose. I recall reading that the padding can be up to 255 bytes (I think this was in the des-cbc-hmac-replay draft), so this would prevent us from using option 2. If that is not the case, then we could indeed use one of those upper bits. I would prefer to have two bits available for possible future use. I'd appreciate input on this. At this time, my recommendation would be to go for option 1 (place a byte between Pad Length and Payload Type). Issue 2: Negotiating compression The only issue here is that ISAKMP and the DOI drafts will need to support the negotiation of a compression algorithm and enabling compression for a specific SA. Given that the working group has decided to proceed with taking up compression as a work item, the necessary changes to the ISAKMP and DOI drafts could be made at any time. METHOD 2: SEPARATE TRANSFORM DRAFT: draft-thayer-seccomp-00.txt In this method, a separate transform is used. It has an overhead of 8 bytes (vs. 1 byte for the ESP optional feature) for each compressed payload. The separate transform has the ability to be used in non-secure environments. PROPOSAL I propose that the working group adopt Method 1. While the Method 1 drafts describe the LZS compression algorithm, the general approach can support any compression algorithm. LZS is a patented algorithm and as such, the proposed draft would ultimately become an Informational RFC. Hi/fn is the owner of the LZS patents and has provided a no-cost license to a C version of the algorithm for use in PPP implementations. Hi/fn has agreed to make a similar license available for IPSEC implementors. Prior to proceeding with additional work on a compression draft, the working group co-chairs must assign an editor or editors to the task. I encourage them to do so in time for a new draft to be produced in time for discussion at the April meeting. Thanks for listening and I look forward to your feedback. Bob Monsour rmonsour@hifn.com
- Compression in ESP Bob Monsour