rfc2407.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

4.4.1.2 PROTO_IPSEC_AH

   The PROTO_IPSEC_AH type specifies IP packet authentication.  The
   default AH transform provides data origin authentication, integrity
   protection, and replay detection.  For export control considerations,
   confidentiality MUST NOT be provided by any PROTO_IPSEC_AH transform.

4.4.1.3 PROTO_IPSEC_ESP

   The PROTO_IPSEC_ESP type specifies IP packet confidentiality.
   Authentication, if required, must be provided as part of the ESP
   transform.  The default ESP transform includes data origin
   authentication, integrity protection, replay detection, and
   confidentiality.

4.4.1.4 PROTO_IPCOMP

   The PROTO_IPCOMP type specifies IP payload compression as defined in
   [IPCOMP].

4.4.2 IPSEC ISAKMP Transform Identifiers

   As part of an ISAKMP Phase I negotiation, the initiator's choice of
   Key Exchange offerings is made using some host system policy
   description.  The actual selection of Key Exchange mechanism is made
   using the standard ISAKMP Proposal Payload.  The following table
   lists the defined ISAKMP Phase I Transform Identifiers for the
   Proposal Payload for the IPSEC DOI.

       Transform                           Value
       ---------                           -----
       RESERVED                            0
       KEY_IKE                             1

   Within the ISAKMP and IPSEC DOI framework it is possible to define
   key establishment protocols other than IKE (Oakley).  Previous
   versions of this document defined types both for manual keying and
   for schemes based on use of a generic Key Distribution Center (KDC).
   These identifiers have been removed from the current document.

   The IPSEC DOI can still be extended later to include values for
   additional non-Oakley key establishment protocols for ISAKMP and
   IPSEC, such as Kerberos [RFC-1510] or the Group Key Management
   Protocol (GKMP) [RFC-2093].







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


4.4.2.1 KEY_IKE

   The KEY_IKE type specifies the hybrid ISAKMP/Oakley Diffie-Hellman
   key exchange (IKE) as defined in the [IKE] document.  All
   implementations within the IPSEC DOI MUST support KEY_IKE.

4.4.3 IPSEC AH Transform Identifiers

   The Authentication Header Protocol (AH) defines one mandatory and
   several optional transforms used to provide authentication,
   integrity, and replay detection.  The following table lists the
   defined AH Transform Identifiers for the ISAKMP Proposal Payload for
   the IPSEC DOI.

   Note: the Authentication Algorithm attribute MUST be specified to
   identify the appropriate AH protection suite.  For example, AH_MD5
   can best be thought of as a generic AH transform using MD5.  To
   request the HMAC construction with AH, one specifies the AH_MD5
   transform ID along with the Authentication Algorithm attribute set to
   HMAC-MD5.  This is shown using the "Auth(HMAC-MD5)" notation in the
   following sections.

       Transform ID                        Value
       ------------                        -----
       RESERVED                            0-1
       AH_MD5                              2
       AH_SHA                              3
       AH_DES                              4

   Note: all mandatory-to-implement algorithms are listed as "MUST"
   implement (e.g. AH_MD5) in the following sections.  All other
   algorithms are optional and MAY be implemented in any particular
   implementation.

4.4.3.1 AH_MD5

   The AH_MD5 type specifies a generic AH transform using MD5.  The
   actual protection suite is determined in concert with an associated
   SA attribute list.  A generic MD5 transform is currently undefined.

   All implementations within the IPSEC DOI MUST support AH_MD5 along
   with the Auth(HMAC-MD5) attribute.  This suite is defined as the
   HMAC-MD5-96 transform described in [HMACMD5].

   The AH_MD5 type along with the Auth(KPDK) attribute specifies the AH
   transform (Key/Pad/Data/Key) described in RFC-1826.





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


   Use of AH_MD5 with any other Authentication Algorithm attribute value
   is currently undefined.

4.4.3.2 AH_SHA

   The AH_SHA type specifies a generic AH transform using SHA-1.  The
   actual protection suite is determined in concert with an associated
   SA attribute list.  A generic SHA transform is currently undefined.

   All implementations within the IPSEC DOI MUST support AH_SHA along
   with the Auth(HMAC-SHA) attribute.  This suite is defined as the
   HMAC-SHA-1-96 transform described in [HMACSHA].

   Use of AH_SHA with any other Authentication Algorithm attribute value
   is currently undefined.

4.4.3.3 AH_DES

   The AH_DES type specifies a generic AH transform using DES.  The
   actual protection suite is determined in concert with an associated
   SA attribute list.  A generic DES transform is currently undefined.

   The IPSEC DOI defines AH_DES along with the Auth(DES-MAC) attribute
   to be a DES-MAC transform.  Implementations are not required to
   support this mode.

   Use of AH_DES with any other Authentication Algorithm attribute value
   is currently undefined.

