[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Packet-by-packet compression within IPSec

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
Follow-Ups: