3.5.5.1 Received Quick Mode First Exchange Request

Figure 15: Quick Mode First Exchange packet
If the responder is not in Main Mode Responder First Exchange Done state, when it receives the above packet it MUST tear down the corresponding main mode (MM) if it can match the packet to an existing main mode, and silently discard the packet otherwise.
If the responder encounters any errors in the processing of a message it MUST be treated as an Invalid Message event. See section 3.5.7.1.
Upon receipt of message #5 (as labeled in the previous diagram), the responder MUST:
Decrypt the Crypto payload.
Compute Auth1 as specified in section 3.1.7.4.
Verify that the HAuth1 payload contains the computed Auth1 value.
Consult the SPD to select a proposal from the SA, IDi, and IDr payloads, and generate the KE by using Diffie-Hellman, as specified in [RFC2408] section 3.7.
Store the peer's Key Dictation Weight in the per QM SA KeyDictationWtRemote field. If the LocalEndWantsToDictateKey is set, compare it with its own KeyDictationWtRemote stored in the per QM SA KeyDictationWtLocal field, if any. The end with the higher weight wins (that is, either KeyDictationLocalWinner or KeyDictationRemoteWinner is set). However, if LocalEndWantsToDictateKey is not set, then set KeyDictationRemoteWinner, irrespective of the peer's weight.
If the responder encounters no errors while it processes message #5 and at least one of the initiator proposals is acceptable (under the criteria specified in IKEv1; for more information, see [RFC2408] section 5.4), it MUST construct message #6 in response as follows:
HDR: The ISAKMP header MUST be identical to the first IKE phase 2 initiator packet (as specified in [RFC2409] section 5.5), except that the exchange type MUST be 243 (MM exchange type) for the first quick mode exchange under this main mode or 244 (quick mode exchange type) for any subsequent quick mode exchange. The Encrypted flag MUST be set.
The payloads that remain MUST be encapsulated in a Crypto payload.
HAuth2: The ISAKMP Hash payload MUST contain the field Auth2 computed as defined in section 3.1.7.4.
IDi, IDr, SA, KE: These payloads MUST be identical to the corresponding IKE payloads specified in [RFC2408] sections 3.8, 3.4, and 3.13.
Notify(exchange_info): If either guaranteed encryption is active or the sender uses negotiation discovery, the EXCHANGE_INFO Notify payload MUST be used to indicate this information to the peer. A precondition for sending this notify is that the MM SA MUST have its PeerIsNegotiationDiscoveryCapable flag set in the MMSAD (see section 3.2.5.1). These two policy options are specified in [MS-IKEE], section 3.7.4.
SKWt: If dictating keys (that is, LocalEndWantsToDictateKey is set), then the Key Dictation Weight payload MUST contain the weight stored in the per QM SA KeyDictationWtLocal field to communicate the intent to a peer.
KeyDict(In) and KeyDict(Out): The responder already knows the Key Dictation weights of the local and remote ends, if any, stored in the per QM SA KeyDictationWtLocal and KeyDictationWtRemote fields, respectively. If the responder has the higher weight and there is no Extended Mode to follow, then it constructs the Key Dictation payloads for inbound and outbound quick mode keys with the dictated keys (see section 2.2.3.7).

Figure 16: Quick Mode Exchange Info notify packet
If no proposal is acceptable (as determined by the procedure specified in [RFC2408] section 5.4), the responder MUST send a Notification NO-PROPOSAL-CHOSEN payload (section 2.2.3.5) with RELIABLE_NOTIFY_FLAG set to indicate that no proposal was chosen. The payload MUST be formatted as specified in [RFC2408] section 5.4.