rfc2407.txt

RFC 的详细文档！

   provide for the derivation of cryptographic keying material in a
   secure and authenticated manner.  Specific discussion of the various
   security protocols and transforms identified in this document can be
   found in the associated base documents and in the cipher references.

6. IANA Considerations

   This document contains many "magic" numbers to be maintained by the
   IANA.  This section explains the criteria to be used by the IANA to
   assign additional numbers in each of these lists.  All values not
   explicitly defined in previous sections are reserved to IANA.






Piper                       Standards Track                    [Page 24]

RFC 2407          IP Security Domain of Interpretation     November 1998


6.1 IPSEC Situation Definition

   The Situation Definition is a 32-bit bitmask which represents the
   environment under which the IPSEC SA proposal and negotiation is
   carried out.  Requests for assignments of new situations must be
   accompanied by an RFC which describes the interpretation for the
   associated bit.

   If the RFC is not on the standards-track (i.e., it is an
   informational or experimental RFC), it must be explicitly reviewed
   and approved by the IESG before the RFC is published and the
   transform identifier is assigned.

   The upper two bits are reserved for private use amongst cooperating
   systems.

6.2 IPSEC Security Protocol Identifiers

   The Security Protocol Identifier is an 8-bit value which identifies a
   security protocol suite being negotiated.  Requests for assignments
   of new security protocol identifiers must be accompanied by an RFC
   which describes the requested security protocol.  [AH] and [ESP] are
   examples of security protocol documents.

   If the RFC is not on the standards-track (i.e., it is an
   informational or experimental RFC), it must be explicitly reviewed
   and approved by the IESG before the RFC is published and the
   transform identifier is assigned.

   The values 249-255 are reserved for private use amongst cooperating
   systems.

6.3 IPSEC ISAKMP Transform Identifiers

   The IPSEC ISAKMP Transform Identifier is an 8-bit value which
   identifies a key exchange protocol to be used for the negotiation.
   Requests for assignments of new ISAKMP transform identifiers must be
   accompanied by an RFC which describes the requested key exchange
   protocol.  [IKE] is an example of one such document.

   If the RFC is not on the standards-track (i.e., it is an
   informational or experimental RFC), it must be explicitly reviewed
   and approved by the IESG before the RFC is published and the
   transform identifier is assigned.

   The values 249-255 are reserved for private use amongst cooperating
   systems.




Piper                       Standards Track                    [Page 25]

RFC 2407          IP Security Domain of Interpretation     November 1998


6.4 IPSEC AH Transform Identifiers

   The IPSEC AH Transform Identifier is an 8-bit value which identifies
   a particular algorithm to be used to provide integrity protection for
   AH.  Requests for assignments of new AH transform identifiers must be
   accompanied by an RFC which describes how to use the algorithm within
   the AH framework ([AH]).

   If the RFC is not on the standards-track (i.e., it is an
   informational or experimental RFC), it must be explicitly reviewed
   and approved by the IESG before the RFC is published and the
   transform identifier is assigned.

   The values 249-255 are reserved for private use amongst cooperating
   systems.

6.5 IPSEC ESP Transform Identifiers

   The IPSEC ESP Transform Identifier is an 8-bit value which identifies
   a particular algorithm to be used to provide secrecy protection for
   ESP.  Requests for assignments of new ESP transform identifiers must
   be accompanied by an RFC which describes how to use the algorithm
   within the ESP framework ([ESP]).

   If the RFC is not on the standards-track (i.e., it is an
   informational or experimental RFC), it must be explicitly reviewed
   and approved by the IESG before the RFC is published and the
   transform identifier is assigned.

   The values 249-255 are reserved for private use amongst cooperating
   systems.

