rfc3173.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 732 行 · 第 1/2 页

   Exchange protocol [IKE], where IPsec is present.  The dynamic
   negotiations MAY be implemented through a different protocol.

4.1. Use of IKE

   For IPComp in the context of IP Security, IKE provides the necessary
   mechanisms and guidelines for establishing IPCA.  Using IKE, IPComp
   can be negotiated as stand-alone or in conjunction with other IPsec
   protocols.

   An IPComp Association is negotiated by the initiator using a Proposal
   Payload, which includes one or more Transform Payloads.  The Proposal
   Payload specifies the IP Payload Compression Protocol in the protocol
   ID field and each Transform Payload contains the specific compression
   algorithm(s) being offered to the responder.

   The CPI is sent in the SPI field of the proposal, with the SPI size
   field set to match.  The CPI SHOULD be sent as a 16-bit number, with
   the SPI size field set to 2.  Alternatively, the CPI MAY be sent as a
   32-bit value, with the SPI size field set to 4.  In this case, the
   16-bit CPI number MUST be placed in the two least significant octets
   of the SPI field, while the two most significant octets MUST be set
   to zero, and MUST be ignored by the receiving node.  The receiving
   node MUST be able to process both forms of the CPI proposal.



Shacham, et al.             Standards Track                     [Page 7]

RFC 3173            IP Payload Compression Protocol       September 2001


   In the Internet IP Security Domain of Interpretation (DOI), IPComp is
   negotiated as the Protocol ID PROTO_IPCOMP.  The compression
   algorithm is negotiated as one of the defined IPCOMP Transform
   Identifiers.

   The following attributes are applicable to IPComp proposals:

      Encapsulation Mode

         To propose a non-default Encapsulation Mode (such as Tunnel
         Mode), an IPComp proposal MUST include an Encapsulation Mode
         attribute.  If the Encapsulation Mode is unspecified, the
         default value of Transport Mode is assumed.

      Lifetime

         An IPComp proposal uses the Life Duration and Life Type
         attributes to suggest life duration to the IPCA.

   When IPComp is negotiated as part of a Protection Suite, all the
   logically related offers must be consistent.  However, an IPComp
   proposal SHOULD NOT include attributes that are not applicable to
   IPComp.  An IPComp proposal MUST NOT be rejected because it does not
   include attributes of other protocols in the Protection Suite that
   are not relevant to IPComp.  When an IPComp proposal includes such
   attributes, those attributes MUST be ignored when setting the IPCA,
   and therefore ignored in the operation of IPComp.

   Implementation note:

      A node can avoid the computation necessary for determining the
      compression algorithm from the CPI if it is using one of the
      well-known algorithms; this can save time in the decompression
      process.  A node can do this by negotiating a CPI equal in value
      to the pre-defined Transform identifier of that compression
      algorithm.  Specifically: A node MAY offer a CPI in the pre-
      defined range by sending a Proposal Payload that MUST contain a
      single Transform Payload, which is identical to the CPI.  When
      proposing two or more Transform Payloads, a node MAY offer CPIs in
      the pre-defined range by using multiple IPComp proposals -- each
      MUST include a single Transform Payload.  To clarify: If a
      Proposal Payload contains two or more Transform Payloads, the CPI
      MUST be in the negotiated range.  A receiving node MUST be able to
      process each of these proposal forms.







Shacham, et al.             Standards Track                     [Page 8]

RFC 3173            IP Payload Compression Protocol       September 2001


   Implementation note:

      IPCAs become non-unique when two or more IPComp sessions are
      established between two nodes, and the same well-known CPI is used
      in at least two of the sessions.  Non-unique IPCAs pose problems
      in maintaining attributes specific to each IPCA, either negotiated
      (e.g., lifetime) or internal (e.g., the counters of the adaptive
      algorithm for handling previously compressed payload).  To ensure
      the uniqueness of IPCAs between two nodes, when two or more of the
      IPCAs use the same compression algorithm, the CPIs SHOULD be in
      the negotiated range.  However, when the IPCAs are not required to
      be unique, for example when no attribute is being utilized for
      these IPCAs, a well-known CPI MAY be used.  To clarify: When only
      a single session using a particular well-known CPI is established
      between two nodes, this IPCA is unique.

4.2. Use of Non-IKE Protocol

   The dynamic negotiations MAY be implemented through a protocol other
   than IKE.  Such a protocol is beyond the scope of this document.

