rfc2408.txt

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

Maughan, et. al.            Standards Track                    [Page 19]

RFC 2408                         ISAKMP                    November 1998


2.5 Miscellaneous

2.5.1 Transport Protocol

   ISAKMP can be implemented over any transport protocol or over IP
   itself.  Implementations MUST include send and receive capability for
   ISAKMP using the User Datagram Protocol (UDP) on port 500.  UDP Port
   500 has been assigned to ISAKMP by the Internet Assigned Numbers
   Authority (IANA). Implementations MAY additionally support ISAKMP
   over other transport protocols or over IP itself.

2.5.2 RESERVED Fields

   The existence of RESERVED fields within ISAKMP payloads are used
   strictly to preserve byte alignment.  All RESERVED fields in the
   ISAKMP protocol MUST be set to zero (0) when a packet is issued.  The
   receiver SHOULD check the RESERVED fields for a zero (0) value and
   discard the packet if other values are found.

2.5.3 Anti-Clogging Token ("Cookie") Creation

   The details of cookie generation are implementation dependent, but
   MUST satisfy these basic requirements (originally stated by Phil Karn
   in [Karn]):

      1.    The cookie must depend on the specific parties.  This
            prevents an attacker from obtaining a cookie using a real IP
            address and UDP port, and then using it to swamp the victim
            with Diffie-Hellman requests from randomly chosen IP
            addresses or ports.

      2.    It must not be possible for anyone other than the issuing
            entity to generate cookies that will be accepted by that
            entity.  This implies that the issuing entity must use local
            secret information in the generation and subsequent
            verification of a cookie.  It must not be possible to deduce
            this secret information from any particular cookie.

      3.    The cookie generation function must be fast to thwart
            attacks intended to sabotage CPU resources.

   Karn's suggested method for creating the cookie is to perform a fast
   hash (e.g.  MD5) over the IP Source and Destination Address, the UDP
   Source and Destination Ports and a locally generated secret random
   value.  ISAKMP requires that the cookie be unique for each SA
   establishment to help prevent replay attacks, therefore, the date and
   time MUST be added to the information hashed.  The generated cookies
   are placed in the ISAKMP Header (described in section 3.1) Initiator



Maughan, et. al.            Standards Track                    [Page 20]

RFC 2408                         ISAKMP                    November 1998


   and Responder cookie fields.  These fields are 8 octets in length,
   thus, requiring a generated cookie to be 8 octets.  Notify and Delete
   messages (see sections 3.14, 3.15, and 4.8) are uni-directional
   transmissions and are done under the protection of an existing ISAKMP
   SA, thus, not requiring the generation of a new cookie.  One
   exception to this is the transmission of a Notify message during a
   Phase 1 exchange, prior to completing the establishment of an SA.
   Sections 3.14 and 4.8 provide additional details.

3 ISAKMP Payloads

   ISAKMP payloads provide modular building blocks for constructing
   ISAKMP messages.  The presence and ordering of payloads in ISAKMP is
   defined by and dependent upon the Exchange Type Field located in the
   ISAKMP Header (see Figure 2).  The ISAKMP payload types are discussed
   in sections 3.4 through 3.15.  The descriptions of the ISAKMP
   payloads, messages, and exchanges (see Section 4) are shown using
   network octet ordering.

3.1 ISAKMP Header Format

   An ISAKMP message has a fixed header format, shown in Figure 2,
   followed by a variable number of payloads.  A fixed header simplifies
   parsing, providing the benefit of protocol parsing software that is
   less complex and easier to implement.  The fixed header contains the
   information required by the protocol to maintain state, process
   payloads and possibly prevent denial of service or replay attacks.

   The ISAKMP Header fields are defined as follows:

    o  Initiator Cookie (8 octets) - Cookie of entity that initiated SA
       establishment, SA notification, or SA deletion.

    o  Responder Cookie (8 octets) - Cookie of entity that is responding
       to an SA establishment request, SA notification, or SA deletion.
















Maughan, et. al.            Standards Track                    [Page 21]

