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

Re: I-D ACTION:draft-thayer-seccomp-00.txt

At 12:18 PM 8/8/96 -0400, Naganand Doraswamy wrote:
>Instead of adding a new header for compression, does it make sense to say
>that we negotiate compression as a part of transform? For example, can we
>negotiate a trasform for ESP which says DES-CBC 64 bit IV with compression
>enabled so that we compress the data before encrypting. We will avoid the
>extra overhead of another header this way.

We at Stac have also been thinking about methods for adding compression in
the context of IPsec; specifically due to the problem as identified in the
draft as follows:

          The introduction of security into packets transmitted using
          Internet IP (Version 4) [RFC-791] causes a change in the
          applicability of compression technology to data communications.
          Specifically, when a packet is encrypted, it becomes essentially
          random data, and therefore is highly incompressible.  This makes
          it difficult to use conventional techniques to compress IP
          datagrams, such as PPP compression.  To solve this problem it
          becomes desirable to compress the data before it is encapsulated
          with security features.

Our original thoughts were to push the compression function down to the ESP
transform level, i.e., define a transform (or set of transforms) which
combine compression with encryption under ESP and to include additional
"opaque" transform data that was compression-specific to handle packet to
packet sequencing for maintaining compression history across packets. The
downside to this approach, however, is that it does not allow compression to
be used in the absence of ESP (say, where only AH is used). I think that the
general method proposed in Rodney's draft (or a derivative thereof) may
indeed be preferable as it circumvents this problem.

I would add that this does pose another problem for the environment where
there may be a subsystem (say a chip or chipset) which takes an
under-construction IP datagram as input and performs compression, encryption
and AH MAC computation, outputting the complete IP datagram to be
transmitted. Since the AH MAC is computed over the entire IP datagram, the
datagram/payload length field of the packet is not known until after the
data is compressed (prior to encryption). In order to avoid making multiple
passes over the data, I would propose that the definition of the span of the
MAC for AH eliminate the datagram/payload length field.

Comments?

Bob Monsour
Stac, Inc.
rmonsour@stac.com
Follow-Ups: