updated IPPCP architecture draft

[Roy Pereira <[e-mail]>]

I seems that the Archiecture draft that was submitted was cut-off short.
 Here is the full version of that draft;


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
([e-mail])
   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. The IP Encapsulation Approach

   The first approach, what we'll 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]


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


   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                             |
   ~                       Outer IP Header                       ~
   |                                                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
   |               Security Parameters Index (SPI)               | ^
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   |                      Sequence Number                        | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
----
   |                                                             | A ^ ^
   ~                       Inner IP Header                       ~ | | |
   |                                                             | | B C
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |
   |                                                             | | | |
   ~                    Payload Data (variable)                  ~ | | |
   |                                                             | | | v
   ~               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|---
   |               |     Padding (0-255 bytes)                   | | |
   +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
   |                               |  Pad Length   | Next Header | v v
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
------
   |                                                             |
   ~                Authentication Data (variable)               ~
   |                                                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   A = Authentication Coverage
   B = Confidentiality Coverage
   C = Compression Coverage

   Refer to [Shacham] for details on handling the Ipv4 and Ipv6 header
   contents; i.e., which fields are copied from the inner header to the
   outer header.


2.2.2. The IP Header Approach

   The second approach, which we'll call the header approach, is
   described in [Thomas]. In this approach, a compression header
   immediately precedes the compressed payload. The header consists of a
   compression parameters index (CPI); the CPI operates in a similar
   manner to an SPI for security parameters. In other words, it uniquely
   defines the parameters for compression processing on the receiving
end
   of the compressed datagram. The CPI is followed by compression
method-
   specific, optional, variable length field which includes all data
   needed for a receiver to decompress the incoming datagram.


R. Monsour, R. Pereira, A. Shacham                               [Page
5]


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



   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.


   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                             |
   ~                         IP Header                           ~
   |                                                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
   |               Security Parameters Index (SPI)               | ^
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
   |                      Sequence Number                        | |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |---
   |              Compression Parameters Index (CPI)             | | ^
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
   |                 Optional, Variable Length                   | | |
   |              Compression Method-Specific Data               | A B
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|---
   |                                                             | | | ^
   ~                    Payload Data (variable)                  ~ | | C
   |                                                             | | | v
   ~               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|---
   |               |     Padding (0-255 bytes)                   | | |
   +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
   |                               |  Pad Length   | Next Header | v v
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
   |                                                             |
   ~                 Authentication Data (variable)              ~
   |                                                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   A = Authentication Coverage
   B = Confidentiality Coverage
   C = Compression Coverage











R. Monsour, R. Pereira, A. Shacham                               [Page
6]


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


2.2.3. Comparison of the Two Approaches

   The relative advantages and disadvantages of the two approaches are
   provided in the table below.

                   +-----------------------------+--------------------+
                   | Advantages                  | Disadvantages      |
   +---------------+-----------------------------+--------------------|
   | Encapsulation | Simple, straightforward     | 20 byte IP header  |
   |               |                             | overhead           |
   |               |                             | Only host-to-host  |
   |               |                             | associations       |
   +---------------+-----------------------------+--------------------+
   | Header        | Minimal overhead (8 bytes)  | Some additional    |
   |               | More control over           | complexity         |
   |               | associations                |                    |
   +---------------+-----------------------------+--------------------+


2.3. Interaction of IP Payload Compression with AH & ESP

   As stated previously, in the IP layer, compression MUST be applied
   before any encryption is applied.  Thus, when used within IPSec with
   either ESP or
   AH, any compression protocol header must precede the security
   protocols headers. In the following examples, IPCOMP refers to the IP
   compression header.

      Example: IP, ESP, IPCOMP, TCP

   When tunneling IP packets, the compression protocol SHOULD
encapsulate
   the entire inner IP packet.

      Example: IP, ESP, IPCOMP, IP, UDP


3.   IP payload Compression without IPSec

   The use of compression without IPSec is possible as long as both
   parties have pre-arranged the use of compression between them. Such
   "pre-arrangement" can be performed either automatically through the
   use of a negotiation mechanism such as ISAKMP (see section 6 for more
   on this topic), or by some manual configuration of the two nodes. One
   method that has been suggested is the use of static "compression
   associations". In this method, a limited number of compression
   parameters indexes (CPIs) would be designated to represent a list of
   specific compression methods.





R. Monsour, R. Pereira, A. Shacham                               [Page
7]


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


4.   Anti-expansion of Payload Data

   If the size of a compressed IP datagram, including whatever overhead
   is included to define the compression protocol, is not smaller than
   the size of the original IP datagram, the IP datagram MUST be sent in
   the original non-compressed form.  This policy ensures saving the
   decompression processing cycles and avoiding incurring IP datagram
   fragmentation when the expanded datagram is larger than the 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, which has been previously compressed,
   tends not to compress any further.  Such 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 in
   order to avoid the performance hit. Such as adaptive algorithm is
   implementation dependent and independent of compression method.


