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

Re: Decoupling compression and security

Have you looked at the draft I did in July?  What you're talking about
sounds like the direction I was headed.  How would you add/change what I
proposed?

>X-Sender: rmonsour@earthlink.net
>Date: Fri, 22 Nov 1996 20:57:01 -0800
>To: Derek Palma <dpalma@netcom.com>
>From: Bob Monsour <rmonsour@earthlink.net>
>Subject: Re: Decoupling compression and security
>Cc: ipsec@tis.com, dpalma@netcom.com
>Sender: owner-ipsec@ex.tis.com
>
>At 12:59 PM 11/22/96 -0800, Derek Palma wrote:
>>Some recent IPSEC implementation experiences and the current discussion
>>has caused me to consider the virtues of coupling compression
>>transforms with security.  No doubt use of compression has
>>benefits, even if only applied to a single packet.
>>
>>I see no problem with having compression be part of an SA.
>>But I think it lacks some generality.  The output of a compression
>>algorithm can be larger than the input, the sender will no
>>doubt like to selectively compress.  This means the receiver
>>must be able to receive compressed and uncompressed data.
>>This seems independent from the SA.  Howeverm, the SA setup
>>can be used to select the compression algorithm.
>
>When using packet-by-packet compression within IPSec, while an SA parameter
>will exist to define the compression algorithm and whether or not
>compression is enabled for a particular sender to receiver, the sender (as
>you suggest) will not want to send data when it expands. We have suggested
>that each compressed payload include a bit (within a one-byte field) which
>indicates whether or not the IP datagram is compressed or not. So, in
>effect, the sender operates as follows:
>         
>         compress the packet
>         if it gets smaller
>            compressed = true
>            send it compressed
>         else
>            compressed = false
>            send the packet in uncompressed form
>
>On the reciever side, it just checks the compressed/uncompressed bit to
>decide whether or not to attempt decompression.
>
>>Generic (probably PPP like) compression transforms which stand
>>on their own (apart from IPSEC) seemslike a more general solution.
>>However, IPSEC is the only group who can justify using compression
>>on a per packet basis.  Would a set of IP-COMP transforms (vs IPSEC)
>>be more appropriate?
>
>The attractive part of PPP-like compression solutions is that operate over
>a connection-oriented protocol and therefore can compress across multiple
>packets, realizing greater efficiencies than by doing it a packet at a
>time. Unfortunately, we don't have that luxury in IP. At an even higher
>layer, say SSL, there again is a connection-oriented protocol and
>compression can indeed be done over a series of transmitted packets. Once
>equipped with the packet-by-packet mode of compression, I would suspect
>that if there is sufficient interest and energy in the working group, some
>effort could be put forth to figure out how to reliably compress across
>multiple IP datagrams. 
>
>How would you see an IP-COMP transform operating?
>
>
>Bob Monsour
>rmonsour@earthlink.net
>
>

               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
                           Communications Software Development