A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE)
Extracted elements (30)
Birth Certificates (a self-signed certificate generated at reboot time) were rejected in favor of QCD tokens because they require the token taker to store a public key certificate and perform expensive asymmetric key verification; the symmetric-key hash approach is lighter weight and simpler.
Initiating a new IKE SA with INITIAL_CONTACT was rejected because IKEv2 requires a piggybacked Child SA in every authentication exchange, and a rebooted gateway with no traffic flowing to the peer has no good traffic selectors. Furthermore, asymmetric authentication (EAP) may prevent the rebooted peer from acting as initiator.
Standard IKEv2 crash recovery (RFC 5996 Section 2.4) requires retransmitting liveness checks 'at least a dozen times over a period of at least several minutes' before declaring a peer dead, which creates a multi-minute blackout window. QCD tokens allow the rebooted peer to immediately signal its state loss to the survivor, eliminating this delay.
The SIR (Safe IKE Recovery) approach, where the non-rebooted peer queries the possibly rebooted peer about SA existence, was considered but the working group preferred QCD tokens because QCD allows the rebooted peer to proactively signal the crash rather than requiring a query-response round trip.
QCD tokens interact with IKEv2 Session Resumption (RFC 5723): QCD addresses the failure-detection gap (liveness checks may not yet have started or completed), while session resumption reduces re-establishment cost after detection. A client conforming to both stores the QCD token and the session resumption ticket; the combined exchange flow is shown in Section 7.
A supporting implementation receiving a QCD token MUST store it (or a digest thereof) along with the IKE SA.
A token maker MUST NOT send a valid QCD token in an unprotected message for an existing IKE SA. In load-balancing clusters, it MUST NOT be possible to trick one gateway into sending a valid token for an IKE SA active on another gateway.
A token taker SHOULD limit the rate of QCD_TOKEN verifications from a particular source to mitigate Denial-of-Service attacks. If excessive unknown-SPI IKE requests arrive at a token maker, the IKE module SHOULD revert to sending INVALID_IKE_SPI or ignoring such requests.
After rekeying an IKE SA, the initiator SHOULD send a new QCD_TOKEN in a separate INFORMATIONAL exchange immediately after the CREATE_CHILD_SA exchange if the initiator is a token maker. The responder may include the new token in the CREATE_CHILD_SA response.
For backup/standby gateway high-availability configurations, it is RECOMMENDED that the standby gateway be able to generate the same token as the active gateway (i.e., share the QCD_SECRET), so that crash recovery is available immediately upon failover.
If the QCD_TOKEN verifies successfully in an unprotected message, the receiver MUST silently discard the IKE SA and all associated child SAs. If the token cannot be validated, a response MUST NOT be sent.
Protocol ID in the QCD token notification MUST be 1 (IKE SA) and SPI Size MUST be zero, in conformance with RFC 5996 Section 3.10.
The QCD_SECRET MUST be protected from access by other parties; anyone gaining access to it will be able to delete all IKE SAs for that token maker.
The QCD Token Notify Message Type field MUST be 16419, the value assigned by IANA for QCD token notifications.
The token maker MUST be able to re-generate or retrieve the token from the IKE SPIs even after rebooting, and the generation method MUST make collisions between different SPI pairs highly unlikely.
The token taker MUST support at least four QCD_TOKEN notifications in a single unprotected packet, verifying the token against each; this supports periodic rollover of the QCD_SECRET across up to four generations of keys.
Token makers MUST generate unpredictable IKE SPIs using a cryptographically strong PRNG to prevent dictionary attacks that map SPI pairs to QCD tokens.
Tokens MUST be at least 16 octets and no more than 128 octets long to facilitate storage and transmission; tokens SHOULD be indistinguishable from random data.
When a QCD token becomes invalid (e.g., due to IP address change in the Section 5.2 method), the token maker MUST send the new token in a protected message under the existing IKE SA. A token taker MUST accept such gratuitous QCD_TOKEN notifications in protected exchanges.
When a token maker receives a protected IKE request with unknown IKE SPIs, it SHOULD generate a new token identical to the previous one and send it in an unprotected IKE message.
When a token taker receives a QCD token in an unprotected notification, it MUST verify the TOKEN_SECRET_DATA against the stored token. On successful verification, it MUST silently delete the associated IKE SA and all child SAs. The token taker MUST accept such tokens from any IP address and port combination.
A QCD token is an octet string sent in the IKE_AUTH exchange by a 'token maker' and stored by the 'token taker'. After a reboot, the token maker regenerates the same token and sends it in an unprotected notification, allowing the token taker to verify the crash and immediately delete the stale IKE SA.
IP-address-bound stateless token generation (Section 5.2): includes the token taker's IP address in the hash: TOKEN_SECRET_DATA = HASH(QCD_SECRET | SPI-I | SPI-R | IPaddr-T). This mitigates load-sharing cluster exposure but requires token replacement if the token taker's address changes.
Stateless token generation (Section 5.1): a 32-octet QCD_SECRET stored in non-volatile storage is combined with the IKE initiator and responder SPIs using a hash: TOKEN_SECRET_DATA = HASH(QCD_SECRET | SPI-I | SPI-R). Up to 3 previous generations of QCD_SECRET may be retained for key rollover.
The QCD_TOKEN notification is sent by the initiator in the first IKE_AUTH request and by the responder in the final IKE_AUTH response (the messages containing AUTH payloads). It is optional per peer; absence MUST NOT be taken as an indication that the peer does not support this standard.
IANA assigned notify message type value 16419 from the IKEv2 status types range (16406–40959) of the 'IKEv2 Notify Message Types' registry with the name QUICK_CRASH_DETECTION.
An attacker can enumerate QCD tokens by sending fake IKE requests and recording responses, building a dictionary of SPI-to-token mappings. Mitigations: the 2^128 SPI space makes full enumeration impractical; throttling limits dictionary construction speed; periodic QCD_SECRET rollover invalidates any accumulated dictionary.
Sending a QCD token in the clear for a still-valid IKE SA enables session teardown by any observer. In load-sharing clusters where a shared QCD_SECRET spans multiple gateways, any member might be tricked into revealing a valid token; either full IKE SPI synchronization across cluster members or the IP-address-bound method (Section 5.2) is required.
Tokens must be hard to guess; compromise of one token by an attacker MUST NOT enable guessing of other tokens from the same maker. The QCD_SECRET length and the use of a cryptographic hash are the primary controls. Token storage on the taker side must also be secured against unauthorized access.
The QCD token notification payload contains: Protocol ID (1 octet, MUST be 1), SPI Size (1 octet, MUST be 0), QCD Token Notify Message Type (2 octets, MUST be 16419), and TOKEN_SECRET_DATA (variable, 16–128 octets). The outer IKEv2 generic notification header fields (Next Payload, Critical bit, RESERVED, Payload Length) precede these fields.