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

ipsec compression support

>> Robert Moskowitz writes:
>>
>> I read draft-ietf-pppext-compression-04.txt,
>> draft-ietf-pppext-dce-compress-00.txt, and
>> draft-ietf-pppext-bsd-compress-02.txt.
>>
>> It seems that there is much here that can be used directly.  The bsd
>> compress sounds best due to licensing issues, yes?  I'd try my hand at
>> cobbling something together, but I am overdue on 1597bis :(
>>
>> Robert Moskowitz
>> Chrysler Corporation
>> (810) 758-8212
>>


I am the lossless data compression algorithm architect for IBM Microelectronics
Division (IMD), which provides IC hardware and software implementations
of a family of algorithms called ALDC.  My department also offers DES macros.
I have been attending and following this group for over a year, waiting quietly
while you cryptography experts mostly debate the technicalities of key
management and algorithm strength, and rightly so.  But I have been looking
forward to the day when it is time to provide for data compression in IPSEC.

Obviously encryption and compression are very closely related.  As has been
commented, the protocol issues with compression, such as requiring mech-
anisms for keeping synchronized contexts, etc, are very similar to those for
encryption, and that encryption will draw compression back from the WAN data
links to the security boundaries, which in many cases should be the end user.
Compression even makes the encryption slightly stronger.  From the point of
view of enabling IC technology, there is also a close relationship.

For instance, our compression chips and macros run at 1 cycle/byte, up to 40-60
MByte/sec, performing exhaustive LZ77 compression, in lowcost devices on about
4 square mm of Silicon.  We can put our DES macro in spare space on the chip
and encrypt the compressed data at 32 cycles per 16 byte block.  This averages
half a byte per clock cycle, but since there is typically only about half as
much data at the output of the compressor, it is still at
20,40.. MByte/s and up referred to the raw data stream.

My purpose for being here is mainly to make sure you do not lock our algorithms
out of a market (again) where we want to compete and we have a lot to offer.
All I want is a reserved value for compression algorithm somewhere in the
header, and if there is going to be a default compression algorithm, to
compete for that designation.

When the PPP algorithm selection was done we did not participate fully. I think
it would be foolish for this group to simply adopt their algorithm selection,
which was at a different point in time, with both its own politics and
its own technical criteria.  For instance an important issue to many
vendors for PPP compression algorithm selection was availability and
performance in software on a 68302 in mid 1994.  The performance requirements
on systems where security is needed, such as LANS, are orders of magnitude
higher.

This is not vaporware, Network Systems is already using IMD's compression
hardware and software in their ip security implementation, which is a real
product.  Please don't argue key management and encryption algorithms for a
year and decide the compression algorithm supported with less consideration
and fairness than a coin flip.


                                    regards,

                                      Oscar Strohacker


Advisory Engineer/Scientist
Data Compression Systems Architecture
IBM Microelectronics Division
11400 Burnet Road
Austin Texas 78758

o (512) 838-4077      f (512) 838-7004         Internet: stroh @ vnet.ibm.com