Subject: <draft-ietf-ippcp-protocol-02.txt>

From: Avram Shacham <[email-masked]>
Date: Tue, 18 Nov 1997 15:00:57 +0200

Following the recent IPPCP WG mailing-list discussions, I modified the IP
Payload Compression Protocol document to include the requested
clarifications. The new document is titled <draft-ietf-ippcp-protocol-02.txt>.

As the 11-21-97 date is getting closer, this message contains the new
document, thus hoping to get a faster feedback.

Looking forward to your prompt comments,
avram

Summary of the changes from <draft-ietf-ippcp-protocol-01.txt>:

a) 2.1.  Compressed Payload
Paragraph 4 - The compression algorithm is responsible to provide a
compressed payload in whole octet units.
Paragraph 5 - Refering to "The original content of the Next Header (IPv6) or
protocol (IPv4) field...", instead of using only "Next Header field".

b) 2.2.  Anti-Expansion Policy
Paragraph 4 - The compressibility test is "algorithm dependent", a phrase
more accurate than "implementation dependent."

c) 3.1. IPv4 Header Modifications
Explicit reference to Header Checksum.

d) 3.3.  IPComp Header Structure
Clarifications of CPI characteristics and usage.

e) 5. Security Considerations
Paragraph 1 - Modified "...transport header fields..." to "...transport
layer header fields..."

f) Several typos were corrected.

=== <draft-ietf-ippcp-protocol-02.txt> - start ===

INTERNET-DRAFT                                         A. Shacham, Cisco
IP Payload Compression Protocol Working Group          R. Monsour, Hi/fn
Expires in six months                               R. Pereira, TimeStep
                                           M. Thomas, AltaVista Internet
                                                           November 1997

               IP Payload Compression Protocol (IPComp)
                  <draft-ietf-ippcp-protocol-02.txt>

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 view the entire list of current Internet-Drafts, please check
   the "1id-abstracts.txt" listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
   (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
   Coast), or ftp.isi.edu (US West Coast).

   Distribution of this memo is unlimited.

Abstract

   This document describes a protocol intended to provide lossless
   compression for Internet Protocol datagrams in an Internet
   environment.

1. Introduction

   IP payload compression is a protocol to reduce the size of IP
   datagrams.  This protocol will increase the overall communication
   performance between a pair of communicating hosts/gateways ("nodes")
   by compressing the datagrams, provided the nodes have sufficient
   computation power, through either CPU capacity or a compression
   coprocessor, and the communication is over slow or congested links.

   IP payload compression is especially useful when encryption is
   applied to IP datagrams.  Encrypting the IP datagram causes the data
   to be random in nature, rendering compression at lower protocol
   layers (e.g., PPP Compression Control Protocol [RFC-1962])
   ineffective.  If both compression and encryption are required,
   compression MUST be applied before encryption.

   This document defines the IP payload compression protocol (IPComp),
   the IPComp packet structure, the IPComp Association (IPCA), and
   several methods to negotiate the IPCA.

Shacham, Monsour, Pereira, Thomas                               [Page 1]

INTERNET DRAFT                   IPComp                    November 1997

   Other documents shall specify how a specific compression algorithm
   can be used with the IP payload compression protocol.

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
   datagram, after being compressed and decompressed, is identical to
   the original IP datagram.

   Each IP datagram is compressed and decompressed by itself without any
   relation to other datagrams ("stateless compression"), as IP
   datagrams may arrive out of order or not arrive at all.  Each
   compressed IP datagram encapsulates a single IP datagram.

   Processing of inbound IP datagrams MUST support both compressed and
   non-compressed IP datagrams, in order to meet the non-expansion
   policy requirements, as defined in section 2.2.

   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.  In addition, in IP
   version 6 [RFC-1883], the compression of outbound IP datagrams MUST
   be done before the addition of either a Hop-by-Hop Options header or
   a Routing Header, since both carry information that must be examined
   and processed by possibly every node along a packet's delivery path,
   and therefore MUST be sent in the original form.

   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.