4.4.4 IPSEC ESP Transform Identifiers

   The Encapsulating Security Payload (ESP) defines one mandatory and
   many optional transforms used to provide data confidentiality.  The
   following table lists the defined ESP Transform Identifiers for the
   ISAKMP Proposal Payload for the IPSEC DOI.

   Note: when authentication, integrity protection, and replay detection
   are required, the Authentication Algorithm attribute MUST be
   specified to identify the appropriate ESP protection suite.  For
   example, to request HMAC-MD5 authentication with 3DES, one specifies
   the ESP_3DES transform ID with the Authentication Algorithm attribute
   set to HMAC-MD5.  For additional processing requirements, see Section
   4.5 (Authentication Algorithm).








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


       Transform ID                        Value
       ------------                        -----
       RESERVED                            0
       ESP_DES_IV64                        1
       ESP_DES                             2
       ESP_3DES                            3
       ESP_RC5                             4
       ESP_IDEA                            5
       ESP_CAST                            6
       ESP_BLOWFISH                        7
       ESP_3IDEA                           8
       ESP_DES_IV32                        9
       ESP_RC4                             10
       ESP_NULL                            11

   Note: all mandatory-to-implement algorithms are listed as "MUST"
   implement (e.g. ESP_DES) in the following sections.  All other
   algorithms are optional and MAY be implemented in any particular
   implementation.

4.4.4.1 ESP_DES_IV64

   The ESP_DES_IV64 type specifies the DES-CBC transform defined in
   RFC-1827 and RFC-1829 using a 64-bit IV.

4.4.4.2 ESP_DES

   The ESP_DES type specifies a generic DES transform using DES-CBC.
   The actual protection suite is determined in concert with an
   associated SA attribute list.  A generic transform is currently
   undefined.

   All implementations within the IPSEC DOI MUST support ESP_DES along
   with the Auth(HMAC-MD5) attribute.  This suite is defined as the
   [DES] transform, with authentication and integrity provided by HMAC
   MD5 [HMACMD5].

4.4.4.3 ESP_3DES

   The ESP_3DES type specifies a generic triple-DES transform.  The
   actual protection suite is determined in concert with an associated
   SA attribute list.  The generic transform is currently undefined.

   All implementations within the IPSEC DOI are strongly encouraged to
   support ESP_3DES along with the Auth(HMAC-MD5) attribute.  This suite
   is defined as the [ESPCBC] transform, with authentication and
   integrity provided by HMAC MD5 [HMACMD5].




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


4.4.4.4 ESP_RC5

   The ESP_RC5 type specifies the RC5 transform defined in [ESPCBC].

4.4.4.5 ESP_IDEA

   The ESP_IDEA type specifies the IDEA transform defined in [ESPCBC].

4.4.4.6 ESP_CAST

   The ESP_CAST type specifies the CAST transform defined in [ESPCBC].

4.4.4.7 ESP_BLOWFISH

   The ESP_BLOWFISH type specifies the BLOWFISH transform defined in
   [ESPCBC].

4.4.4.8 ESP_3IDEA

   The ESP_3IDEA type is reserved for triple-IDEA.

4.4.4.9 ESP_DES_IV32

   The ESP_DES_IV32 type specifies the DES-CBC transform defined in
   RFC-1827 and RFC-1829 using a 32-bit IV.

4.4.4.10 ESP_RC4

   The ESP_RC4 type is reserved for RC4.

4.4.4.11 ESP_NULL

   The ESP_NULL type specifies no confidentiality is to be provided by
   ESP.  ESP_NULL is used when ESP is being used to tunnel packets which
   require only authentication, integrity protection, and replay
   detection.

   All implementations within the IPSEC DOI MUST support ESP_NULL.  The
   ESP NULL transform is defined in [ESPNULL].  See the Authentication
   Algorithm attribute description in Section 4.5 for additional
   requirements relating to the use of ESP_NULL.

4.4.5 IPSEC IPCOMP Transform Identifiers

   The IP Compression (IPCOMP) transforms define optional compression
   algorithms that can be negotiated to provide for IP payload
   compression ([IPCOMP]).  The following table lists the defined IPCOMP
   Transform Identifiers for the ISAKMP Proposal Payload within the



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


   IPSEC DOI.

       Transform ID                        Value
       ------------                        -----
       RESERVED                            0
       IPCOMP_OUI                          1
       IPCOMP_DEFLATE                      2
       IPCOMP_LZS                          3

4.4.5.1 IPCOMP_OUI

   The IPCOMP_OUI type specifies a proprietary compression transform.
   The IPCOMP_OUI type must be accompanied by an attribute which further
   identifies the specific vendor algorithm.

4.4.5.2 IPCOMP_DEFLATE

   The IPCOMP_DEFLATE type specifies the use of the "zlib" deflate
   algorithm as specified in [DEFLATE].

4.4.5.3 IPCOMP_LZS

   The IPCOMP_LZS type specifies the use of the Stac Electronics LZS
   algorithm as specified in [LZS].

4.5 IPSEC Security Association Attributes

   The following SA attribute definitions are used in Phase II of an IKE
   negotiation.  Attribute types can be either Basic (B) or Variable-
   Length (V).  Encoding of these attributes is defined in the base
   ISAKMP specification.

   Attributes described as basic MUST NOT be encoded as variable.
   Variable length attributes MAY be encoded as basic attributes if
   their value can fit into two octets.  See [IKE] for further
   information on attribute encoding in the IPSEC DOI.  All restrictions
   listed in [IKE] also apply to the IPSEC DOI.














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


       Attribute Types

             class               value           type
       -------------------------------------------------