Internet Draft                                 R. Monsour, Hi/fn, Inc.
Expires in six months                 R. Pereira, TimeStep Corporation
                                             A. Shacham, Cisco Systems
                                                         July 30, 1997



              IP Payload Compression Protocol Architecture
                     <draft-ietf-ippcp-arch-00.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 draft documents are valid for a maximum of six months
   and may be updated, replaced, or obsolete 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 memo is unlimited.

Abstract

   This memo describes an architecture for applying lossless compression
   to Internet Protocol datagrams. It defines several of the key
   architectural elements of a compression protocol and describes
   alternatives for each element.

Acknowledgments

   The authors gratefully acknowledge the many sources of input who made
   this draft possible, including Rodney Thayer, Bob Moskowitz, Naganand
   Doraswamy, Thomas Narten and all those that participated in the early
   discussions and debates of these concepts. It is hoped that the
   continued focused effort of those involved in the IPCCP Working Group
   will result in the rapid development of a useful IP compression
   protocol.





R. Monsour, R. Pereira, A. Shacham                               [Page =
1]


Internet Draft       draft-ietf-ippcp-arch-00.txt           July 29, =
1997


Table of Contents

   1. Introduction...................................................2
      1.1. Background................................................2
      1.2. IP Payload Compression Overview...........................3
      1.3. Specification of Requirements.............................3
   2. Use of IP Compression with IPSec...............................3
      2.1. General Compression Processing............................3
      2.2. Alternative Compression Protocol Approaches...............4
         2.2.1. The IP Encapsulation Approach........................4
         2.2.2. The IP Header Approach...............................5
         2.2.3. Comparison of the Two Approaches.....................7
      2.3. Interaction of IP Payload Compression with AH & ESP.......7
   3. IP payload Compression without IPSec...........................7
   4. Anti-expansion of Payload Data.................................8
   5. Stateless vs. Stateful compression.............................8
   6. Negotiation Mechanisms for IP Compression......................8
      6.1. Use of ISAKMP in IPSec Contexts...........................9
         6.1.1. Compression as a "Protocol"..........................9
         6.1.2. Compression as a Protocol Attribute.................10
      6.2. Static Configuration for Non-IPSec Contexts..............10
   7. Implications with Ipv4 and Ipv6...............................11
   8. Compression Method/Format Registration Mechanism..............11
   9. Document Roadmap..............................................11
   10. Security Considerations......................................12
   11. References...................................................13
   12. Authors' Addresses...........................................14
   13. Working Group................................................14



1.   Introduction

   This document is a submission to the IETF IP Payload Compression
   Protocol (IPCCP) Working Group. Comments are solicited and should be
   addressed to the working group mailing list =
(ippcp@external.cisco.com)
   or to the editor.


1.1. Background

   The motivation for the development of the IP Payload Compression
   Protocol was initially driven by the use of the IP Security protocol
   and the negative   effect that IP encryption has on data link layer
   compression techniques. Encrypted data is random in nature and not
   compressible.  When an IP datagram is encrypted, compression methods
   used at lower protocol layers, e.g., the PPP Compression Control
   Protocol [RFC-1962], are rendered ineffective.  If both compression
   and encryption are desired, compression must be performed first. Such


R. Monsour, R. Pereira, A. Shacham                               [Page =
2]


Internet Draft       draft-ietf-ippcp-arch-00.txt           July 29, =
1997


   motivation drove the creation of a new working group, the IP Payload
   Compression Protocol working group, and the development of this
   document.


1.2. IP Payload Compression Overview

   The IP payload compression architecture is designed to provide
   compression services for the IP Protocol. Two fundamental =
requirements
   of such a compression protocol are: (1) that it supports the use of
   any lossless compression method, and (2) the two communicating =
parties
   have a mechanism to negotiate the use of specific compression method
   and any related parameters.

   This document describes the architectural alternatives available for
   supporting lossless compression services for IP datagrams. The
   following topics are discussed:

   a)   alternative approaches for integrating compression with IP
        Security
   b)   features of an IP compression protocol
   c)   negotiation and use of lossless compression techniques, both in
        the presence and absence of the IP Security protocol
   d)   requirements for a registration mechanism used for identifying
        compression methods for use with the protocol
   e)   a document roadmap to simplify access and understanding of the
        necessary specifications


1.3. 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 RFC2119 [RFC-2119].


2.   Use of IP Compression with IPSec


2.1. General Compression Processing

   The compression processing of IP datagrams has two phases, =
compressing
   of outbound IP datagrams and decompressing of inbound datagrams.

   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


R. Monsour, R. Pereira, A. Shacham                               [Page =
3]


Internet Draft       draft-ietf-ippcp-arch-00.txt           July 29, =
1997


   datagrams MUST support both compressed and non-compressed IP
   datagrams.

   A different compression algorithm may be negotiated in each direction
   of the communication channel, or only one direction may be =
compressed.


2.2. Alternative Compression Protocol Approaches

   Two recent Internet Drafts have been submitted by members of the
   working group, each offering a different approach to the application
   of lossless compression to IP datagram payloads. Note that in the
   description of both approaches, examples are provided in the more
   complex IP Security context. The simplification of the resulting
   packet formats for non-IPSec environments should be apparent from the
   examples.


2.2.1.T
       he IP Encapsulation Approach

   The first approach, what we=92ll call IP encapsulation, is described =
in
   [Shacham]. This approach involves the following steps (Note: this is =
a
   simplified view of the processing):

   a)   a complete IP datagram is treated as a payload and is compressed
   b)   a new IP header is prepended to the datagram to be compressed
   c)   subsequent IP security processing, if any, is applied to the new
        datagram

   The following is an example datagram structure which results when
   using this approach in conjunction with ESP. This approach can be =
used
   with AH as well as without any security processing of the datagram.



















R. Monsour, R. Pereira, A. Shacham                               [Page =
4]