Quick mode with commit bit

The ISAKMP protocol defines a bit in the ISAKMP message header known as the commit bit. When the commit bit is turned on during a Quick mode exchange, the responder should acknowledge the receipt of message 3. The responder does this by extending the Quick mode exchange to include a fourth message. The major advantage of commit-bit processing is increased interoperability and the elimination of a potential window where IP packets could be dropped during the process of negotiating a new security association.

The z/OS® IKE daemon uses commit-bit support as defined in the IKE draft dated May 1999. This draft was written after RFC 2409. No special configuration is required to take advantage of this support. When acting as a responder of a phase 2 negotiation, the IKE daemon always uses commit-bit logic. When acting as an initiator of a phase 2 negotiation, the IKE daemon always honors the commit-bit preference of the responder.

Figure 1 shows the new fourth message in the Quick mode exchange, which includes an encrypted hash along with a notify payload indicating that message 3 was received.

Figure 1. Quick mode exchange with commit-bit support

In quick mode with commit-bit support, the initiator server A exchanges four messages with responder server B. A sends the first message to B including encrypted Hash, proposed SAs, Nonce, and optional information. A receives the second message from B including encrypted Hash, SAs accepted, Nonce, and optional information. The optional information can be key generation information, or identity information, or both. A sends the third message of encrypted Hash to B and receives the fourth message including an encrypted hash with a notify payload indicating that message 3 was received. All the messages must be encrypted.

In a normal Quick mode exchange, the initiator can start using a newly negotiated SA immediately after sending message 3. The responder does not start using the newly negotiated SA until it receives message 3. Message 3 is sent using UDP. Because UDP is not a reliable protocol, it is possible that the initiator sends message 3 and that this message never gets processed by the responder. In this case, the responder retransmits message 2 back to the initiator, causing the initiator to retransmit message 3. Unfortunately, during the time between such retransmissions, the initiator might start using the SA to protect an IP packet. Any such packet would be discarded by the responder until it successfully processed message 3.

In a Quick mode exchange with commit processing, the initiator defers the usage of a newly negotiated SA until one of the following events occur:

The initiator receives a connected notify message
The initiator receives an IP packet that was protected with the SA

The responder continues to start using the newly negotiated SA when it receives message 3. This eliminates the window where one side might start using an SA before the other side knows that it is safe to use the SA.

On z/OS, an SA is considered to be in a pending state while the initiator is waiting for a connected notify message (for example, message 4). An SA is placed into a pending state only if another SA that could be used to protect outbound traffic exists. An SA in pending state remains in pending state until one of the following events occur:

A connected notify is received
A message protected by the SA is received
The last usable SA expires