Compression and Encryption in IPSec
As more organizations open their intranets to remote users, suppliers and trading partners, security becomes increasingly important. Although encryption is not currently the most common security mechanism, its use will likely rise with the finalization of the IETF Internet Protocol Security (IPSec) standard in 1998.
However, encryption is very compute-intensive and can reduce performance dramatically. In many areas of performance, compression can help to mitigate performance delays. However, according to the IETF, the use of a higher-layer encryption protocol such as IPSec "reduces the effectiveness" of lower-layer compression protocols, such as PPP. This reduced effectiveness occurs because encrypted data cannot be compressed.
The compression process searches for redundant data strings in a file, and replaces the redundant strings with a token, thus reducing (compressing) the size of the file. The encryption process, on the other hand, randomizes data, making it unrecognizable. In an ideal randomization process, all redundancy is eliminated, so that compression becomes impossible or, at the very least, ineffective.
There are various Internet protocols and products that incorporate compression and/or encryption functions in their processes. However, problems arise if encryption is performed before compression. For example, IPSec, a layer 3 protocol, performs security functions but no compression functions; but PPP (Point-to-Point Protocol), a layer 2 protocol incorporates both compression and security functions. For example, when you are sending data, the network layer processing occurs first, which is where IPSec encryption occurs. Later, as the data gets closer to the wire, before sending the packet, PPP compression would normally be applied. But, according to Bob Monsour, vice president of marketing at Hi/fn (San Jose, Calif., www.hifn.com), an OEM networking products company, "once you do IPSec encryption, which randomizes the data, there is no more redundancy for the subsequent PPP compression to identify, which makes PPP compression ineffective. Therefore, the order in which compression and encryption are performed is important."
In order to overcome this problem, and incorporate the opportunity to use both compression and encryption effectively in IPSec, the IETF has established the IP Payload Compression (IPPC) working group to outline the proper process.
The IPPC working group is developing protocol specifications that define how payloads can be compressed before they are processed by an encryption protocol. The specifications will require that compression operations be performed before encryption of a payload by a protocol such as IPSec.
The two specifications, which currently will be negotiated, are LZS, by Hi/fn, and DEFLATE, designed by Phil Katz, president of PKWARE Inc. (Brown Deer, Wis., www.pkware.com) and creator of the PKUnzip compression utility. LZS compression is a lossless compression algorithm applied to IP datagram payloads. It is widely used today in networks in many routers, firewall, remote access servers and ISDN connectivity products. In order to solidify its position in the market, Hi/fn has recently acquired Cylan's Technologies and its IPSECure product, which performs compression and encryption according to IPPC working group guidelines. The DEFLATE protocol has been used for many years in networks on modem and other point-to-point links to transfer files for PCs and workstations.
The working group has already written a draft, which defines how to apply the Hi/fn LZS compression technique to the IPPC protocol. Although no date for finalization of the draft standard is available, users should know that in March 1998, at an interoperability workshop, 30 companies tested the implementation of IPSec, and six of those also tested the IPPC protocol.