[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: TO COMPRESS OR NOT TO CMPRS (please reply)
At 03:39 PM 2/18/97 -0800, Rob Adams wrote:
>I would much rather see compression negotiated as part of the ISAKMP exchange
>and used for all traffic associated with an SA. I don't think adding any
bits is necessary.
>As Naganand said, we already have enough bits and options.
Rob,
Compression would indeed be negotiated as partof the ISAKMP exchange.
Allowing selective compression on a packet by packet basis provides
implementation flexibility. For example, you may want to avoid compressing
packets less than 100 bytes; or want to send uncompressed data because the
data expanded (was precompressed or pre-encrypted at the application
layer). You could easily do this using the compressed/not-compressed bit as
proposed. To avoid using the bit, you would have to have two SA's for each
direction of the connection: one to use for compressed data and one to use
for uncompressed data. Are system resources (SA's) that free that a
potential doubling of their use is acceptable? I would argue that use of a
single bit per packet (an existing bit, not an additional one) is
preferable to managing two SA's per direction on each connection. Seems
like comparable complexity at best.
...snip...
>I prefer ISAKMP negotiation because it will allow me to implement it up
higher in my stack
>than the IP layer. I think that compressing at the IP layer isn't going
to buy you a whole
>lot in speed since you're going to be sending out the same number of
packets.
>If I have a confirmed negotiated compression algorithm/state, my
implementation
>can do compression in the appropriate place, above the fragmentation done
by
>TCP. Firewalls can do compression before they encrypt or whatever, but then
>I'll just get a lot of small encrypted packets from a firewall. A
firewall will get
>fully packed, compressed and encrypted packets from me. That's better
than nothing.
>
>The choice of what layer to process compression at should be an
implementation detail
>as long as it is done before encryption and decompressed after decryption.
In this way,
>compression may be useful to things other than IPsec and ESP in
particular. Lumping
>compression on ESP doesn't allow us a general compression solution.
The problem, as I've stated in other responses, is that there is not a
universal "higher layer" in which to do compression. It is more than an
implementation detail. All parties wanting to compress would have to
support it at this "higher layer" which may or may not be present. IP is
the common denominator and the need for compression at the IP layer is
partly because of the encryption. In the absence of encryption, for systems
using PPP, the PPP compression will be effective.
...snip...
>I'd like to see more investigation of how useful compression is before we
commit to anything though.
>I have a lot of questions about how much we'll gain for what kinds of
traffic and over links that do
>hardware compression like some modems and routers. Am I the only one that
feels like we're rushing
>this without enough information?
In a response to another message in this thread, I provided a table of
compression ratios for text data, analyzed on the basis of packet size. I
will work on providing similar results on other types of data, but this is
publically available data used for comparing compression ratios for
different compression algorithms (see draft-sabin-lzs-payload-00.txt).
For links that do hardware compression (modems & routers), once you encrypt
at a the IP layer, those compressors are no longer effective (encrypted
data doesn't/shouldn't compress).
Your questions are useful in the debate and are appreciated.
-Bob