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.
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.
- 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.
- A connected notify is received
- A message protected by the SA is received
- The last usable SA expires