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

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

While compression make some sense at a transport layer, it also make
sense to implement it with IPSec as well.  

Certain situations do not have access to transport layer compression
(ie. firewalls) and IPSec compression would greatly affect performance,
expecially when you consider that in certain situations where a lot of
large packets are being sent accross, adding the ESP header would cause
fragmentation.  When compression is used, fragmentation would not
normally be required.


I don't like the idea of adding it to the pad length field.  Although
255 bytes of padding is more than enough, changing that fields role
might break some current implementations.

I like the idea presented in <draft-sabin-lzs-payload-00.txt>, whereas
the compression byte field is placed as the first byte of the ESP data.
After this byte, is the compressed data.

We might also wish to expand this compression byte field to a small
header for future growth;

Eg:

compression_header :==
{
	word compression_header_length;
	byte flags;	// 0x01 = compressed
}

>----------
>From: 	Bob Monsour[SMTP:rmonsour@earthlink.net]
>Sent: 	Monday, February 17, 1997 7:14 PM
>To: 	ipsec@tis.com
>Subject: 	TO COMPRESS OR NOT TO CMPRS (please reply)
>
>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
>
>
>