Decoupling compression and security

Derek Palma <dpalma@netcom.com> Fri, 22 November 1996 21:14 UTC

Received: from cnri by ietf.org id aa01101; 22 Nov 96 16:14 EST
Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa25865; 22 Nov 96 16:14 EST
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA09104 for ipsec-outgoing; Fri, 22 Nov 1996 16:01:10 -0500 (EST)
Message-Id: <3.0.32.19961122125905.00e47f40@netcom8.netcom.com>
X-Sender: dpalma@netcom8.netcom.com (Unverified)
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 22 Nov 1996 12:59:54 -0800
To: ipsec@tis.com
From: Derek Palma <dpalma@netcom.com>
Subject: Decoupling compression and security
Cc: dpalma@netcom.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

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.

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?

Derek