Re: Decoupling compression and security
Santeri Paavolainen <santtu@cs.hut.fi> Mon, 25 November 1996 08:59 UTC
Received: from cnri by ietf.org id aa25205; 25 Nov 96 3:59 EST
Received: from portal.ex.tis.com by CNRI.Reston.VA.US id aa08164; 25 Nov 96 3:48 EST
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id DAA10369 for ipsec-outgoing; Mon, 25 Nov 1996 03:32:24 -0500 (EST)
Date: Mon, 25 Nov 1996 10:34:24 +0200
From: Santeri Paavolainen <santtu@cs.hut.fi>
X-Sender: santtu@hutcs
To: ipsec@tis.com
Subject: Re: Decoupling compression and security
In-Reply-To: <3.0.32.19961122205654.0099c100@earthlink.net>
Message-ID: <Pine.GSO.3.94.961125100351.29183A-100000@hutcs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
> 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. 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). Also, some persons might want compression, and only that. I imagine there would be plenty of situations (two computers connected by a secure network/line) where getting "compression" out of IPSEC layer could not be justified because of the extra costs because the compression would imply (cpu-intensive) cryptographic methods. Of course, it is another matter whether compression should be included in the IPSEC layer at all. PS. In the IP Authentication Header draft (4 June 1996, are there newer versions?) at chapter 3, the combination of AH(AH(...)) is said to be invalid at all times. Why? Take the following situation as an example where AH(AH(...)) could be used: A VPN network, eg. an intranet created by establishing a secure tunnel between two separate networks. Typically, the VPN routers apply some IPSEC AH+ESP transformation on a packet before sending it through the internet network. But, there can be a case when the VPN router does not want to encrypt a packet, but still requires authentication. If there are IPSEC-capable hosts within these two parts of the intranet talking to each other with some AH+ESP transformations the VPN routers will get packets in the form of AH(ESP(...)). If the VPN routers have knowledge about the used ESP (by acting as a middlemen in key management routine, for example) an deem it as "secure enough" they might not want to apply a second layer of ESP, because it would be unnecessary. Still they want to apply an AH, so that the other VPN router can confirm the authenticity of the packet coming from the internet (that it really is coming from the other VPN router). This leads to a situation where the packet would look like AH(AH(ESP(...))) when send to the internet. But this seems not to be allowed by the draft! -- sjpaavol@cc.Helsinki.FI I have become death, destroyer of the worlds.
- Decoupling compression and security Derek Palma
- Re: Decoupling compression and security Santeri Paavolainen
- Re: Decoupling compression and security Santeri Paavolainen