6.6 IPSEC IPCOMP Transform Identifiers

   The IPSEC IPCOMP Transform Identifier is an 8-bit value which
   identifier a particular algorithm to be used to provide IP-level
   compression before ESP.  Requests for assignments of new IPCOMP
   transform identifiers must be accompanied by an RFC which describes
   how to use the algorithm within the IPCOMP framework ([IPCOMP]).  In
   addition, the requested algorithm must be published and in the public
   domain.

   If the RFC is not on the standards-track (i.e., it is an
   informational or experimental RFC), it must be explicitly reviewed
   and approved by the IESG before the RFC is published and the
   transform identifier is assigned.





Piper                       Standards Track                    [Page 26]

RFC 2407          IP Security Domain of Interpretation     November 1998


   The values 1-47 are reserved for algorithms for which an RFC has been
   approved for publication.  The values 48-63 are reserved for private
   use amongst cooperating systems.  The values 64-255 are reserved for
   future expansion.

6.7 IPSEC Security Association Attributes

   The IPSEC Security Association Attribute consists of a 16-bit type
   and its associated value.  IPSEC SA attributes are used to pass
   miscellaneous values between ISAKMP peers.  Requests for assignments
   of new IPSEC SA attributes must be accompanied by an Internet Draft
   which describes the attribute encoding (Basic/Variable-Length) and
   its legal values.  Section 4.5 of this document provides an example
   of such a description.

   The values 32001-32767 are reserved for private use amongst
   cooperating systems.

6.8 IPSEC Labeled Domain Identifiers

   The IPSEC Labeled Domain Identifier is a 32-bit value which
   identifies a namespace in which the Secrecy and Integrity levels and
   categories values are said to exist.  Requests for assignments of new
   IPSEC Labeled Domain Identifiers should be granted on demand.  No
   accompanying documentation is required, though Internet Drafts are
   encouraged when appropriate.

   The values 0x80000000-0xffffffff are reserved for private use amongst
   cooperating systems.

6.9 IPSEC Identification Type

   The IPSEC Identification Type is an 8-bit value which is used as a
   discriminant for interpretation of the variable-length Identification
   Payload.  Requests for assignments of new IPSEC Identification Types
   must be accompanied by an RFC which describes how to use the
   identification type within IPSEC.

   If the RFC is not on the standards-track (i.e., it is an
   informational or experimental RFC), it must be explicitly reviewed
   and approved by the IESG before the RFC is published and the
   transform identifier is assigned.

   The values 249-255 are reserved for private use amongst cooperating
   systems.






Piper                       Standards Track                    [Page 27]

RFC 2407          IP Security Domain of Interpretation     November 1998


6.10 IPSEC Notify Message Types

   The IPSEC Notify Message Type is a 16-bit value taken from the range
   of values reserved by ISAKMP for each DOI.  There is one range for
   error messages (8192-16383) and a different range for status messages
   (24576-32767).  Requests for assignments of new Notify Message Types
   must be accompanied by an Internet Draft which describes how to use
   the identification type within IPSEC.

   The values 16001-16383 and the values 32001-32767 are reserved for
   private use amongst cooperating systems.

7. Change Log

7.1 Changes from V9

     o  add explicit reference to [IPCOMP], [DEFLATE], and [LZS]
     o  allow RESPONDER-LIFETIME and REPLAY-STATUS to be directed
        at an IPSEC SPI in addition to the ISAKMP "SPI"
     o  added padding exclusion to Secrecy and Integrity Length text
     o  added forward reference to Section 4.5 in Section 4.4.4
     o  update document references

7.2 Changes from V8

     o  update IPCOMP identifier range to better reflect IPCOMP draft
     o  update IANA considerations per Jeff/Ted's suggested text
     o  eliminate references to DES-MAC ID ([DESMAC])
     o  correct bug in Notify section; ISAKMP Notify values are 16-bits

