HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 11:53:38 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 17 Mar 1998 16:31:00 GMT ETag: "3ddb05-2d84-350ea544" Accept-Ranges: bytes Content-Length: 11652 Connection: close Content-Type: text/plain Compression Working Group Matt Thomas Internet Draft AltaVista Internet Software July 1997 The Compressed Payload Header draft-thomas-ippcp-compression-00.txt Abstract This doucment defines the Compressed Payload Header. The Compressed Payload Header encapsulates payloads (TCP header and data for instance) which have been compressed for traversal of the network. The Compressed Payload Header is generally used in conjunction with the IP Security Headers. Status of This Memo This document is a submission to the Compression Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ippcp@external.cisco.com mailing list. This document is not at this time a product of the Compression Working Group, but a proposal to become a product of the Compression Working Group. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Table Of Contents 1. Introduction 3 1.1. Specification of Requirements 3 2. Compression Process 3 3. Compression Model 4 4. Compressed Payload Header Format 4 5. Negotiation 5 Expires December 1997 [Page 1] Internet Draft The Compressed Payload Header July 1997 6. Security Considerations 5 7. Acknowledgements 5 8. References 5 9. Authors' Addresses 6 Expires December 1997 [Page 2] Internet Draft The Compressed Payload Header July 1997 1. Introduction The use of IP Security will prevent layers below IP from being able to compress data. Thus in addition to the computational overhead of IP Security, IP Security will also cause a significant loss in effective throughput on those network paths that use compression at the datalink level or below (e.g PPP). To aleviate this, before the data is encrypted by IP Security it may be compressed. For this case, the Compressed Payload Header has been created. A notion of a Compress Association is used in this document. It refers to a set of compression information relating to a network connection or a set of network connections. It is analagous to a Security Assocation as used by IP Security. 1.1. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC-2119]. 2. Compression Process The compression processing of IP datagrams has two phases, compressing of outbound IP datagrams ("Compression") and decompressing of inbound datagrams ("Decompression"). The compression processing MUST be lossless, ensuring that the IP atagram after being Compressed and Decompressed is identical to the original IP datagram. The Compression of outbound IP datagrams MUST be done before any IP security processing, such as encryption and authentication, and before any fragmentation of the IP datagram. Similarly, the Decompression of inbound IP datagrams MUST be done after the reassembly of the IP datagrams, and after the completion of all IP security processing, such as authentication and decryption. Processing of inbound IP datagrams MUST support both Compressed and non-compressed IP datagrams. The Compression is applied to only the upper layer protocol (ULP) payload and does not include the IP header or other optional headers such as the Hop-By-Hop header or Routing header. The size of a Compressed datagram is always in whole octet units. If the Compressed ULP is larger than the initial ULP, then Compressed ULP is discarded and the initial ULP is transmitted. The Compresser SHOULD keep track of successful compressions versus unsuccessful compressions. Expires December 1997 [Page 3] Internet Draft The Compressed Payload Header July 1997 3. Compression Model One posconceptual model that can be used is to only compress when it will result in an overall increase in network throughput. If the Compression Process results in a decrease in network throughput then Compression SHOULD be stopped and the packets transmitted uncompressed. If it consumes more resources to compress the ULP and transmit a Compressed datagram than it does transmit the Original datagram then that ULP should not have been compressed. A hueristic to see if an ULP is compressable might be try to compress the ULP and if, at some point in, the ULP is not compressing, abort the compression process. The point at which the test is performed could vary depending on how successful previous compression attempts have been. The more successful, the further into the ULP the point could be. The less successful, the closer to the beginning of the ULP. This would try to minimize the time trying to compress uncompressable data. 4. Compressed Payload Header Format With inspiration from IPv6, the following header is defined as: 0 32 32+N EOP +-------------------+--------+...--------------+ | CPI | CHDR | compressed data | +-------------------+--------+...--------------+ CPI The Compression Parameters Index (CPI) is a 32-bit pseudo-random value identifying the compression association for this datagram. The Compression Parameters Index value 0 is reserved to indicate that "no compression association exists"; this value should only be used for development purposes. The set of Compression Parameters Index values in the range 1 through 255 are reserved to the Internet Assigned Numbers Authority (IANA) for future use. A reserved CPI value will not normally be assigned by IANA unless the use of that particular assigned CPI value is openly specified in an RFC. A reserved CPI value SHALL NOT have implicit state (payload type, ports, etc.). CHDR The Compression Header is a variable-length per-algorithm area which contains information on how to decompress the compressed data. This header MAY end on a byte boundary. The payload type (protocol type) of the Compress Payload Header is . The payload type of the compressed data MUST be obtained from either Expires December 1997 [Page 4] Internet Draft The Compressed Payload Header July 1997 the Compression Association, the Compression Header, or the compressed data. How is it obtained is algorithm-specific. Note that compression can be negotiated without AH or ESP. The Compression Algorithm SHOULD detect data corruption in the compressed payload. 5. Negotiation Before the compressed Payload Header can be used, it must be known that the destination can decode the Compressed Payload Header. This can be done either manually or be negotiated using ``Internet Security Association and Key Management Protocol (ISAKMP)'' [ISAKMP], ``The resolution of ISAKMP with Oakley'' [OAKLEY], and `The Internet IP Security Domain of Interpretation for ISAKMP'' [IPDOI]. When negotiating for the use of the Compressed Payload Header, an ISAKMP proposal payload is generated with the PROTOCOL-ID set to CPH and a non-zero number of Transform payloads, one for each compression protocol supported. When specifying the CPI in the proposal payload, the CPI is placed in first 4 bytes of SPI field in network order and remaining 4 bytes are filled with 0. If the negotiation fails, then compression MUST NOT be used. 6. Security Considerations This protocol presents a challenge to security gateways. It is expected that when the Compressed Payload Header is not encapulated in an Encapsulating Security Payload, the CPI in conjuction with the source and destination addresses will be used by security gateways to permit or deny passage of the packet. Any packet not matching the identities (e.g. protocol and/or port) of establishers of the CPI MUST be discarded by the destination node and, optionally, an audit entry SHOULD be created. 7. Acknowledgements I'd like to thank Avram Shacham from whom I plagarized the Compression Process section. I'd also like to acknowledge Thomas Natren for acting as a soundboard. 8. References [RFC-2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", Best Current Practices, March 1997 [IPDOI] D. Pipper, "The Internet IP Security Domain of Interpretation for ISAKMP", draft-ietf-ipsec-ipsec-doi-02.txt, Febuary 1997 Expires December 1997 [Page 5] Internet Draft The Compressed Payload Header July 1997 [ISAKMP] D. Maughan, M. Schertler, M. Schneider, J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", draft-ietf-ipsec-isakmp-07.txt, March 1997 [OAKLEY] D. Harkins, D. Carrel, "The resolution of ISAKMP with Oakley", draft-ietf-ipsec-isakmp-oakley-03.txt, March 1997 9. Authors' Addresses Matt Thomas AltaVista Internet Software 30 Porter Road Littleton, MA 01460 Email: matt.thomas@altavista-software.com Expires December 1997 [Page 6]