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

Re: TO COMPRESS OR NOT TO CMPRS (please reply)

I think there should be compression.  I think stealing a bit sounds like an
acceptable scheme.  I think this should be a negotiated option in a key
management context (see the DOI) to specify this.  I think it should be a
bit rather than a byte in deference to the 64-bit alignment issue.  I
believe the combination of using a bit and using negotiation allows
implementations to address or ignore compression in an interoperable
manner.  I believe the 128-byte padding limit has no known problems, as I
recall the conversations.

At 04:14 PM 2/17/97 -0800, you wrote:
>Since my last posting about adding compression in the form of an "optional
>feature of ESP", I have received several offline inputs from wg members.
>Specifically, two issues arose:
>
>1. What is the status of adding compression to ESP?
>
>   I know that there are some wg members who support the use of compression, 
>   some who don't and some who haven't expressed an interest either way.
Well,
>   the time has come to decide. PLEASE RESPOND BY INDICATING YOUR POSITION.
>   Be sure to copy the wg list in your reply. 
>
>2. Placement of the "packet compressed/not-compressed" byte/bit
>
>   Several people have suggested that rather than using a whole byte for this
>   purpose, simply "steal" the uppermost bit of the pad length field. This is
>   a simple solution. It was suggested to me that a maximum of 128 bytes of 
>   padding is sufficient. Note that the preferred ESP transform for the IPSEC
>   DOI (draft-ietf-ipsec-esp-des-md5-03.txt) provides for up to 255 bytes of
>   padding. There are two ways to approach this issue:
>
>    (a) alter the transform draft to specify a max of 128 bytes of
padding, or
>
>    (b) for implementations which do not negotiate the use of compression
(for
>        a particular SA, or never), they can continue to use up to 255 bytes
>        of padding; for those that *do* support compression, the maximum
>padding
>        would be 128 bytes. 
>
>   INPUTS ON THIS DECISION ARE NEEDED. Assuming that the group wants to
>proceed
>   with compression, the decision on this issue will affect the ESP draft,
>the 
>   latest of which has yet to be issued. So, please respond.
>
>Regards,
>Bob
>
>
>
>

               Rodney Thayer <rodney@sabletech.com>       +1 617 332 7292
               Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA
               Fax: +1 617 332 7970           http://www.shore.net/~sable
                           "Developers of communications software"