4.3. Manual Configuration

   Nodes may establish IPComp Associations using manual configuration.
   For this method, a limited number of Compression Parameters Indexes
   (CPIs) is designated to represent a list of specific compression
   methods.

5. Security Considerations

   When IPComp is used in the context of IPsec, it is believed not to
   have an effect on the underlying security functionality provided by
   the IPsec 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.

   When IPComp is used without IPsec, IP payload compression potentially
   reduces the security of the Internet, similar to the effects of IP
   encapsulation [RFC2003].  For example, IPComp may make 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
   is not located in its normal positions within the datagram, and any
   transport layer 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.  A
   filtering border router can filter the datagram only if it shares the
   IPComp Association used for the compression.  To allow this sort of
   compression in environments in which all packets need to be filtered



Shacham, et al.             Standards Track                     [Page 9]

RFC 3173            IP Payload Compression Protocol       September 2001


   (or at least accounted for), a mechanism must be in place for the
   receiving node to securely communicate the IPComp Association to the
   border router.  This might, more rarely, also apply to the IPComp
   Association used for outgoing datagrams.

6. IANA Considerations

   This document does not require any IANA actions.  The well-known
   numbers used in this document are defined elsewhere; see [SECDOI].

7. Changes made since RFC 2393

   This section summarizes the changes in this document from RFC 2393 of
   which an implementer of RFC 2393 should be aware.  All the changes
   are meant to clarify the negotiation of an IPComp Association (IPCA)
   using IKE [IKE] in the context of IPsec.

   1) Added a clarification that IPComp can be negotiated stand-alone or
      bundled with other protocols in a Protection Suite.

   2) Defined the CPI in the SPI field of an IKE proposal: two-octet
      field is a SHOULD, four-octet a MAY.  Defined the placement of the
      16-bit CPI in a four-octet field.  Specified that a receiver MUST
      process both field sizes.

   3) Added wording to define the default Encapsulation Mode to be
      Transport Mode.  Required that an IPComp proposal MUST include an
      Encapsulation Mode attribute when it suggests a non-default
      encapsulation, such as Tunnel Mode.

   4) Added the Lifetime attribute to the list of supported attributes
      (along with Transport Mode).

   5) Specified the handling of attributes of transforms in a Protection
      Suite that are not applicable to IPComp: These attributes SHOULD
      NOT be included in an IPComp proposal and MUST be ignored when
      setting IPCA and in the operation of IPComp.  IPComp
      implementations MUST never reject an IPCOMP proposal that does not
      include attributes of other transforms.

   6) Added implementation notes on the negotiation and usage of CPIs in
      the predefined (well-known) range.









Shacham, et al.             Standards Track                    [Page 10]

RFC 3173            IP Payload Compression Protocol       September 2001


8. References

   [RFC0791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
             September 1981.

   [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
             1700, October 1994.  Or see:
             http://www.iana.org/numbers.html

   [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
             (IPv6) Specification", RFC 2460, December 1998.

   [RFC1962] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
             1962, June 1996.

   [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
             October 1996.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [IKE]     Harkins, D. and D. Carrel, "The Internet Key Exchange
             (IKE)", RFC 2409, November 1998.

   [SECDOI]  Piper, D., "The Internet IP Security Domain of
             Interpretation for ISAKMP", RFC 2407, November 1998.

   [V42BIS]  CCITT, "Data Compression Procedures for Data Circuit
             Terminating Equipment (DCE) Using Error Correction
             Procedures", Recommendation V.42 bis, January 1990.





















Shacham, et al.             Standards Track                    [Page 11]

RFC 3173            IP Payload Compression Protocol       September 2001


Authors' Addresses

   Abraham Shacham
   Juniper Networks, Inc.
   1194 North Mathilda Avenue
   Sunnyvale, California 94089
   United States of America

   EMail: [e-mail]


   Bob Monsour
   18 Stout Road
   Princeton, New Jersey 08540
   United States of America

   EMail: [e-mail]


   Roy Pereira
   Cisco Systems, Inc.
   55 Metcalfe Street
   Ottawa, Ontario K1P 6L5
   Canada

   EMail: [e-mail]


   Matt Thomas
   3am Software Foundry
   8053 Park Villa Circle
   Cupertino, California 95014
   United States of America

   EMail: [e-mail]

Comments

   Comments should be addressed to the [e-mail] mailing
   list and/or the author(s).











Shacham, et al.             Standards Track                    [Page 12]

RFC 3173            IP Payload Compression Protocol       September 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Shacham, et al.             Standards Track                    [Page 13]