RFC 2408                         ISAKMP                    November 1998


                         1                   2                   3
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                          Initiator                            !
    !                            Cookie                             !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                          Responder                            !
    !                            Cookie                             !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !  Next Payload ! MjVer ! MnVer ! Exchange Type !     Flags     !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                          Message ID                           !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                            Length                             !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                 Figure 2:  ISAKMP Header Format

    o  Next Payload (1 octet) - Indicates the type of the first payload
       in the message.  The format for each payload is defined in
       sections 3.4 through 3.16.  The processing for the payloads is
       defined in section 5.


                        Next Payload Type       Value
                    NONE                           0
                    Security Association (SA)      1
                    Proposal (P)                   2
                    Transform (T)                  3
                    Key Exchange (KE)              4
                    Identification (ID)            5
                    Certificate (CERT)             6
                    Certificate Request (CR)       7
                    Hash (HASH)                    8
                    Signature (SIG)                9
                    Nonce (NONCE)                 10
                    Notification (N)              11
                    Delete (D)                    12
                    Vendor ID (VID)               13
                    RESERVED                   14 - 127
                    Private USE               128 - 255

    o  Major Version (4 bits) - indicates the major version of the ISAKMP
       protocol in use.  Implementations based on this version of the
       ISAKMP Internet-Draft MUST set the Major Version to 1.
       Implementations based on previous versions of ISAKMP Internet-
       Drafts MUST set the Major Version to 0.  Implementations SHOULD



Maughan, et. al.            Standards Track                    [Page 22]

RFC 2408                         ISAKMP                    November 1998


       never accept packets with a major version number larger than its
       own.

    o  Minor Version (4 bits) - indicates the minor version of the
       ISAKMP protocol in use.  Implementations based on this version of
       the ISAKMP Internet-Draft MUST set the Minor Version to 0.
       Implementations based on previous versions of ISAKMP Internet-
       Drafts MUST set the Minor Version to 1.  Implementations SHOULD
       never accept packets with a minor version number larger than its
       own, given the major version numbers are identical.

    o  Exchange Type (1 octet) - indicates the type of exchange being
       used.  This dictates the message and payload orderings in the
       ISAKMP exchanges.


                            Exchange Type      Value
                         NONE                    0
                         Base                    1
                         Identity Protection     2
                         Authentication Only     3
                         Aggressive              4
                         Informational           5
                         ISAKMP Future Use     6 - 31
                         DOI Specific Use     32 - 239
                         Private Use         240 - 255

    o  Flags (1 octet) - indicates specific options that are set for the
       ISAKMP exchange.  The flags listed below are specified in the
       Flags field beginning with the least significant bit, i.e the
       Encryption bit is bit 0 of the Flags field, the Commit bit is bit
       1 of the Flags field, and the Authentication Only bit is bit 2 of
       the Flags field.  The remaining bits of the Flags field MUST be
       set to 0 prior to transmission.

      --  E(ncryption Bit) (1 bit) - If set (1), all payloads following
          the header are encrypted using the encryption algorithm
          identified in the ISAKMP SA. The ISAKMP SA Identifier is the
          combination of the initiator and responder cookie.  It is
          RECOMMENDED that encryption of communications be done as soon
          as possible between the peers.  For all ISAKMP exchanges
          described in section 4.1, the encryption SHOULD begin after
          both parties have exchanged Key Exchange payloads.  If the
          E(ncryption Bit) is not set (0), the payloads are not
          encrypted.






Maughan, et. al.            Standards Track                    [Page 23]

RFC 2408                         ISAKMP                    November 1998


      -- C(ommit Bit) (1 bit) - This bit is used to signal key exchange
          synchronization.  It is used to ensure that encrypted material
          is not received prior to completion of the SA establishment.
          The Commit Bit can be set (at anytime) by either party
          participating in the SA establishment, and can be used during
          both phases of an ISAKMP SA establishment.  However, the value
          MUST be reset after the Phase 1 negotiation.  If set(1), the
          entity which did not set the Commit Bit MUST wait for an
          Informational Exchange containing a Notify payload (with the
          CONNECTED Notify Message) from the entity which set the Commit
          Bit.  In this instance, the Message ID field of the
          Informational Exchange MUST contain the Message ID of the
          original ISAKMP Phase 2 SA negotiation.  This is done to
          ensure that the Informational Exchange with the CONNECTED
          Notify Message can be associated with the correct Phase 2 SA.
          The receipt and processing of the Informational Exchange
          indicates that the SA establishment was successful and either
          entity can now proceed with encrypted traffic communication.
          In addition to synchronizing key exchange, the Commit Bit can
          be used to protect against loss of transmissions over
          unreliable networks and guard against the need for multiple
          re-transmissions.

          NOTE: It is always possible that the final message of an
          exchange can be lost.  In this case, the entity expecting to
          receive the final message of an exchange would receive the
          Phase 2 SA negotiation message following a Phase 1 exchange or