7.3 Changes from V7

     o  corrected name of IPCOMP (IP Payload Compression)
     o  corrected references to [ESPCBC]
     o  added missing Secrecy Level and Integrity Level to Figure 1
     o  removed ID references to PF_KEY and ARCFOUR
     o  updated Basic/Variable text to align with [IKE]
     o  updated document references and add intro pointer to [ARCH]
     o  updated Notification requirements; remove aggressive reference
     o  added clarification about protection for Notify payloads
     o  restored RESERVED to ESP transform ID namespace; moved ESP_NULL
     o  added requirement for ESP_NULL support and [ESPNULL] reference
     o  added clarification on Auth Alg use with AH/ESP
     o  added restriction against using conflicting AH/Auth combinations

7.4 Changes from V6

   The following changes were made relative to the IPSEC DOI V6:



Piper                       Standards Track                    [Page 28]

RFC 2407          IP Security Domain of Interpretation     November 1998


     o  added IANA Considerations section
     o  moved most IANA numbers to IANA Considerations section
     o  added prohibition on sending (V) encoding for (B) attributes
     o  added prohibition on sending Key Length attribute for fixed
        length ciphers (e.g. DES)
     o  replaced references to ISAKMP/Oakley with IKE
     o  renamed ESP_ARCFOUR to ESP_RC4
     o  updated Security Considerations section
     o  updated document references

7.5 Changes from V5

   The following changes were made relative to the IPSEC DOI V5:

     o  changed SPI size in Lifetime Notification text
     o  changed REPLAY-ENABLED to REPLAY-STATUS
     o  moved RESPONDER-LIFETIME payload definition from Section 4.5.4
        to Section 4.6.3.1
     o  added explicit payload layout for 4.6.3.3
     o  added Implementation Note to Section 4.6.3 introduction
     o  changed AH_SHA text to require SHA-1 in addition to MD5
     o  updated document references

7.6 Changes from V4

   The following changes were made relative to the IPSEC DOI V4:

     o  moved compatibility AH KPDK authentication method from AH
        transform ID to Authentication Algorithm identifier
     o  added REPLAY-ENABLED notification message type per Architecture
     o  added INITIAL-CONTACT notification message type per list
     o  added text to ensure protection for Notify Status messages
     o  added Lifetime qualification to attribute parsing section
     o  added clarification that Lifetime notification is optional
     o  removed private Group Description list (now points at [IKE])
     o  replaced Terminology with pointer to RFC-2119
     o  updated HMAC MD5 and SHA-1 ID references
     o  updated Section 1 (Abstract)
     o  updated Section 4.4 (IPSEC Assigned Numbers)
     o  added restriction for ID port/protocol values for Phase I

7.7 Changes from V3 to V4

   The following changes were made relative to the IPSEC DOI V3, that
   was posted to the IPSEC mailing list prior to the Munich IETF:

     o  added ESP transform identifiers for NULL and ARCFOUR




Piper                       Standards Track                    [Page 29]

RFC 2407          IP Security Domain of Interpretation     November 1998


     o  renamed HMAC Algorithm to Auth Algorithm to accommodate
        DES-MAC and optional authentication/integrity for ESP
     o  added AH and ESP DES-MAC algorithm identifiers
     o  removed KEY_MANUAL and KEY_KDC identifier definitions
     o  added lifetime duration MUST follow lifetype attribute to
        SA Life Type and SA Life Duration attribute definition
     o  added lifetime notification and IPSEC DOI message type table
     o  added optional authentication and confidentiality
        restrictions to MAC Algorithm attribute definition
     o  corrected attribute parsing example (used obsolete attribute)
     o  corrected several Internet Draft document references
     o  added ID_KEY_ID per ipsec list discussion (18-Mar-97)
     o  removed Group Description default for PFS QM ([IKE] MUST)

Acknowledgments

   This document is derived, in part, from previous works by Douglas
   Maughan, Mark Schertler, Mark Schneider, Jeff Turner, Dan Harkins,
   and Dave Carrel.  Matt Thomas, Roy Pereira, Greg Carter, and Ran
   Atkinson also contributed suggestions and, in many cases, text.

References

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

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