5.   Stateless vs. Stateful compression

   Since IP is a connectionless protocol, it is important that each
   compressed packet be capable of being decompressed independently of
   any other packet; i.e., the successful decompression of a packet MUST
   NOT depend on the contents of any other packet(s), nor should it
   depend on order of receipt of any other packet(s).

   ISSUE: Does the working group believe that stateful IP compression is
   completely out of the question, or should the protocol allow for
   implementation of stateful compression (i.e., maintaining compression
   history across IP datagrams)? Such an implementation could be
   negotiated by consenting parties, much like many other protocol
   options.


6.   Negotiation Mechanisms for IP Compression

   This section describes the options available for negotiating the use
   and method of lossless compression for use in an IP payload
   compression protocol.







R. Monsour, R. Pereira, A. Shacham                               [Page
8]


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


6.1. Use of ISAKMP in IPSec Contexts

   The Internet Security Association Key Management Protocol (ISAKMP)
   defines procedures and packet formats to establish, negotiate, modify
   and delete Security Associations (SA). SAs contain all the
information
   required for execution of various network security services, such as
   the IP layer services (such as header authentication and payload
   encapsulation), transport or application layer services, or self-
   protection of negotiation traffic.

   For IP payload compression in the context of IP Security, ISAKMP
   provides the necessary mechanisms to enable compression and to choose
   which compression method shall be used between the two parties.

   This documents describes two approaches to using ISAKMP to negotiate
   the use of compression: (1) defining compression as a "protocol" (a
   peer to ESP and AH), and (2) defining compression as an attribute of
   the protocols negotiated using ISAKMP. Each of these is described
   below, along with their pros and cons. Regardless of which approach
is
   used, compression would be negotiated during an ISAKMP phase 2
   negotiation.


6.1.1. Compression as a "Protocol"

   In this method, compression would be 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.

   ISSUE: This method requires an extension of the IPSec DOI [DOI] to
   include compression in the list of available protocols. Currently,
the
   IPSec DOI defines the following protocols: PROTO_ISAKMP,
   PROTO_IPSEC_AH, and PROTO_IPSEC_ESP. Additionally, a list of
   transforms for the compression protocol would need to be added to the
   DOI (and/or handled by IANA registration - more on this later).

   +-----------------------------------+--------------------------------
+
   | PROS                              | CONS
|
   +-----------------------------------+--------------------------------
+
   | Better support for non-IPSec      | Simple changes to the IPSec
|
   | contexts                          | DOI spec
|
   +-----------------------------------+--------------------------------
+







R. Monsour, R. Pereira, A. Shacham                               [Page
9]


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


6.1.2. Compression as a Protocol Attribute

   In this method, compression is negotiated through the use of Data
   Attributes as described in the ISAKMP specification. Data Attributes
   are included in each Transform Payload. Such attributes can take two
   different forms, a basic attribute which has an attribute identifier
   and a value, and a variable-length attribute. Compression would be an
   attribute of a negotiated transform for one or more of the
   PROTO_ISAKMP, PROTO_IPSEC_AH, or PROTO_IPSEC_ESP protocols.

   Defining compression as a basic attribute could cause what we'll call
   "transform payload explosion" (not unlike the earlier transform
   explosion problem that IPSec suffered in earlier days). The reason
for
   this is that in order for an initiator to provide a variety of
   compression choices to the responder, each protocol would have to be
   "proposed" to the responder once for each value of compression
   attribute (which can only contain a single value for compression
   choice).

   An alternative to the preceding technique would be to define
   compression as a variable-length attribute where the attribute,
   provided once for each protocol for which compression would be
   offered, would contain a list of offered compression algorithms, with
   the first in the list being the most preferred by the initiator.

   ISSUE: Both of these methods require an extension of the IPSec DOI to
   include compression in the list of Security Association attributes.
   Examples of the currently defined attributes include: Replay
   Prevention and Encapsulation Mode (transport or tunnel mode).

   +----------------------------------------+---------------------------
+
   | PROS                                   | CONS
|
   +----------------------------------------+---------------------------
+
   | Achieves primary goal of working group | Less general solution
|
   | Simple changes to the IPSec DOI spec   |
|
   +----------------------------------------+---------------------------
+


6.2. Static Configuration for Non-IPSec Contexts

   It may be desirable to use IP compression in contexts other than
   IPSec/ISAKMP. Where this is the case, an alternate method for
   communicating which compression method is used will be necessary. One
   method that has been suggested is the use of static, "compression
   associations". In this method, a limited number of compression
   parameters indexes (CPIs) would be designated to represent a list of
   specific compression methods. Note that CPIs and Compression
   Associations are protocol dependent fields.



R. Monsour, R. Pereira, A. Shacham                              [Page
10]


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


