rfc2408.txt

RFC 的详细文档！

   ISAKMP SAs are bidirectional in nature.

   Additionally, ISAKMP allows both initiator and responder to have some
   control during the negotiation process.  While ISAKMP is designed to
   allow an SA negotiation that includes multiple proposals, the
   initiator can maintain some control by only making one proposal in
   accordance with the initiator's local security policy.  Once the
   initiator sends a proposal containing more than one proposal (which
   are sent in decreasing preference order), the initiator relinquishes
   control to the responder.  Once the responder is controlling the SA
   establishment, the responder can make its policy take precedence over
   the initiator within the context of the multiple options offered by
   the initiator.  This is accomplished by selecting the proposal best
   suited for the responder's local security policy and returning this
   selection to the initiator.






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.