Network Working Group R. Thayer Sable Technology Internet Draft July 1996 Compression Payload for Use with IP Security Status of this Memo 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). TABLE OF CONTENTS STATUS OF THIS MEMO.............................................1 ABSTRACT........................................................1 1. INTRODUCTION.................................................2 2. USE OF COMPRESSION FOR IP PACKETS............................2 2.1 INTERACTION WITH AH/ESP.....................................2 3. COMPRESSION PAYLOAD MESSAGE FORMAT...........................2 3.1 NEXT PAYLOAD................................................3 3.2 TYPE........................................................3 3.3 OPTIONS.....................................................3 3.4 IDENT.......................................................3 3.5 LENGTH......................................................3 4. SECURITY CONSIDERATIONS......................................3 5. REFERENCES...................................................4 6. AUTHOR'S ADDRESS.............................................4 Abstract This document describes a payload format to be used to store compressed protocol messages within an IP packet which is using security features as defined in [RFC-1825]. Thayer [Page 1] Internet Draft IP Compression with IPSEC Page 2 1. Introduction The introduction of security into packets transmitted using Internet IP (Version 4) [RFC-791] causes a change in the applicability of compression technology to data communications. Specifically, when a packet is encrypted, it becomes essentially random data, and therefore is highly incompressible. This makes it difficult to use conventional techniques to compress IP datagrams, such as PPP compression. To solve this problem it becomes desirable to compress the data before it is encapsulated with security features. 2. Use of Compression for IP packets The process of using data compression techniques for IP packets is a matter of processing the data in the following order, if IP Security is present: a. Source node generates packet b. IP packet is compressed c. (optional) ESP transform is applied to IP packet d. AH transform is applied to IP packet e. IP packet is transmitted Note that compression occurs BEFORE encryption. 2.1 Interaction with AH/ESP Since the 'payload' as seen by ESP (or AH) is no longer IPv4 or IPv6, the payload type field used with ESP, e.g. [Hughes] or AH [Atkinson] must specify a value indicating this is compressed. For purposes of this discussion draft, the value 99 should be used. This is defined in [RFC-1700] as "any private encryption scheme" and has been used by implementors in the past for compression [Thayer]. It is assumed that some more proper value from IANA will be eventually chosen. 3. Compression Payload Message Format 3322 2222 2222 1111 1111 1100 0000 0000 1098 7654 3210 9876 5432 1098 7654 3210 +------------+-----------+-------------+-----------+ |Next Payload| Type | Options | +------------+-----------+-------------+-----------+ | Ident | Length | +------------+-----------+-------------+-----------+ | ... compressed data ... + Thayer [Page 2] Internet Draft IP Compression with IPSEC Page 3 3.1 Next Payload is the type field of the next level of data, from [RFC-1700]. Note this is typically IPv4 or IPv6. 3.2 Type is the dialect of compression to use. The following values are predefined, others are t.b.d. 0 = no compression, pass-through 1 = ZLIB compression [ZLIB] 2 = private scheme 3..255 - undefined 3.3 Options This is a 16-bit field containing options for compression. The only bit defined at this time is: 0x0001 = flush history after this packet. Use of this field is specific to the compression dialect. The value defined here is specifically for use with ZLIB. 3.4 Ident This is an identifier for this packet. It may be used to determine if packets have been dropped or for other purposes. The field is 16 bits wide. The range of the identifier is dialect-specific. For dialect 0 (pass-through) it must be 0..65535. For dialect 1 (ZLIB) it must be in the range 0..255. 3.5 Length This is the length of the actual compressed data, in bytes. It is not necessary for the compressed data to be a multiple of 4 bytes. This counder covers the data only, not the header fields. 4. Security Considerations This protocol is specifically for use in an IP Security Context. It therefore is explicitly NOT intended to handle encryption (since ESP is doing that) or authentication (since AH is doing that). Thayer [Page 3] Internet Draft IP Compression with IPSEC Page 4 5. References [Atkinson] R. Atkinson, `IP Authentication Header'', draft-ietf- ipsec-auth-header-00.txt [Hughes] J. Hughes, `Combined DES-CBC, HMAC and Replay Prevention Security'' June 1996, Internet Draft draft-ietf- ipsec-esp-des-md5-02.txt [RFC-1700] J. Reynolds, J. Postel, "ASSIGNED NUMBERS", 10/20/1994. (Pages=230) (Format=.txt) (Obsoletes RFC1340) (STD 2) [RFC-1825] R. Atkinson, "Security Architecture for the Internet Protocol", 08/09/1995. (Pages=22) (Format=.txt) [RFC-791] J. Postel, "Internet Protocol", 09/01/1981. (Pages=45) (Format=.txt) [Thayer] R. Thayer, `WHR Accelerator Compression Encapsulation Protocol', March 1994, presented at Compression BOF at Seattle IETF. [ZLIB] L. P. Deutsch, J. Gailly, `ZLIB Compressed Data Format Specification version 3.3'' draft-deutsch-zlib-spec-01.txt 6. Author's Address Rodney Thayer Sable Technology Corporation 246 Walnut Street Newton Massachusetts 02160 rodney@sabletech.com +1 617 332 7292 Thayer [Page 4]