rfc2406.txt

RFC 的详细文档！

        b. The pad length or pad values could be erroneous -- Bad pad
           lengths or pad values can be detected irrespective of the use
           of authentication.

        c. The encrypted ESP packet could be corrupted -- This can be
           detected if authentication is selected for the SA.,

   In case (a) or (c), the erroneous result of the decryption operation
   (an invalid IP datagram or transport-layer frame) will not
   necessarily be detected by IPsec, and is the responsibility of later
   protocol processing.

4.  Auditing

   Not all systems that implement ESP will implement auditing.  However,
   if ESP is incorporated into a system that supports auditing, then the
   ESP implementation MUST also support auditing and MUST allow a system
   administrator to enable or disable auditing for ESP.  For the most
   part, the granularity of auditing is a local matter.  However,
   several auditable events are identified in this specification and for
   each of these events a minimum set of information that SHOULD be
   included in an audit log is defined.  Additional information also MAY
   be included in the audit log for each of these events, and additional



Kent & Atkinson             Standards Track                    [Page 17]

RFC 2406           IP Encapsulating Security Payload       November 1998


   events, not explicitly called out in this specification, also MAY
   result in audit log entries.  There is no requirement for the
   receiver to transmit any message to the purported sender in response
   to the detection of an auditable event, because of the potential to
   induce denial of service via such action.

5.  Conformance Requirements

   Implementations that claim conformance or compliance with this
   specification MUST implement the ESP syntax and processing described
   here and MUST comply with all requirements of the Security
   Architecture document.  If the key used to compute an ICV is manually
   distributed, correct provision of the anti-replay service would
   require correct maintenance of the counter state at the sender, until
   the key is replaced, and there likely would be no automated recovery
   provision if counter overflow were imminent.  Thus a compliant
   implementation SHOULD NOT provide this service in conjunction with
   SAs that are manually keyed.  A compliant ESP implementation MUST
   support the following mandatory-to-implement algorithms:

             - DES in CBC mode [MD97]
             - HMAC with MD5 [MG97a]
             - HMAC with SHA-1 [MG97b]
             - NULL Authentication algorithm
             - NULL Encryption algorithm

   Since ESP encryption and authentication are optional, support for the
   2 "NULL" algorithms is required to maintain consistency with the way
   these services are negotiated.  NOTE that while authentication and
   encryption can each be "NULL", they MUST NOT both be "NULL".

6.  Security Considerations

   Security is central to the design of this protocol, and thus security
   considerations permeate the specification.  Additional security-
   relevant aspects of using the IPsec protocol are discussed in the
   Security Architecture document.

7.  Differences from RFC 1827

   This document differs from RFC 1827 [ATK95] in several significant
   ways.  The major difference is that, this document attempts to
   specify a complete framework and context for ESP, whereas RFC 1827
   provided a "shell" that was completed through the definition of
   transforms.  The combinatorial growth of transforms motivated the
   reformulation of the ESP specification as a more complete document,
   with options for security services that may be offered in the context
   of ESP.  Thus, fields previously defined in transform documents are



Kent & Atkinson             Standards Track                    [Page 18]

RFC 2406           IP Encapsulating Security Payload       November 1998


   now part of this base ESP specification.  For example, the fields
   necessary to support authentication (and anti-replay) are now defined
   here, even though the provision of this service is an option.  The
   fields used to support padding for encryption, and for next protocol
   identification, are now defined here as well.  Packet processing
   consistent with the definition of these fields also is included in
   the document.

Acknowledgements

   Many of the concepts embodied in this specification were derived from
   or influenced by the US Government's SP3 security protocol, ISO/IEC's
   NLSP, or from the proposed swIPe security protocol.  [SDNS89, ISO92,
   IB93].

   For over 3 years, this document has evolved through multiple versions
   and iterations.  During this time, many people have contributed
   significant ideas and energy to the process and the documents
   themselves.  The authors would like to thank Karen Seo for providing
   extensive help in the review, editing, background research, and
   coordination for this version of the specification.  The authors
   would also like to thank the members of the IPsec and IPng working
   groups, with special mention of the efforts of (in alphabetic order):
   Steve Bellovin, Steve Deering, Phil Karn, Perry Metzger, David
   Mihelcic, Hilarie Orman, Norman Shulman, William Simpson and Nina
   Yuan.

References

   [ATK95]   Atkinson, R., "IP Encapsulating Security Payload (ESP)",
             RFC 1827, August 1995.

   [Bel96]   Steven M. Bellovin, "Problem Areas for the IP Security
             Protocols", Proceedings of the Sixth Usenix Unix Security
             Symposium, July, 1996.

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

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

   [IB93]    John Ioannidis & Matt Blaze, "Architecture and
             Implementation of Network-layer Security Under Unix",
             Proceedings of the USENIX Security Symposium, Santa Clara,
             CA, October 1993.





Kent & Atkinson             Standards Track                    [Page 19]

RFC 2406           IP Encapsulating Security Payload       November 1998


   [ISO92]   ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC
             DIS 11577, International Standards Organisation, Geneva,
             Switzerland, 29 November 1992.

   [KA97a]   Kent, S., and R. Atkinson, "Security Architecture for the
             Internet Protocol", RFC 2401, November 1998.

   [KA97b]   Kent, S., and R. Atkinson, "IP Authentication Header", RFC
             2402, November 1998.

   [MD97]    Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher
             Algorithm With Explicit IV", RFC 2405, November 1998.

   [MG97a]   Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within
             ESP and AH", RFC 2403, November 1998.

   [MG97b]   Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within
             ESP and AH", RFC 2404, November 1998.

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

   [SDNS89]  SDNS Secure Data Network System, Security Protocol 3, SP3,
             Document SDN.301, Revision 1.5, 15 May 1989, as published
             in NIST Publication NIST-IR-90-4250, February 1990.

Disclaimer

   The views and specification here are those of the authors and are not
   necessarily those of their employers.  The authors and their
   employers specifically disclaim responsibility for any problems
   arising from correct or incorrect implementation or use of this
   specification.

















Kent & Atkinson             Standards Track                    [Page 20]

RFC 2406           IP Encapsulating Security Payload       November 1998


Author Information

   Stephen Kent
   BBN Corporation
   70 Fawcett Street
   Cambridge, MA  02140
   USA

   Phone: [phone]
   EMail: [e-mail]


   Randall Atkinson
   @Home Network
   425 Broadway,
   Redwood City, CA  94063
   USA

   Phone: [phone]
   EMail: [e-mail]































Kent & Atkinson             Standards Track                    [Page 21]

RFC 2406           IP Encapsulating Security Payload       November 1998


Full Copyright Statement

   Copyright (C) The Internet Society (1998).  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.
























Kent & Atkinson             Standards Track                    [Page 22]