2.1. Compressed Payload

   The compression is applied to a single array of octets, which are
   contiguous in the IP datagram.  This array of octets always ends at
   the last octet of the IP packet payload.  Note: a contiguous array of
   octets in the IP datagram may be not contiguous in physical memory.

   In IP version 4 [RFC-0791], the compression is applied to the upper
   layer protocol (ULP) payload of the IP datagram.  No portion of the
   IP header or the IP header options is compressed.

Shacham, Monsour, Pereira, Thomas                               [Page 2]

INTERNET DRAFT                   IPComp                    November 1997

   In the IPv6 context, IPComp is viewed as an end-to-end payload, and
   therefore MUST apply after hop-by-hop, routing, and fragmentation
   extension headers.  The compression is applied starting at the first
   IP Header Option field which does not carry information that must be
   examined and processed by nodes along a packet's delivery path, if
   such IP Header Option field exists, and continues to the ULP payload
   of the IP datagram.

   The size of a compressed payload, generated by the compression
   algorithm, MUST be in whole octet units.

   As defined in section 3, an IPComp header is inserted immediately
   preceding the compressed payload.  The original IP header is modified
   to indicate the usage of the IPComp protocol and the reduced size of
   the IP datagram.  The original content of the Next Header (IPv6) or
   protocol (IPv4) field is stored in the IPComp header.

   The decompression is applied to a single contiguous array of octets
   in the IP datagram.  The start of the array of octets immediately
   follows the IPComp header and ends at the last octet of the IP
   payload.  If the decompression process is successfully completed, the
   IP header is modified to indicate the size of the decompressed IP
   datagram, and the original next header as stored in the IPComp
   header.  The IPComp header is removed from the IP datagram and the
   decompressed payload immediately follows the IP header.

2.2. Non-Expansion Policy

   If the size of a compressed IP datagram, including the IP header,
   the IPComp header as defined in section 3, and the compressed
   payload, is not smaller than the size of the original IP datagram,
   the IP datagram MUST be sent in the original non-compressed form.
   To clarify:  If an IP datagram is sent non-compressed, no IPComp
   header is added to the datagram.  This policy ensures saving the
   decompression processing cycles and avoiding incurring IP datagram
   fragmentation when the expanded datagram is larger than MTU.

   Small IP datagrams are likely to expand as a result of compression.
   Therefore, a numeric threshold SHOULD be applied before compression,
   where IP datagrams of size smaller than the threshold are sent in
   the original form without attempting compression.  The numeric
   threshold is implementation dependent.

   An IP datagram with payload that has been previously compressed
   tends not to compress any further.  The previously compressed payload
   may be the result of external processes, such as compression applied
   by an upper layer in the communication stack, or by an off-line
   compression utility.  An adaptive algorithm SHOULD be implemented to
   avoid the performance hit.  For example, if the compression of i
   consecutive IP datagrams of an IPCA fails, the next k IP datagrams
   are sent without attempting compression.  If the next j datagrams
   are also failing to compress, the next k+n datagrams are sent without
   attempting compression.  Once a datagram is compressed successfully,
   the normal process of IPComp restarts.  The adaptive algorithm

Shacham, Monsour, Pereira, Thomas                               [Page 3]

INTERNET DRAFT                   IPComp                    November 1997

   including all the related thresholds is implementation dependent.

   During the processing of the payload, the compression algorithm
   MAY periodically apply a test to determine the compressibility of
   the processed data, similar to the requirements of [V42BIS].  The
   nature of the test is algorithm dependent.  Once the compression
   algorithm detects that the data is non-compressible, the algorithm
   SHOULD stop processing the data, and the payload is sent in the
   original non-compressed form.

3. Compressed IP Datagram Header Structure

   A compressed IP datagram is encapsulated by modifying the IP header
   and inserting an IPComp header immediately preceding the compressed
   payload.  This section defines the IP header modifications both in
   IPv4 and IPv6, and the structure of the IPComp header.

