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-protocol-01.txt < prev    next >
Text File  |  1997-10-01  |  18KB  |  475 lines
  1.  
  2. INTERNET-DRAFT                                         A. Shacham, Cisco
  3. IP Payload Compression Protocol Working Group          R. Monsour, Hi/fn
  4. Expires in six months                               R. Pereira, TimeStep
  5.                                            M. Thomas, AltaVista Internet
  6.                                                             October 1997
  7.  
  8.                IP Payload Compression Protocol (IPComp)
  9.                   <draft-ietf-ippcp-protocol-01.txt>
  10.  
  11. Status of this Memo
  12.  
  13.    This document is an Internet-Draft.  Internet-Drafts are working
  14.    documents of the Internet Engineering Task Force (IETF), its
  15.    areas, and its working groups.  Note that other groups may also
  16.    distribute working documents as Internet-Drafts.
  17.  
  18.    Internet-Drafts are draft documents valid for a maximum of six
  19.    months and may be updated, replaced, or obsoleted by other
  20.    documents at any time.  It is inappropriate to use Internet-
  21.    Drafts as reference material or to cite them other than as
  22.    ``work in progress.''
  23.  
  24.    To view the entire list of current Internet-Drafts, please check
  25.    the "1id-abstracts.txt" listing contained in the Internet-Drafts
  26.    Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
  27.    (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
  28.    Coast), or ftp.isi.edu (US West Coast).
  29.  
  30.    Distribution of this memo is unlimited.
  31.  
  32. Abstract
  33.  
  34.    This document describes a protocol intended to provide lossless
  35.    compression for Internet Protocol datagrams in an Internet
  36.    environment.
  37.  
  38. 1. Introduction
  39.  
  40.    IP payload compression is a protocol to reduce the size of IP
  41.    datagrams.  This protocol will increase the overall communication
  42.    performance between a pair of communicating hosts/gateways ("nodes")
  43.    by compressing the datagrams, provided the nodes have sufficient
  44.    computation power, through either CPU capacity or a compression
  45.    coprocessor, and the communication is over slow or congested links.
  46.  
  47.    IP payload compression is especially useful when encryption is
  48.    applied to IP datagrams.  Encrypting the IP datagram causes the data
  49.    to be random in nature, rendering compression at lower protocol
  50.    layers (e.g., PPP Compression Control Protocol [RFC-1962])
  51.    ineffective.  If both compression and encryption are required,
  52.    compression MUST be applied before encryption.
  53.  
  54.    This document defines the IP payload compression protocol (IPComp),
  55.    the IPComp packet structure, the IPComp Association (IPCA), and
  56.    several methods to negotiate the IPCA.
  57.  
  58. Shacham, Monsour, Pereira, Thomas                               [Page 1]
  59.  
  60. INTERNET DRAFT                   IPComp                     October 1997
  61.  
  62.    Other documents shall specify how a specific compression algorithm
  63.    can be used with the IP payload compression protocol.
  64.  
  65. 1.1. Specification of Requirements
  66.  
  67.    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
  68.    NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
  69.    in this document are to be interpreted as described in RFC 2119
  70.    [RFC-2119].
  71.  
  72. 2. Compression Process
  73.  
  74.    The compression processing of IP datagrams has two phases:
  75.    compressing of outbound IP datagrams ("compression") and
  76.    decompressing of inbound datagrams ("decompression").  The
  77.    compression processing MUST be lossless, ensuring that the IP
  78.    datagram, after being compressed and decompressed, is identical to
  79.    the original IP datagram.
  80.  
  81.    Each IP datagram is compressed and decompressed by itself without any
  82.    relation to other datagrams ("stateless compression"), as IP
  83.    datagrams may arrive out of order or not arrive at all.  Each
  84.    compressed IP datagram encapsulates a single IP datagram.
  85.  
  86.    Processing of inbound IP datagrams MUST support both compressed and
  87.    non-compressed IP datagrams, in order to meet the non-expansion
  88.    policy requirements, as defined in section 2.2.
  89.  
  90.    The compression of outbound IP datagrams MUST be done before any IP
  91.    security processing, such as encryption and authentication, and
  92.    before any fragmentation of the IP datagram.  In addition, in IP
  93.    version 6 [RFC-1883], the compression of outbound IP datagrams MUST
  94.    be done before the addition of either a Hop-by-Hop Options header or
  95.    a Routing Header, since both carry information that must be examined
  96.    and processed by possibly every node along a packet's delivery path,
  97.    and therefore MUST be sent in the original form.
  98.  
  99.    Similarly, the decompression of inbound IP datagrams MUST be done
  100.    after the reassembly of the IP datagrams, and after the completion
  101.    of all IP security processing, such as authentication and
  102.    decryption.
  103.  
  104. 2.1. Compressed Payload
  105.  
  106.    The compression is applied to a single array of octets, which are
  107.    contiguous in the IP datagram.  This array of octets always ends at
  108.    the last octet of the IP packet payload.  Note: a contiguous array of
  109.    octets in the IP datagram may be not contiguous in physical memory.
  110.  
  111.    In IP version 4 [RFC-0791], the compression is applied to the upper
  112.    layer protocol (ULP) payload of the IP datagram.  No portion of the
  113.    IP header or the IP header options is compressed.
  114.  
  115.  
  116.  
  117. Shacham, Monsour, Pereira, Thomas                               [Page 2]
  118.  
  119. INTERNET DRAFT                   IPComp                     October 1997
  120.  
  121.    In the IPv6 context, IPComp is viewed as an end-to-end payload, and
  122.    therefore MUST apply after hop-by-hop, routing, and fragmentation
  123.    extension headers.  The compression is applied starting at the first
  124.    IP Header Option field which does not carry information that must be
  125.    examined and processed by nodes along a packet's delivery path, if
  126.    such IP Header Option field exists, and continues to the ULP payload
  127.    of the IP datagram.
  128.  
  129.    The size of a compressed payload MUST be in whole octet units.
  130.  
  131.    As defined in section 3, an IPComp header is inserted immediately
  132.    preceding the compressed payload.  The original IP header is modified
  133.    to indicate the usage of the IPComp protocol and the reduced size of
  134.    the IP datagram.  The original content of the Next Header field is
  135.    stored in the IPComp header.
  136.  
  137.    The decompression is applied to a single contiguous array of octets
  138.    in the IP datagram.  The start of the array of octets immediately
  139.    follows the IPComp header and ends at the last octet of the IP
  140.    payload.  If the decompression process is successfully completed, the
  141.    IP header is modified to indicate the size of the decompressed IP
  142.    datagram, and the original next header as stored in the IPComp
  143.    header.  The IPComp header is removed from the IP datagram and the
  144.    decompressed payload immediately follows the IP header.
  145.  
  146. 2.2. Non-Expansion Policy
  147.  
  148.    If the size of a compressed IP datagram, including the IP header,
  149.    the IPComp header as defined in section 3, and the compressed
  150.    payload, is not smaller than the size of the original IP datagram,
  151.    the IP datagram MUST be sent in the original non-compressed form.
  152.    To clarify:  If an IP datagram is sent non-compressed, no IPComp
  153.    header is added to the datagram.  This policy ensures saving the
  154.    decompression processing cycles and avoiding incurring IP datagram
  155.    fragmentation when the expanded datagram is larger than MTU.
  156.  
  157.    Small IP datagrams are likely to expand as a result of compression.
  158.    Therefore, a numeric threshold SHOULD be applied before compression,
  159.    where IP datagrams of size smaller than the threshold are sent in
  160.    the original form without attempting compression.  The numeric
  161.    threshold is implementation dependent.
  162.  
  163.    An IP datagram with payload that has been previously compressed
  164.    tends not to compress any further.  The previously compressed payload
  165.    may be the result of external processes, such as compression applied
  166.    by an upper layer in the communication stack, or by an off-line
  167.    compression utility.  An adaptive algorithm SHOULD be implemented to
  168.    avoid the performance hit.  For example, if the compression of i
  169.    consecutive IP datagrams of an IPCA fails, the next k IP datagrams
  170.    are sent without attempting compression.  If the next j datagrams
  171.    are also failing to compress, the next k+n datagrams are sent without
  172.    attempting compression.  Once a datagram is compressed successfully,
  173.    the normal process of IPComp restarts.  The adaptive algorithm
  174.    including all the related thresholds is implementation dependent.
  175.  
  176. Shacham, Monsour, Pereira, Thomas                               [Page 3]
  177.  
  178. INTERNET DRAFT                   IPComp                     October 1997
  179.  
  180.    During the processing of the payload, the compression algorithm
  181.    MAY periodically apply a test to determine the compressibility of
  182.    the processed data, similar to the requirements of [V42BIS].  The
  183.    nature of the test is implementation dependent.  Once the
  184.    compression algorithm detects that the data is non-compressible,
  185.    the algorithm SHOULD stop processing the data, and the payload is
  186.    sent in the original non-compressed form.
  187.  
  188. 3. Compressed IP Datagram Header Structure
  189.  
  190.    A compressed IP datagram is encapsulated by modifying the IP header
  191.    and inserting an IPComp header immediately preceding the compressed
  192.    payload.  This section defines the IP header modifications both in
  193.    IPv4 and IPv6, and the structure of the IPComp header.
  194.  
  195. 3.1. IPv4 Header Modifications
  196.  
  197.    The following IPv4 header fields are set:
  198.  
  199.       Total Length
  200.  
  201.          The length of the entire encapsulated IP datagram, including
  202.          the IP header, the IPComp header and the compressed payload.
  203.  
  204.       Protocol
  205.  
  206.          The Protocol field is set to 108, IPComp Datagram, [RFC-1700].
  207.  
  208.    All other IPv4 header fields are kept unchanged, including any header
  209.    options.
  210.  
  211. 3.2. IPv6 Header Modifications
  212.  
  213.    The following IPv6 header fields are set:
  214.  
  215.       Payload Length
  216.  
  217.          The length of the compressed IP payload.
  218.  
  219.       Next Header
  220.  
  221.          The Next Header field is set to 108, IPComp Datagram,
  222.          [RFC-1700].
  223.  
  224.    All other IPv6 header fields are kept unchanged, including any
  225.    non-compressed header options.
  226.  
  227.    The IPComp header is placed in an IPv6 packet using the same rules as
  228.    the IPv6 Fragment Header.  However if an IPv6 packet contains both an
  229.    IPv6 Fragment Header and an IPComp header, the IPv6 Fragment Header
  230.    MUST preceed the IPComp header in the packet.
  231.  
  232.  
  233.  
  234.  
  235. Shacham, Monsour, Pereira, Thomas                               [Page 4]
  236.  
  237. INTERNET DRAFT                   IPComp                     October 1997
  238.  
  239. 3.3.  IPComp Header Structure
  240.  
  241.    The four octet header has the following structure:
  242.  
  243.    0                   1                   2                   3
  244.    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
  245.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  246.    |  Next Header  |     Flags     | Compression Parameter Index |
  247.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  248.  
  249.    Next Header
  250.  
  251.         8-bit selector.  Stores the IPv4 Protocol field or the IPv6
  252.         Next Header field of the original IP header.
  253.  
  254.    Flags
  255.  
  256.         8-bit field.  Reserved for future use.  Must be set to zero.
  257.  
  258.    Compression Parameter Index (CPI)
  259.  
  260.         16-bit index.  The CPI is stored in network order.  The values
  261.         0-63 are defined by IANA and are used for manual setup, which
  262.         requires no additional information.  The values 64-61439 are
  263.         negotiated between the two nodes in definition of an IPComp
  264.         Association, as defined in section 4.  The values 61440-65535
  265.         are for private use among mutually consenting parties.
  266.  
  267. 4. IPComp Association (IPCA) Negotiation
  268.  
  269.    To utilize the IPComp protocol, two nodes MUST first establish an
  270.    IPComp Association (IPCA) between them.  The IPCA includes all
  271.    required information for the operation of IPComp, including the
  272.    Compression Parameter Index (CPI), the mode of operation, the
  273.    compression algorithm to be used, and any required parameter for the
  274.    selected compression algorithm.  The IPComp mode of operation is
  275.    either a node-to-node policy where IPComp is applied to every IP
  276.    packet between the nodes, or an ULP session based policy where only
  277.    selected ULP sessions between the nodes are using IPComp.  For each
  278.    IPCA, a different compression algorithm may be negotiated in each
  279.    direction, or only one direction may be compressed.  The default is
  280.    "no IPComp compression".
  281.  
  282.    The IPCA is established by dynamic negotiations or by static
  283.    configuration.  The dynamic negotiations SHOULD use the Internet
  284.    Security Association and Key Management Protocol [ISAKMP], where
  285.    IPSec is present.  The dynamic negotiations MAY be implemented
  286.    through a different protocol.
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294. Shacham, Monsour, Pereira, Thomas                               [Page 5]
  295.  
  296. INTERNET DRAFT                   IPComp                     October 1997
  297.  
  298. 4.1. Use of ISAKMP
  299.  
  300.    For IPComp in the context of IP Security, ISAKMP provides the
  301.    necessary mechanisms to establish IPCA.  IPComp Association is
  302.    negotiated by the initiator using a Proposal Payload, which would
  303.    include one or more Transform Payloads.  The Proposal Payload would
  304.    specify a compression protocol in the protocol id field and each
  305.    Transform Payload would contain the specific compression method(s)
  306.    being offered to the responder.
  307.  
  308.    In the Internet IP Security Domain of Interpretation (DOI) [SECDOI],
  309.    IPComp is negotiated as the Protocol ID PROTO_IPCOMP.  The
  310.    compression algorithm is negotiated as one of the defined IPCOMP
  311.    Transform Identifiers.
  312.  
  313. 4.2. Use of Non-ISAKMP Protocol
  314.  
  315.    The dynamic negotiations MAY be implemented through a protocol other
  316.    than ISAKMP.  Such protocol is beyond the scope of this document.
  317.  
  318. 4.3. Static Configuration
  319.  
  320.    Nodes may establish IPComp Associations using static configuration.
  321.    For this method, a limited number of Compression Parameters Indexes
  322.    (CPIs) is designated to represent a list of specific compression
  323.    methods.
  324.  
  325. 5. Security Considerations
  326.  
  327.    IP payload compression potentially reduces the security of the
  328.    Internet, similar to the effects of IP encapsulation [RFC-2003].  For
  329.    example, IPComp makes it difficult for border routers to filter
  330.    datagrams based on header fields.  In particular, the original value
  331.    of the Protocol field in the IP header is not located in its normal
  332.    positions within the datagram, and any transport header fields within
  333.    the datagram, such as port numbers, are neither located in their
  334.    normal positions within the datagram nor presented in their original
  335.    values after compression.  A filtering border router can filter the
  336.    datagram only if it shares the IPComp Association used for the
  337.    compression.  To allow this sort of compression in environments in
  338.    which all packets need to be filtered (or at least accounted for), a
  339.    mechanism must be in place for the receiving node to securely
  340.    communicate the IPComp Association to the border router.  This might,
  341.    more rarely, also apply to the IPComp Association used for outgoing
  342.    datagrams.
  343.  
  344.    When IPComp is used in the context of IPSec, it is not believed to
  345.    have an effect on the underlying security functionality provide by
  346.    the IPSec protocol; i.e., the use of compression is not known to
  347.    degrade or alter the nature of the underlying security architecture
  348.    or the encryption technologies used to implement it.
  349.  
  350.  
  351.  
  352.  
  353. Shacham, Monsour, Pereira, Thomas                               [Page 6]
  354.  
  355. INTERNET DRAFT                   IPComp                     October 1997
  356.  
  357. 6. References
  358.  
  359.    [RFC-0791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
  360.               September 1981.
  361.  
  362.    [RFC-1700] Reynolds, J., Postel, J., "Assigned Numbers", RFC 1700,
  363.               October 1994.
  364.  
  365.    [RFC-1883] Deering, S., Hinden, R., "Internet Protocol, Version 6
  366.               (IPv6) Specification", RFC 1883, April 1996.
  367.  
  368.    [RFC-1962] Rand, D., "The PPP Compression Control Protocol (CCP)",
  369.               RFC 1962, June 1996.
  370.  
  371.    [RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
  372.               October 1996.
  373.  
  374.    [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
  375.               Requirement Levels", RFC 2119, March 1997.
  376.  
  377.    [ISAKMP]   Maughan, D., Schertler, M., Schneider, M., and Turner, J.,
  378.               "Internet Security Association and Key Management
  379.               Protocol (ISAKMP)", Internet-Draft:
  380.               draft-ietf-ipsec-isakmp-08.txt, Work in Progress,
  381.               July 1997.
  382.  
  383.    [SECDOI]   Piper, D., "The Internet IP Security Domain of
  384.               Interpretation for ISAKMP", Internet-Draft:
  385.               draft-ietf-ipsec-ipsec-doi-02.txt, Work in Progress,
  386.               February 1997.
  387.  
  388.    [V42BIS]   CCITT, "Data Compression Procedures for Data Circuit
  389.               Terminating Equipment (DCE) Using Error Correction
  390.               Procedures", Recommendation V.42 bis, January 1990.
  391.  
  392. Authors' Information
  393.  
  394.    Abraham Shacham
  395.    Cisco Systems
  396.    101 Cooper Street
  397.    Santa Cruz, California 95060
  398.    United States of America
  399.    Email: shacham@cisco.com
  400.  
  401.    Robert Monsour
  402.    Hi/fn Inc.
  403.    2105 Hamilton Avenue, Suite 230
  404.    San Jose, California 95125
  405.    United States of America
  406.    Email: rmonsour@hifn.com
  407.  
  408.  
  409.  
  410.  
  411.  
  412. Shacham, Monsour, Pereira, Thomas                               [Page 7]
  413.  
  414. INTERNET DRAFT                   IPComp                     October 1997
  415.  
  416.    Roy Pereira
  417.    TimeStep Corporation
  418.    362 Terry Fox Drive
  419.    Kanata, Ontario K2K 2P5
  420.    Canada
  421.    Email: rpereira@timestep.com
  422.  
  423.    Matt Thomas
  424.    AltaVista Internet Software
  425.    30 Porter Road
  426.    Littleton, Massachusetts 01460
  427.    United States of America
  428.    Email: matt.thomas@altavista-software.com
  429.  
  430. Working Group
  431.  
  432.    The IP Payload Compression Protocol (IPPCP) working group can be
  433.    contacted through its chair:
  434.  
  435.    Naganand Dorswamy
  436.    Bay Networks
  437.    Email: naganand@baynetworks.com
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471. Shacham, Monsour, Pereira, Thomas    Expires in six months      [Page 8]
  472.  
  473.  
  474.  
  475.