home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ippcp-arch-00.txt < prev    next >
Text File  |  1997-08-05  |  9KB  |  249 lines
  1.  
  2. Internet Draft                                 R. Monsour, Hi/fn, Inc.
  3. Expires in six months                 R. Pereira, TimeStep Corporation
  4.                                              A. Shacham, Cisco Systems
  5.                                                          July 30, 1997
  6.  
  7.  
  8.  
  9.               IP Payload Compression Protocol Architecture
  10.                      <draft-ietf-ippcp-arch-00.txt>
  11.  
  12.  
  13.  
  14. Status of this Memo
  15.  
  16.    This document is an Internet-Draft.  Internet Drafts are working
  17.    documents of the Internet Engineering Task Force (IETF), its areas,
  18.    and its working Groups. Note that other groups may also distribute
  19.    working documents as Internet Drafts.
  20.  
  21.    Internet-Drafts draft documents are valid for a maximum of six months
  22.    and may be updated, replaced, or obsolete by other documents at any
  23.    time. It is inappropriate to use Internet-Drafts as reference =
  24. material
  25.    or to cite them other than as "work in progress."
  26.  
  27.    To learn the current status of any Internet-Draft, please check the
  28.    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  29.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  30.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  31.    ftp.isi.edu (US West Coast).
  32.  
  33.    Distribution of this memo is unlimited.
  34.  
  35. Abstract
  36.  
  37.    This memo describes an architecture for applying lossless compression
  38.    to Internet Protocol datagrams. It defines several of the key
  39.    architectural elements of a compression protocol and describes
  40.    alternatives for each element.
  41.  
  42. Acknowledgments
  43.  
  44.    The authors gratefully acknowledge the many sources of input who made
  45.    this draft possible, including Rodney Thayer, Bob Moskowitz, Naganand
  46.    Doraswamy, Thomas Narten and all those that participated in the early
  47.    discussions and debates of these concepts. It is hoped that the
  48.    continued focused effort of those involved in the IPCCP Working Group
  49.    will result in the rapid development of a useful IP compression
  50.    protocol.
  51.  
  52.  
  53.  
  54.  
  55.  
  56. R. Monsour, R. Pereira, A. Shacham                               [Page =
  57. 1]
  58.  
  59.  
  60. Internet Draft       draft-ietf-ippcp-arch-00.txt           July 29, =
  61. 1997
  62.  
  63.  
  64. Table of Contents
  65.  
  66.    1. Introduction...................................................2
  67.       1.1. Background................................................2
  68.       1.2. IP Payload Compression Overview...........................3
  69.       1.3. Specification of Requirements.............................3
  70.    2. Use of IP Compression with IPSec...............................3
  71.       2.1. General Compression Processing............................3
  72.       2.2. Alternative Compression Protocol Approaches...............4
  73.          2.2.1. The IP Encapsulation Approach........................4
  74.          2.2.2. The IP Header Approach...............................5
  75.          2.2.3. Comparison of the Two Approaches.....................7
  76.       2.3. Interaction of IP Payload Compression with AH & ESP.......7
  77.    3. IP payload Compression without IPSec...........................7
  78.    4. Anti-expansion of Payload Data.................................8
  79.    5. Stateless vs. Stateful compression.............................8
  80.    6. Negotiation Mechanisms for IP Compression......................8
  81.       6.1. Use of ISAKMP in IPSec Contexts...........................9
  82.          6.1.1. Compression as a "Protocol"..........................9
  83.          6.1.2. Compression as a Protocol Attribute.................10
  84.       6.2. Static Configuration for Non-IPSec Contexts..............10
  85.    7. Implications with Ipv4 and Ipv6...............................11
  86.    8. Compression Method/Format Registration Mechanism..............11
  87.    9. Document Roadmap..............................................11
  88.    10. Security Considerations......................................12
  89.    11. References...................................................13
  90.    12. Authors' Addresses...........................................14
  91.    13. Working Group................................................14
  92.  
  93.  
  94.  
  95. 1.   Introduction
  96.  
  97.    This document is a submission to the IETF IP Payload Compression
  98.    Protocol (IPCCP) Working Group. Comments are solicited and should be
  99.    addressed to the working group mailing list =
  100. (ippcp@external.cisco.com)
  101.    or to the editor.
  102.  
  103.  
  104. 1.1. Background
  105.  
  106.    The motivation for the development of the IP Payload Compression
  107.    Protocol was initially driven by the use of the IP Security protocol
  108.    and the negative   effect that IP encryption has on data link layer
  109.    compression techniques. Encrypted data is random in nature and not
  110.    compressible.  When an IP datagram is encrypted, compression methods
  111.    used at lower protocol layers, e.g., the PPP Compression Control
  112.    Protocol [RFC-1962], are rendered ineffective.  If both compression
  113.    and encryption are desired, compression must be performed first. Such
  114.  
  115.  
  116. R. Monsour, R. Pereira, A. Shacham                               [Page =
  117. 2]
  118.  
  119.  
  120. Internet Draft       draft-ietf-ippcp-arch-00.txt           July 29, =
  121. 1997
  122.  
  123.  
  124.    motivation drove the creation of a new working group, the IP Payload
  125.    Compression Protocol working group, and the development of this
  126.    document.
  127.  
  128.  
  129. 1.2. IP Payload Compression Overview
  130.  
  131.    The IP payload compression architecture is designed to provide
  132.    compression services for the IP Protocol. Two fundamental =
  133. requirements
  134.    of such a compression protocol are: (1) that it supports the use of
  135.    any lossless compression method, and (2) the two communicating =
  136. parties
  137.    have a mechanism to negotiate the use of specific compression method
  138.    and any related parameters.
  139.  
  140.    This document describes the architectural alternatives available for
  141.    supporting lossless compression services for IP datagrams. The
  142.    following topics are discussed:
  143.  
  144.    a)   alternative approaches for integrating compression with IP
  145.         Security
  146.    b)   features of an IP compression protocol
  147.    c)   negotiation and use of lossless compression techniques, both in
  148.         the presence and absence of the IP Security protocol
  149.    d)   requirements for a registration mechanism used for identifying
  150.         compression methods for use with the protocol
  151.    e)   a document roadmap to simplify access and understanding of the
  152.         necessary specifications
  153.  
  154.  
  155. 1.3. Specification of Requirements
  156.  
  157.    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  158.    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  159.    document are to be interpreted as described in RFC2119 [RFC-2119].
  160.  
  161.  
  162. 2.   Use of IP Compression with IPSec
  163.  
  164.  
  165. 2.1. General Compression Processing
  166.  
  167.    The compression processing of IP datagrams has two phases, =
  168. compressing
  169.    of outbound IP datagrams and decompressing of inbound datagrams.
  170.  
  171.    The compression of outbound IP datagrams MUST be done before any IP
  172.    security processing, such as encryption and authentication, and =
  173. before
  174.    any fragmentation of the IP datagram.  Similarly, the decompression =
  175. of
  176.    inbound IP datagrams MUST be done after the reassembly of the IP
  177.    datagrams, and after the completion of all IP security processing,
  178.    such as authentication and decryption. Processing of inbound IP
  179.  
  180.  
  181. R. Monsour, R. Pereira, A. Shacham                               [Page =
  182. 3]
  183.  
  184.  
  185. Internet Draft       draft-ietf-ippcp-arch-00.txt           July 29, =
  186. 1997
  187.  
  188.  
  189.    datagrams MUST support both compressed and non-compressed IP
  190.    datagrams.
  191.  
  192.    A different compression algorithm may be negotiated in each direction
  193.    of the communication channel, or only one direction may be =
  194. compressed.
  195.  
  196.  
  197. 2.2. Alternative Compression Protocol Approaches
  198.  
  199.    Two recent Internet Drafts have been submitted by members of the
  200.    working group, each offering a different approach to the application
  201.    of lossless compression to IP datagram payloads. Note that in the
  202.    description of both approaches, examples are provided in the more
  203.    complex IP Security context. The simplification of the resulting
  204.    packet formats for non-IPSec environments should be apparent from the
  205.    examples.
  206.  
  207.  
  208. 2.2.1.T
  209.        he IP Encapsulation Approach
  210.  
  211.    The first approach, what we=92ll call IP encapsulation, is described =
  212. in
  213.    [Shacham]. This approach involves the following steps (Note: this is =
  214. a
  215.    simplified view of the processing):
  216.  
  217.    a)   a complete IP datagram is treated as a payload and is compressed
  218.    b)   a new IP header is prepended to the datagram to be compressed
  219.    c)   subsequent IP security processing, if any, is applied to the new
  220.         datagram
  221.  
  222.    The following is an example datagram structure which results when
  223.    using this approach in conjunction with ESP. This approach can be =
  224. used
  225.    with AH as well as without any security processing of the datagram.
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245. R. Monsour, R. Pereira, A. Shacham                               [Page =
  246. 4]
  247.  
  248.  
  249.