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

Re: compression and encryption

Steve, that was a very thoughtful analysis. Thank you for spending the time
and energy on it. Here are my thoughts on your recommendations.

At 08:54 PM 11/6/96 -0500, Steve Bellovin wrote:
>	a) we proceed with ESP as it is now.  No changes should
>	be made, or hooks left, for compression.

Based on the data provided by Mike Sabin earlier today regarding the
compression performance of stateless compression (repeated here):

      On 11/6, Mike Sabin wrote:
	>Here's the row of the table that corresponds to 512-byte payloads:
	>
	>     n:                      1     2     4     8    16    32   
	>     Compression ratio:   1.58  1.73  1.89  2.01  2.08  2.11
	>
	>In the case n=1, the compression boosts throughput by about 60%.
	>(Headers are neglected here.)  Larger values of n give better 	
	>compression, obviously.

I would suggest that we allow for statless compression to be implemented
within the context of ESP. I would further suggest, as I did in an earlier
posting (11/4) that this be done with some minor language changes to ESP: 

	"...that the ESP draft simply state that compression is one of the 
	negotiable security association attributes...In addition, the ESP draft 
	would state that when the optional compression is implemented, it is 
	performed prior to encryption. I would suggest that the appropriate 
	language be added to the descriptions of the "sender" and "receiver" 
	operations in the	tunnel-mode and transport-mode descriptions (sections 
	4.1 and 4.2	of the June 6 draft)."

This allows stateless compression functionality to be optionally deployed
in the near term> It also allows the working group the necessary time and
consideration needed to properly evaluate mechanisms for implementing
statfull, multi-packet compression.

I would suggest to you that this qualifies as "no changes or hooks", since
the ESP transform is not modified in any way.

>	b) the key management exchanges should permit the negotiation
>	of an arbitrary set of compression parameters, for when something
>	is defined.

Agree.

>	c) we investigate IPSEC header compression.

In tunnel mode, the tunnelled headers are part of the payload that will be
compressed.  This will boost compression efficiency, since the headers are
presumably very compressible.

>	d) the IPSEC architecture must allow for the header formats
>	resulting from POP-based encryption.
>

Agree.


Thanks to all for listening. I look forward to comments from all
(supporters and non-supporters alike).


Bob Monsour
rmonsour@earthlink.net