3.1. IPv4 Header Modifications

   The following IPv4 header fields are set before transmitting the
   compressed IP datagram:

      Total Length

         The length of the entire encapsulated IP datagram, including
         the IP header, the IPComp header and the compressed payload.

      Protocol

         The Protocol field is set to 108, IPComp Datagram, [RFC-1700].

      Header Checksum

         The Internet Header checksum [RFC-0791] of the IP header.

   All other IPv4 header fields are kept unchanged, including any header
   options.

3.2. IPv6 Header Modifications

   The following IPv6 header fields are set before transmitting the
   compressed IP datagram:

      Payload Length

         The length of the compressed IP payload.

      Next Header

         The Next Header field is set to 108, IPComp Datagram,
         [RFC-1700].

   All other IPv6 header fields are kept unchanged, including any
   non-compressed header options.

Shacham, Monsour, Pereira, Thomas                               [Page 4]

INTERNET DRAFT                   IPComp                    November 1997

   The IPComp header is placed in an IPv6 packet using the same rules as
   the IPv6 Fragment Header.  However if an IPv6 packet contains both an
   IPv6 Fragment Header and an IPComp header, the IPv6 Fragment Header
   MUST precede the IPComp header in the packet.

3.3.  IPComp Header Structure

   The four octet header has the following structure:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |     Flags     | Compression Parameter Index |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Next Header

        8-bit selector.  Stores the IPv4 Protocol field or the IPv6
        Next Header field of the original IP header.

   Flags

        8-bit field.  Reserved for future use.  Must be set to zero.

   Compression Parameter Index (CPI)

        16-bit index.  The CPI is stored in network order.  The values
        0-63 are defined by IANA and are used for manual setup, which
        requires no additional information.  The values 64-61439 are
        negotiated between the two nodes in definition of an IPComp
        Association, as defined in section 4.  The values 61440-65535
        are for private use among mutually consenting parties.  Both
        nodes participating can select a CPI value independently of each
        other and there is no relationships between the two separately
        chosen CPIs.  The outbound IPComp header MUST use the CPI value
        chosen by the decompressing node.  The CPI in combination with
        the destination IP address uniquely identifies the compression
        algorithm characteristics for the datagram.

4. IPComp Association (IPCA) Negotiation

   To utilize the IPComp protocol, two nodes MUST first establish an
   IPComp Association (IPCA) between them.  The IPCA includes all
   required information for the operation of IPComp, including the
   Compression Parameter Index (CPI), the mode of operation, the
   compression algorithm to be used, and any required parameter for the
   selected compression algorithm.  The IPComp mode of operation is
   either a node-to-node policy where IPComp is applied to every IP
   packet between the nodes, or an ULP session based policy where only
   selected ULP sessions between the nodes are using IPComp.  For each
   IPCA, a different compression algorithm may be negotiated in each
   direction, or only one direction may be compressed.  The default is
   "no IPComp compression".

Shacham, Monsour, Pereira, Thomas                               [Page 5]

INTERNET DRAFT                   IPComp                    November 1997

   The IPCA is established by dynamic negotiations or by static
   configuration.  The dynamic negotiations SHOULD use the Internet
   Security Association and Key Management Protocol [ISAKMP], where
   IPSec is present.  The dynamic negotiations MAY be implemented
   through a different protocol.

4.1. Use of ISAKMP

   For IPComp in the context of IP Security, ISAKMP provides the
   necessary mechanisms to establish IPCA.  IPComp Association is
   negotiated by the initiator using a Proposal Payload, which would
   include one or more Transform Payloads.  The Proposal Payload would
   specify a compression protocol in the protocol id field and each
   Transform Payload would contain the specific compression method(s)
   being offered to the responder.

   In the Internet IP Security Domain of Interpretation (DOI) [SECDOI],
   IPComp is negotiated as the Protocol ID PROTO_IPCOMP.  The
   compression algorithm is negotiated as one of the defined IPCOMP
   Transform Identifiers.

