One document matched: draft-thomas-ippcp-compression-00.txt

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 
   <TDB>.

   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 
   <value is TBD by IANA> 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]