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

Re: proposed IPSEC changes/extensions

At 02:58 AM 10/29/96 +0000, Stephen Kent wrote:

>        For ESP, the changes are much more significant.  The protocol
>(header) will consist of a set of optional, mostly variable-length fields,
>each of which is selected at SA establishment to describe the specific
>security services desired for the SA.  The optional fields include an IV,
>sequence number for anti-replay, and an integrity check value (in addition
>to the static SPI and next protocol fields, and the padding).  Thus there
>are no new fields (not already described in some existing tranform) nor
>substantive changes in processing description. (We've been talking about
>compression for a while, more so recently, but I don't know if there a need
>for any new fields for this, rather than just an SA characteristicto be
>negotiated?)

Compression is greatly helped by including a field that controls two
functions:  (1) whether or not the contents of the packet are compressed;
and (2) whether or not the compression state was reset prior to this packet.
Here is why:

1)  Compressing a packet sometimes actually expands its contents.  This is
most common with short packets.  When expansion occurs, it is better to send
the uncompressed version of the packet.  This requires each packet to have a
bit that identifies the packet as compressed or not.

2)  Compression is stateful, which means that the transmitter and receiver
can get out of sync if packets are missed.  To deal with this, the
transmitter frequently resets its compression state to a known starting
value, allowing an out-of-sync receiver to resync.  A convenient way to
accommodate this is to include a bit in each packet that indicates whether
or not the compression state was reset prior to compressing this packet.

We recently developed an ESP transform based on the Hughes draft that
includes compression (see below).  We included a "Compression Control" field
(one byte) that has a bit for each of these two functions.  I vote that such
a field be included as an optional field in the ESP.

Regards,
mike sabin


> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.                                                              
>
>       Title     : Combined 3DES-CBC, LZS Compression, HMAC, and 
>                   Replay Prevention ESP Transform
       
>       Author(s) : M. Sabin, R. Monsour
>       Filename  : draft-sabin-esp-des3-lzs-md5-00.txt
>       Pages     : 18
>       Date      : 10/23/1996
>
>This document proposes the "3DES-CBC-LZS-HMAC-Replay" security transform 
>for the IP Encapsulating Security Payload (ESP).  The proposed transform 
>combines triple-DES encryption, LZS compression, HMAC authentication, and 
>replay prevention into a single packet format.  The transform is compatible
>with implementations that do not support compression and with 
>implementations that support only single-DES encryption.  Compression is 
>performed prior to encryption, which has the side benefit of reducing the 
>amount of data that must be encrypted.       
>                              
>This document is based on the IPsec Working Group's proposed "Combined 
>DES-CBC, HMAC, and Replay Prevention Security Transform," cited later in 
>this document.                                                             
>