[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Decoupling compression and security
At 10:34 AM 11/25/96 +0200, Santeri Paavolainen wrote:
...
>If the compression was another IPSEC transformation there would be no
>need for such a "bit" in the actual _security_ transformation
>data. Have everybody forgotten that applying transformations on a
>packet is still optional? If I want an option of not applying a packet
>compression transformation I can just not apply it -- no need for any
>information bits in the packet. As an example,
>
>there is two transformations defined, COMP for compression and CRYPT
>for some crypto. If I get a acceptable compression ratio for a packet,
>I leave the compression transformation on and pass the packet to the
>rest of the transformation chain, finally giving a packet like
>
> CRYPT(COMP(packet))
>
>OTOH, if the compression ratio is unacceptable, just leave the
>compression layer off:
>
> CRYPT(packet)
>
>Because the receiver sees only SPIs of the various layers, it will
>first decrypt and either get a regular (not compressed) packet, or a
>compressed packet which will then have to be uncompressed to gain the
>final packet.
>
>Of course, this would mean there is overhead of SPI vs. "bit", but I
>think the generality is a clear plus. What if you later find out the
>cryptographic transformation you have embedded the compression layer
>is not secure? Also, there is no clear way how to interoperate between
>different transformations which have the same compression engine (you
>must remember that each transformation should be self-contained from
>the coding point of view).
...
This is more than just an issue of the overhead of an SPI vs. a "bit". Let
me explain by way of example. Let's say that a security association has
been set up for traffic traveling from a sender to a receiver. Thus the SPI
for traffic in that direction is specified. Let's also say that the SPI
specifies the use of a particular set of compression, encryption and
authentication algorithms. Then, let's say that the sender wants to send a
datagram to the receiver. Suppose the data expands. The sender would then
want to send the original uncompressed form of the data. Under our
proposal, all the sender would have to do is to change a bit at the start
of the payload. Under what you propose, the SPI is no longer valid since
the reciever will erroneously attempt to decompress raw data. Your method
would thus require that a new SPI be used which would likely require some
renegotiation between the sender and receiver as to which algorithms and
modes are to be used for the connection.
Bob Monsour
rmonsour@earthlink.net