[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Compression in ESP
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