home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / DRAFT_ARCHIVE < prev    next >
Text File  |  1997-07-21  |  11KB  |  296 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6. IP Payload Compression Protocol Working Group                 A. Shacham
  7. INTERNET-DRAFT                                             Cisco Systems
  8. Expires in six months                                          July 1997
  9.  
  10.                IP Payload Compression Protocol (IPComp)
  11.                   <draft-ietf-ippcp-protocol-00.txt>
  12.  
  13. Status of this Memo
  14.  
  15.    This document is an Internet-Draft.  Internet-Drafts are working
  16.    documents of the Internet Engineering Task Force (IETF), its
  17.    areas, and its working groups.  Note that other groups may also
  18.    distribute working documents as Internet-Drafts.
  19.  
  20.    Internet-Drafts are draft documents valid for a maximum of six
  21.    months and may be updated, replaced, or obsoleted by other
  22.    documents at any time.  It is inappropriate to use Internet-
  23.    Drafts as reference material or to cite them other than as
  24.    ``work in progress.''
  25.  
  26.    To learn the current status of any Internet-Draft, please check
  27.    the ``1id-abstracts.txt'' listing contained in the Internet-
  28.    Drafts Shadow Directories on ftp.is.co.za (Africa),
  29.    ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim),
  30.    ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
  31.  
  32.    Distribution of this memo is unlimited.
  33.  
  34. Abstract
  35.  
  36.    This memo describes a protocol intended to provide compression
  37.    services for IP datagrams in an Internet environment.
  38.  
  39. 1. Introduction
  40.  
  41.    IP compression is a mechanism to reduce the size of IP datagrams.
  42.    This protocol will increase the overall communication performance
  43.    between a pair of communicating hosts/gateways by compressing the
  44.    datagrams, provided the hosts/gateways have sufficient CPU capacity
  45.    and the communication is over slow or congested links.  IP
  46.    compression is especially useful when encryption is applied to IP
  47.    datagrams and therefore layer 2 (e.g., PPP) compression is not
  48.    effective.
  49.  
  50. 1.1. Specification of Requirements
  51.  
  52.    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
  53.    NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
  54.    in this document are to be interpreted as described in RFC 2119
  55.    [RFC-2119].
  56.  
  57. Shacham                                                         [Page 1]
  58.  
  59. INTERNET DRAFT                   IPComp                        July 1997
  60.  
  61. 2. Compression Policy Negotiations
  62.  
  63.    A policy of compression of IP datagram is negotiated as part of a
  64.    Security Association (SA) using the Internet Security Association and
  65.    Key Management Protocol (ISAKMP) [ISAKMP].
  66.  
  67.    When the negotiated SA includes IP Encapsulating Security Payload
  68.    (ESP), IP datagram compression MUST be negotiated.  IP datagram
  69.    compression MAY be negotiated even when encryption is not part of the
  70.    SA, when the hosts try to preserve communication bandwidth.
  71.  
  72.    In the Internet IP Security Domain of Interpretation (DOI) [SECDOI],
  73.    the following SA compression attribute is used in phase II of
  74.    an ISAKMP/Oakley negotiations:
  75.  
  76.       Class: Compression Format (algorithm).
  77.       Value: 12.
  78.       Type:  Basic (B).
  79.  
  80.    The Compression Format value of zero (0) is "no compression".
  81.    The Compression Format values 1-255 are identical to the PPP
  82.    compression types, where up-to-date values of the Type are specified
  83.    in the most recent "Assigned Numbers" RFC [RFC-1700].  Values 
  84.    256-61439 are reserved to IANA.  Values 61440-65535 are for private
  85.    use among mutually consenting parties.
  86.  
  87.    A different compression algorithm may be negotiated in each
  88.    direction, or only one direction may be compressed.  The default
  89.    value is "no compression".
  90.  
  91. 3. Compression Process
  92.  
  93.    The compression processing of IP datagrams has two phases,
  94.    compressing of outbound IP datagrams ("Compression") and
  95.    decompressing of inbound datagrams ("Decompression").  The
  96.    compression processing MUST be lossless, ensuring that the IP
  97.    datagram after being Compressed and Decompressed is identical to the
  98.    original IP datagram.
  99.  
  100.    The Compression of outbound IP datagrams MUST be done before any IP
  101.    security processing, such as encryption and authentication, and
  102.    before any fragmentation of the IP datagram.  Similarly, the
  103.    Decompression of inbound IP datagrams MUST be done after the
  104.    reassembly of the IP datagrams, and after the completion of all IP
  105.    security processing, such as authentication and decryption.
  106.    Processing of inbound IP datagrams MUST support both Compressed and
  107.    non-compressed IP datagrams.
  108.  
  109.    Each IP datagram is Compressed and Decompressed by itself without any
  110.    relation to other datagrams ("stateless compression"), as IP
  111.    datagrams may arrive out of order.  The Compression is applied to the
  112.    whole IP datagram, including the IP header and the upper layer
  113.    protocol (ULP) payload.  The size of a Compressed datagram is always
  114.    in whole octet units.
  115.  
  116. Shacham                                                         [Page 2]
  117.  
  118. INTERNET DRAFT                   IPComp                        July 1997
  119.  
  120.    If the size of a Compressed IP datagram, including the encapsulating
  121.    IP header as defined in section 4, is not smaller than the size of
  122.    the original IP datagram, the IP datagram MUST be sent in the
  123.    original non-compressed form.  This policy ensures saving the
  124.    Decompression processing cycles and avoiding incurring IP datagram
  125.    fragmentation when the expanded datagram is larger than MTU.
  126.  
  127.    Small IP datagrams are likely to expand as a result of Compression.
  128.    Therefore, a numeric threshold SHOULD be applied before Compression,
  129.    where IP datagrams of size smaller than the threshold are sent in
  130.    the original form without attempting Compression.  The numeric
  131.    threshold is implementation dependent.
  132.  
  133.    An IP datagram with payload, which has been previously compressed,
  134.    tends not to compress any further.  Such previously compressed
  135.    payload may be the result of external processes, such as compression
  136.    applied by an upper layer in the communication stack, or by an 
  137.    off-line compression utility.  An adaptive algorithm, SHOULD be
  138.    implemented in order to avoid the performance hit. The adaptive
  139.    algorithm is implementation dependent.
  140.  
  141. 4. Compressed IP Datagram Structure
  142.  
  143.    A compressed IP datagram is encapsulated by inserting an outer IP
  144.    header before the datagram's existing (inner) IP header, similar to
  145.    the method of IP Encapsulation within IP [RFC-2003]. Each compressed
  146.    IP datagram encapsulates a single IP datagram.
  147.  
  148. 4.1. IP version 4
  149.  
  150.    The following outer IP header version 4 [RFC-0791] fields are kept
  151.    from the original inner IP header:
  152.  
  153.       Version.
  154.       The Type of Service (TOS).
  155.       Identification, Flags, Fragment Offset.
  156.       The Time To Live (TTL).
  157.       Source Address.
  158.       Destination Address.
  159.  
  160.    The following outer IP header version 4 fields are set after a
  161.    successful compression:
  162.  
  163.       The Internet Header Length (IHL).
  164.  
  165.          The length of the outer IP header measured in 32-bit words
  166.          [RFC-0791].
  167.  
  168.       Total Length
  169.  
  170.          The length of the entire encapsulated IP datagram, including
  171.          the outer IP header and the compressed IP datagram.
  172.  
  173.  
  174.  
  175. Shacham                                                         [Page 3]
  176.  
  177. INTERNET DRAFT                   IPComp                        July 1997
  178.  
  179.       Protocol
  180.  
  181.          The Protocol field is set to 106, Compressed IP Datagram,
  182.          [RFC-1700].
  183.  
  184.       Header Checksum
  185.  
  186.          The Internet Header checksum [RFC-0791] of the outer IP header.
  187.  
  188.       Options
  189.  
  190.          No options present in the inner IP header are copied to the
  191.          outer IP header.
  192.  
  193. 4.2. IP version 6
  194.  
  195.    The following outer IP header version 6 [RFC-1833] fields are kept
  196.    from the original inner IP header:
  197.  
  198.       Version.
  199.       Priority.
  200.       Flow Label.
  201.       Hop Limit.
  202.       Source Address.
  203.       Destination Address.
  204.       IPv6 Extension Headers.
  205.  
  206.    The following outer IP header version 6 fields are set after a
  207.    successful compression:
  208.  
  209.       Payload Length
  210.  
  211.          The length of the compressed IP datagram.
  212.  
  213.       Next Header
  214.  
  215.          The Next Header field is set to 106, Compressed IP Datagram,
  216.          [RFC-1700].
  217.  
  218. 5. Security Considerations
  219.  
  220.    IP compression potentially reduces the security of the Internet,
  221.    similar to the effects of IP encapsulation [RFC-2003].  For example,
  222.    IP compression makes it difficult for border routers to filter
  223.    datagrams based on header fields.  In particular, the original value
  224.    of the Protocol field in the IP header, and any transport header
  225.    fields within the datagram, such as port numbers, are neither
  226.    located in their normal positions within the datagram nor presented
  227.    in their original values after compression.  Filtering border router
  228.    can filter the datagram only if it shares the security association
  229.    used for the compression.  To allow this sort of compression in
  230.    environments in which all packets need to be filtered (or at least
  231.    accounted for), a mechanism must be in place for the receiving node
  232.    to securely communicate the security association to the border
  233.  
  234. Shacham                                                         [Page 4]
  235.  
  236. INTERNET DRAFT                   IPComp                        July 1997
  237.  
  238.    router.  This might, more rarely, also apply to the security
  239.    association used for outgoing datagrams.
  240.  
  241. 6. References
  242.  
  243.    [RFC-0791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
  244.               September 1981.
  245.  
  246.    [RFC-1700] Reynolds, J., Postel, J., "Assigned Numbers", RFC 1700,
  247.               October 1994.
  248.  
  249.    [RFC-1883] Deering, S. , Hinden, R., "Internet Protocol, Version 6
  250.               (IPv6) Specification", RFC 1883, April 1996.
  251.  
  252.    [RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
  253.               October 1996.
  254.  
  255.    [RFC-2119] Bradner, S. , "Key words for use in RFCs to Indicate
  256.               Requirement Levels", RFC 2119, March 1997.
  257.  
  258.    [ISAKMP]   Maughan, D., Schertler, M., Schneider, M., and Turner, J.,
  259.               "Internet Security Association and Key Management
  260.               Protocol (ISAKMP)", Internet-Draft:
  261.               draft-ietf-ipsec-isakmp-07.txt, Work in Progress,
  262.               February 1997.
  263.  
  264.    [SECDOI]   Piper, D., "The Internet IP Security Domain of
  265.               Interpretation for ISAKMP", Internet-Draft:
  266.               draft-ietf-ipsec-ipsec-doi-02.txt, Work in Progress,
  267.               February 1997.
  268.  
  269. Author's Address
  270.  
  271.    Abraham Shacham
  272.    Cisco Systems
  273.    101 Cooper Street
  274.    Santa Cruz, California  95060
  275.    United States of America
  276.  
  277.    Phone: +1 408 457 5200
  278.    EMail: shacham@cisco.com
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293. Shacham                  Expires in six months                  [Page 5]
  294.  
  295.  
  296.