Compression is used in communications to reduce the size of data for increased per-formance and efficient use of bandwidth. By sending a smaller packet over the wire, less bandwidth is required, thus allowing more data over the same pipe. This is very common in voice networks where two conversations can be placed on a single DS0 normally designed for one conversation. Voice over IP (VoIP) is infamous for huge compression of data and limiting the little things that are often taken for granted — such as clarity in some cases.
Compression is designed to identify patterns and duplicated data within a file or package. Once found, the repetitions and patterns are indexed and associated with the data that is compressed to provide the necessary information for decompression. An interesting phenomenon can be experienced when encrypted data is compressed.
Because well-encrypted data has little or no repetition or patterns in the data stream, the compression algorithm will actually increase the size of the data. Various commu-nications that implement encryption techniques after the network layer, will experience performance issues and fragmentation.
The IP Payload Compression (IPComp) protocol was designed to allow IP com-munications to be compressed at the network layer. Because IPSec operates at the network layer, the encryption can be applied after the compression — eliminating the data expansion problem. Some compression algorithms utilize histories to reduce repetition in the processing of data for compression. This allows the algorithm to become more efficient over time. Unfortunately, this requires that the communicating systems maintain the state of the communication to align the compression information — referred to as stateful. Because IP is not a guaranteed service and packets can arrive out of order, the abilities provided by the history function of many compression protocols cannot be utilized.
PCP IP protocol, IANA protocol 108, includes a very simple 32-bit header. As with many headers, there is an 8-bit field to identify the next payload, an 8-bit field reserved for the IANA, and finally a 16-bit field for the CPI. The Compression Parameter Index (CPI) is an identifier that acts much like an SPI and defines the IPComp Association (IPCA) that can be automatically negotiated by ISAKMP. In the IPSec DOI, there are four types of IPSec security protocol identifiers. Two (AH and ESP) have been discussed in great detail. The others are ISAKMP and IPCOMP, allowing the key management protocol to negotiate on behalf of IKE itself, IPSec, and IPComp. As with transform sets in IKE to define the protection suite to be applied to data, such as ESP_DES, ESP_3DES, and AH_HMAC_MD5, among others, there are transform identifiers for IPComp that can be used to negotiate compression algorithms between the peers.
Both systems must agree to establish an IPCA, as with IKE SAs and IPSec SAs. The values are as follows:
RESERVED 0 IPCOMP_OUI 1 IPCOMP_DEFLATE 2 IPCOMP_LZS 3
IPComp_OUI is a proprietary compression algorithm that can be agreed upon by the peers. This is usually accompanied by attribute fields to communicate the specifics of the algorithm. Typically, vendors will identify that they are communicating with a known device and implement a custom compression algorithm to increase performance.
IPComp_Deflate specifies the use of the zlib algorithm, and IPComp_LZS specifies the use of the Static Electronics algorithm.
As far as the IPCA is concerned, that is about all there is to it; no keys, cookies, or nonces to negotiate, just simply the algorithm and the identity of the association.
Processing IPComp, inbound and outbound, has some interesting aspects in that it does not always happen when configured to do so. In outbound processing, the compression is, of course, applied prior to encryption, or authentication; therefore, compression occurs before AH or ESP is applied. The type of information that is compressed can be upper layer information, as with transport mode, or an entire IP datagram, as with tunnel mode (see Exhibit 7-23). Once the compression is complete, an IPComp header is placed on the compressed data and the next header field is populated with the protocol that was compressed, such as 4, representing an IP header if tunnel mode is employed for IP traffic. Last, the header and compressed data are passed to IPSec for processing. IPSec applies a security protocol (e.g., ESP) and populates the next header field in the ESP header with 108 — IPComp. If the com-pression was unsuccessful, no IPComp header is applied and ESP is applied to the IP datagram and has the next header field populated with the value that represents the
original communication protocol. The elimination of the IPComp header in the event of an error simplifies the entire process. Rather than providing an error message that complicates the input of the peer, the recipient of the packet simply ignores the fact that it was not compressed and processes it as normal. Given that IPComp is a stateless protocol, because it operates within IP, there is no need to provide errors or acknowl-edgments, thus liberating the peer to operate in a local state — doing what is necessary on a packet-by-packet level at any particular moment in the communication.
As the peer receives an IPSec payload, which it identified because the protocol field in the IP header is AH, or ESP as with this example, it de-encrypts and de-encapsulates the datagram and inspects the next header field in the ESP header. If the value of 108 is discovered, the IPComp header is inspected to determine the IPCA and the next header to be expected once decompression is complete. After decompression is com-plete, the data is processed as normal and all compression information associated with that datagram is discarded. An interesting aspect of inbound processing, very similar to outbound, is the lack of errors in the event an IPComp header is not present in the payload. Of course, this means that the initiator did not perform compression for some reason — possibly an error — and applied ESP to the datagram normally. Although the recipient of the datagram has an established IPCA and expects an IPComp header for each packet, it does not really matter if it is absent.
There are many reasons that IPComp may not choose to compress the datagram.
One aspect is that if the compressed data and the header combine to be equal to or greater than the original upper layer data, the datagram must not be compressed.
Otherwise, the process will defeat the purpose of implementing compression and result in performance problems. It will affect performance in not only processor overhead and inefficient use of available bandwidth, but the expansion of the data causes frag-mentation given that MTU discovery processes will not take into consideration an increased datagram. Small datagrams can fall victim to increased size post compression.
The compression-specific data that must be associated with the original data can increase the size of the final payload. To accommodate this foreseeable event, thresholds can be implemented to simply ally compression to datagrams with a defined minimum size.
Another example of when compression may not be applied is when the datagram has already been compressed by another process or application. The first question is: how Exhibit 7-23. IPComp header placement.
can the IPComp tell what has been previously compressed? The IPComp compression protocol can make determinations about the outbound traffic with regard to the success rate of the compression algorithm. As a certain number of consecutive packets unsuc-cessfully compress, the system will not attempt to apply compression for a predefined number of following packets. Once the number of uncompressed packets has been met, compression is attempted again. If the compression fails for a number of times again, the cycle repeats. The number of failures and number of packets to not pass to the compression algorithm are implementation specific and can be some of the attributes negotiated during IKE. The concept of stopping the compression after failure is to accommodate certain data flows that may be mixed with other datagrams that need to be compressed. By flipping on and off, one hopes to avoid sections that cannot be compressed and compress the data streams that can benefit from compression.