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

Re: Decoupling compression and security

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
Follow-Ups: