3.1.5 Message Processing Events and Sequencing Rules

  • Article

[RFC2407]: Message processing MUST be as specified in [RFC2407] with the following exceptions:

  • [RFC2407] section 4.5.2: "If conflicting attributes are detected, an ATTRIBUTES-NOT-SUPPORTED Notification Payload SHOULD be returned and the security association setup MUST be aborted."

    The IKE variant specified by this document MUST NOT terminate the SA setup when it encounters an unknown attribute.

  • [RFC2407] section 4.5.3: "If an implementation receives a defined IPSEC DOI attribute (or attribute value) that it does not support, an ATTRIBUTES-NOT-SUPPORTED SHOULD be sent and the security association setup MUST be aborted, unless the attribute value is in the reserved range."

    The IKE variant specified by this document MUST NOT terminate the SA setup when it encounters an unknown attribute.

  • [RFC2407] section 4.5.3: "Notification Status Messages MUST be sent under the protection of an ISAKMP SA, either as a payload in the last main mode exchange; in a separate informational exchange after main mode or aggressive mode processing is complete; or as a payload in any quick mode exchange."

    The IKE variant specified by this document SHOULD send notifications unprotected by an SA, without the hash payload, as specified in [RFC2409] section 5.7, if the notify occurs during the first two round trips of main mode. If the notify occurs in the last round trip of main mode, then this notify SHOULD be protected by the SA.<12>

[RFC2408]: Message processing MUST be as specified in [RFC2408] with the following exceptions:

  • [RFC2408] section 3.9: "The certificate payload MUST be accepted at any point during an exchange."

    The IKE variant specified by this document MUST NOT accept certificate payloads at any time; a certificate payload MUST be in a message that contains an ID payload.

  • [RFC2408] section 5.1: "When transmitting an ISAKMP message, the transmitting entity (initiator or responder (1)) MUST do the following: 1. Set a timer and initialize a retry counter."

    The IKE variant timer specified by this document does not set a retransmission timer in the following cases:

    • The responder (1) never sets a retransmission timer.

    • A notify message is sent to a peer.

    • A delete message is sent to a peer that does not support reliable deletes, that is, a peer that has not sent the Microsoft Implementation Vendor ID.

[RFC2409]: Message processing MUST be as specified in [RFC2409].

[RFC3947]: Message processing MUST be as specified in [RFC3947] with the following exceptions:

  • [RFC3947] section 5.2: "In the case of transport mode, both ends MUST send both original initiator and responder (1) addresses to the other end" and "The initiator MUST send the payloads if it proposes any UDP-Encapsulated-Transport mode, and the responder (1) MUST send the payload only if it selected UDP-Encapsulated-Transport mode."

    The IKE variant specified by this document MUST send the NAT-OA if the host is behind a NAT.

[RFC4306]: Message processing MUST be as specified in [RFC4306] with the following exceptions:

  • [RFC4306] section 2.7: "This hierarchical structure was designed to efficiently encode proposals for cryptographic suites when the number of supported suites is large because multiple values are acceptable for multiple transforms. The responder (1) MUST choose a single suite, which MAY be any subset of the SA proposal following the rules below:"

    The responder (1) MUST consult its SPD and loop through the SPD entries, comparing each SPD entry in turn with all the proposal suites from the peer. If a match is found from the list of proposal suites, the responder (1) MUST accept that proposal suite. This MUST repeat until a match is found, or policy comparison, and the negotiation fails.

  • [RFC4306] section 3.12: "Writers of Internet-Drafts who wish to extend this protocol MUST define a Vendor ID payload to announce the ability to implement the extension in the Internet-Draft."

    The IKE variant specified by this document does not define a Vendor ID to announce the implementation of CFG attributes described in section 3.11.