7.   Implications with Ipv4 and Ipv6

   The two approaches to applying compression to IP datagrams face the
   same interaction issues with Ipv4 and IPV6 as other protocols (like
   IPSec). The ones that immediately come to mind involve alignment of
   headers, particularly in Ipv6. There may be additional, more serious
   implications for the working group to consider and resolve during the
   development of the protocol specification.


8.   Compression Method/Format Registration Mechanism

   The negotiation of which compression method will be used by the two
   communicating parties requires that there be a means for identifying
   which compression method to use. Protocols such as PPP, which use
   compression, have a list of identifiers for compression
sub-protocols.

   This list of identifiers is maintained by the IANA. The IP payload
   compression protocol will require a similar list of compression
method
   identifiers.

   ISSUE: It was suggested by Jon Postel, who runs the IANA, that this
   group investigate the possibility of using the same list of
   identifiers as PPP. There are two potential problems in using this
   list: First, the numbers do not define unique compression methods
   (e.g., two of them refer to LZS, but have different PPP-specific
   protocol handling). Secondly, the list is under the list of PPP
number
   assignments and may be nerve-racking to locate during the
   implementation of the resulting IP payload compression protocol. One
   approach to use these numbers would be to document which of the PPP
   numbers are valid for IP payload compression; in addition, each
   compression method would specify the appropriate PPP number that it
   would use.


9.   Document Roadmap

   This section provides an overall roadmap to the documents to be
   produced by the IP payload compression protocol working group.

   This document, while not specifically called for in the working group
   charter, has been produced to provide a general architectural
   framework for the development of the detailed protocol
specifications,
   from which implementations will be built.








R. Monsour, R. Pereira, A. Shacham                              [Page
11]


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


   The working group charter calls for the following documents to be
   produced:

   a)   IP payload compression protocol specification
   b)   Compression transform specifications (one or more)
   c)   ISAKMP negotiation mechanism specification

   As of the date of this writing, two drafts have been generated to
   address the protocol specification. The basic architectural
approaches
   of these drafts is discussed earlier in this document.

   The compression transform specifications shall specify how a specific
   compression algorithm can be used with the IP payload compression
   protocol.

   The ISAKMP negotiation mechanism specification shall specify the
   details of using ISAKMP to negotiate the use of compression. There
may
   be two such drafts, one to address use of ISAKMP in the IPSec context
   and one for non-IPSec contexts. In the case where ISAKMP is used in
   contexts other than IPSec, an additional document, a compression
   Domain of Interpretation will be required.


10.  Security Considerations

   This memo discusses the use of lossless compression technology in a
   security protocol, specifically IPSec. The proposed use of
compression
   within this protocol is not believed to have an effect on the
   underlying security functionality provide by the 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.

   The use of compression does change the length of ESP payloads, in a
   manner that depends on the data prior to encryption.  Thus, the use
of
   compression may have an effect on the ability of an eavesdropper to
   glean information by analyzing the length of transmitted packets.

   For the encapsulation approach, IP compression potentially reduces
the
   security of the Internet, similar to the effects of IP encapsulation
   [RFC-2003].  For example, IP compression 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, and any
   transport 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.  Filtering
   border router can filter the datagram only if it shares the security
   association used for the compression.  To allow this sort of


R. Monsour, R. Pereira, A. Shacham                              [Page
12]


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


   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 security association to
the
   border.


11.  References

   [AH]  Kent, S., Atkinson, R., "IP Authentication Header", draft-ietf-
   ipsec-auth-header-01.txt, Work in Progress, July 1997.

   [DOI] 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.

   [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security Payload,"
   draft-ietf-ipsec-esp-v2-00.txt, Work in Progress, July 1997.

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

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

   [Shacham] Shacham, A., "IP Payload Compression Protocol (IPComp)",
   draft-ietf-ippcp-protocol-00.txt, Work in Progress, July 1997.

   [Thayer] Thayer, R., "Compression Payload for Use with IP Security",
   draft-thayer-seccomp-01.txt, Work in Progress, March, 1997.

   [Thomas] Thomas, M., "The Compressed Payload Header", draft-thomas-
   ippcp-compression-00.txt, Work in Progress, July 1997.





R. Monsour, R. Pereira, A. Shacham                              [Page
13]


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


12.  Authors' Addresses

   Robert Monsour
   Hi/fn Inc.
   5973 Avenida Encinas
   Carlsbad, CA 92008
   Email: [e-mail]

   Roy Pereira
   TimeStep Corporation
   362 Terry Fox Drive
   Kanata, Ontario K2K 2P5
   Email: [e-mail]

   Abraham Shacham
   Cisco Systems
   101 Cooper Street
   Santa Cruz, CA 95060
   Email: [e-mail]


13.  Working Group

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

     Naganand Dorswamy
     Bay Networks
     [e-mail]

   The IPPCP mailing list may be subscribed to by sending an email to
   "[e-mail]" and including "SUBSCRIBE ippcp" in the text of the
   message.


















R. Monsour, R. Pereira, A. Shacham                              [Page
14]