4.2. Use of Non-ISAKMP Protocol

   The dynamic negotiations MAY be implemented through a protocol other
   than ISAKMP.  Such protocol is beyond the scope of this document.

4.3. Static Configuration

   Nodes may establish IPComp Associations using static configuration.
   For this method, a limited number of Compression Parameters Indexes
   (CPIs) is designated to represent a list of specific compression
   methods.

5. Security Considerations

   IP payload compression potentially reduces the security of the
   Internet, similar to the effects of IP encapsulation [RFC-2003].  For
   example, IPComp makes it difficult for border routers to filter
   datagrams based on header fields.  In particular, the original value
   of the Protocol field in the IP header is not located in its normal
   positions within the datagram, and any transport layer header fields
   within the datagram, such as port numbers, are neither located in
   their normal positions within the datagram nor presented in their
   original values after compression.  A filtering border router can
   filter the datagram only if it shares the IPComp Association used for
   the compression.  To allow this sort of compression in environments
   in which all packets need to be filtered (or at least accounted for),
   a mechanism must be in place for the receiving node to securely
   communicate the IPComp Association to the border router.  This might,
   more rarely, also apply to the IPComp Association used for outgoing
   datagrams.

Shacham, Monsour, Pereira, Thomas                               [Page 6]

INTERNET DRAFT                   IPComp                    November 1997

   When IPComp is used in the context of IPSec, it is not believed to
   have an effect on the underlying security functionality provided by
   the IPSec protocol; i.e., the use of compression is not known to
   degrade or alter the nature of the underlying security architecture
   or the encryption technologies used to implement it.

6. References

   [RFC-0791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC-1700] Reynolds, J., Postel, J., "Assigned Numbers", RFC 1700,
              October 1994.

   [RFC-1883] Deering, S., Hinden, R., "Internet Protocol, Version 6
              (IPv6) Specification", RFC 1883, April 1996.

   [RFC-1962] Rand, D., "The PPP Compression Control Protocol (CCP)",
              RFC 1962, June 1996.

   [RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
              October 1996.

   [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997.

   [ISAKMP]   Maughan, D., Schertler, M., Schneider, M., and Turner, J.,
              "Internet Security Association and Key Management
              Protocol (ISAKMP)", Internet-Draft:
              draft-ietf-ipsec-isakmp-08.txt, Work in Progress,
              July 1997.

   [SECDOI]   Piper, D., "The Internet IP Security Domain of
              Interpretation for ISAKMP", Internet-Draft:
              draft-ietf-ipsec-ipsec-doi-02.txt, Work in Progress,
              February 1997.

   [V42BIS]   CCITT, "Data Compression Procedures for Data Circuit
              Terminating Equipment (DCE) Using Error Correction
              Procedures", Recommendation V.42 bis, January 1990.

Authors' Information

   Abraham Shacham
   Cisco Systems
   101 Cooper Street
   Santa Cruz, California 95060
   United States of America
   Email: [email-masked]

Shacham, Monsour, Pereira, Thomas                               [Page 7]

INTERNET DRAFT                   IPComp                    November 1997

   Robert Monsour
   Hi/fn Inc.
   2105 Hamilton Avenue, Suite 230
   San Jose, California 95125
   United States of America
   Email: [email-masked]

   Roy Pereira
   TimeStep Corporation
   362 Terry Fox Drive
   Kanata, Ontario K2K 2P5
   Canada
   Email: [email-masked]

   Matt Thomas
   AltaVista Internet Software
   30 Porter Road
   Littleton, Massachusetts 01460
   United States of America
   Email: [email-masked]

Working Group

   The IP Payload Compression Protocol (IPPCP) working group can be
   contacted through its chair:

   Naganand Dorswamy
   Bay Networks
   Email: [email-masked]

Shacham, Monsour, Pereira, Thomas    Expires in six months      [Page 8]

=== <draft-ietf-ippcp-protocol-02.txt> - end ===