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

RE: TO COMPRESS OR NOT TO CMPRS (please reply)

I think that linking compression to a specific set of transforms isn't a good idea. 

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.  Besides, in the future,
some may want to use compression with other types of transforms than just ESP.   Why for
instance, wouldn't I want to compress an AH packet?  Granted, you won't gain very 
much but someone is going to argue that running a hash algorithm over less data is good!

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. 

I'm not sure compression is that good an idea anyway, and I am not sure that we will gain 
very much from its use.  However, if we are going to do compression, I think linking it
specifically to ESP isn't very wise.  Negotiating it and using it on all packets per 
association seems to be the only real solution to me.  Adding a bit to say if a packet is 
compressed or not seems like overkill.    Granted I don't know a ton about compression 
but it seems that a small minority of packets will be expanded by compression 
and why check every packet to see if it is compressed or not to save the processing 
of one decompression per n packets of compressed data. 

Okay, I've babbled long enough.   Direct answers are in order.

>>1. What is the status of adding compression to ESP?

Adding compression to a transform is not good.  Adding compression to the architecture
may or may not be good.  So don't let's add compression to ESP.  Add it, if at all,
to the architecture. 

>>2. Placement of the "packet compressed/not-compressed" byte/bit

See answer to 1.  No bit, no byte. 


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?

-Rob Adams
Cisco Systems. 

----------
From: 	Bob Monsour[SMTP:rmonsour@earthlink.net]
Sent: 	Monday, February 17, 1997 4:14 PM
To: 	ipsec@tis.com
Subject: 	TO COMPRESS OR NOT TO CMPRS (please reply)

Since my last posting about adding compression in the form of an "optional
feature of ESP", I have received several offline inputs from wg members.
Specifically, two issues arose:

1. What is the status of adding compression to ESP?

   I know that there are some wg members who support the use of compression, 
   some who don't and some who haven't expressed an interest either way. Well,
   the time has come to decide. PLEASE RESPOND BY INDICATING YOUR POSITION.
   Be sure to copy the wg list in your reply. 

2. Placement of the "packet compressed/not-compressed" byte/bit

   Several people have suggested that rather than using a whole byte for this
   purpose, simply "steal" the uppermost bit of the pad length field. This is
   a simple solution. It was suggested to me that a maximum of 128 bytes of 
   padding is sufficient. Note that the preferred ESP transform for the IPSEC
   DOI (draft-ietf-ipsec-esp-des-md5-03.txt) provides for up to 255 bytes of
   padding. There are two ways to approach this issue:

    (a) alter the transform draft to specify a max of 128 bytes of padding, or

    (b) for implementations which do not negotiate the use of compression (for
        a particular SA, or never), they can continue to use up to 255 bytes
        of padding; for those that *do* support compression, the maximum
padding
        would be 128 bytes. 

   INPUTS ON THIS DECISION ARE NEEDED. Assuming that the group wants to
proceed
   with compression, the decision on this issue will affect the ESP draft,
the 
   latest of which has yet to be issued. So, please respond.

Regards,
Bob