Network Working Group R. Thayer Expire in six months Sable Technology Internet Draft March 1997 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). 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]. 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 2.1.1 Relationship to Combined Transforms .....................3 3. COMPRESSION PAYLOAD MESSAGE FORMAT...........................3 3.1 NEXT PAYLOAD................................................3 Thayer [Page 1] Internet Draft IP Compression with IPSEC Page 2 3.2 TYPE........................................................3 3.3 OPTIONS.....................................................3 3.4 IDENT.......................................................3 3.5 LENGTH......................................................4 4. SECURITY CONSIDERATIONS......................................4 5. REFERENCES...................................................4 6. AUTHOR'S ADDRESS.............................................5 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 Thayer [Page 2] Internet Draft IP Compression with IPSEC Page 3 compression [Thayer]. It is assumed that some more proper value from IANA will be eventually chosen. 2.1.1 Relationship to Combined Transforms Since there is no compression scheme ('bit') defined in the ESP transforms under discussion at the time of publication, this draft still represents a relevant proposal. As before, the proposal is to simply do the compression outside of ESP. 3. Compression Payload Message Format (Byte 0) (Byte 3) +------------+-----------+-------------+-----------+ |Next Payload| Type | Options | +------------+-----------+-------------+-----------+ | Ident | Length | +------------+-----------+-------------+-----------+ | ... compressed data ... + 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 = Hi/Fn 3 = IBM ALDC 4 = private scheme 5..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 Thayer [Page 3] Internet Draft IP Compression with IPSEC Page 4 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). 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 Thayer [Page 4] Internet Draft IP Compression with IPSEC Page 5 6. Author's Address Rodney Thayer Sable Technology Corporation 246 Walnut Street Newton Massachusetts 02160 rodney@sabletech.com +1 617 332 7292 Thayer [Page 5]