Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks
Extracted elements (30)
The core vulnerability is that IKE_SA_INIT is cheap for the Initiator but causes the Responder to allocate a half-open SA (100–several thousand bytes) for each request. An attacker can exhaust Responder memory by flooding IKE_SA_INIT requests, and spoofed IP addresses defeat per-address rate limits.
The puzzle mechanism is loosely based on Bitcoin's proof-of-work technique. The task is to find N keys such that PRF(Ki, S) has at least ZBC trailing zero bits. Using four keys instead of one reduces the variance in solve time while keeping Responder verification cheap.
ZBC values 1–7 are explicitly excluded from valid difficulty levels because they create puzzles that are too easy to solve and provide negligible protection against attackers.
An Initiator that does not support puzzles will ignore the PUZZLE notification as an unrecognized status notification per RFC 7296 Section 3.10.1 and simply return the COOKIE. The Responder SHOULD allow some fraction of such legacy requests to be served so that non-puzzle-capable clients are not entirely locked out during an attack.
During an artificial delay imposed on a misbehaving peer, any retransmitted request messages received during the delay period MUST be silently discarded.
If a peer initiates an abusive amount of CREATE_CHILD_SA exchanges, the Responder SHOULD reply with TEMPORARY_FAILURE notifications to indicate the peer must slow down.
If a received IKE_AUTH message fails to decrypt or fails the ICV check, the Responder SHOULD still keep the computed SK_* keys so that an attacker cannot repeatedly force expensive key derivation on the same half-open SA.
If an IKE_SA_INIT response contains a PUZZLE notification but no COOKIE notification, the Initiator MUST ignore the received message and continue waiting, as the puzzle cannot be solved without the cookie.
If IKE fragmentation is used in the IKE_AUTH exchange, the PS payload MUST be present only in the first IKE Fragment message.
If the Responder requested an IKE_AUTH puzzle, it MUST silently discard all IKE_AUTH request messages that do not contain the PS payload, and MUST verify all four keys before any computationally intensive operation.
Implementations MUST use countermeasures (e.g., frequently rotating cookie secrets, timestamped cookies, or global counters in cookie generation) to completely eliminate or make insignificant any benefit an attacker gains from reusing puzzle solutions.
In diverse environments, it is RECOMMENDED that the Responder set the puzzle difficulty level (ZBC) to 0, meaning the Initiator may spend as much power as it can afford; a higher ZBC increases the chance of being served.
It is NOT RECOMMENDED to allow an IKEv2 window size greater than one when NULL Authentication has been used, since there is no way to decrease window size once increased and a larger window amplifies resource exhaustion.
Rate limiting for IPv4 SHOULD be done per IP address; for IPv6 it SHOULD be done per /48 or /64 prefix rather than per single IPv6 address, since ISPs assign address blocks to subscribers.
The PS (Puzzle Solution) payload MUST be placed outside the Encrypted payload in IKE_AUTH, so the Responder can verify the puzzle solution before performing the computationally expensive DH shared secret and SK_* key derivations.
The PUZZLE notification MUST always be accompanied by the COOKIE notification in IKE_SA_INIT responses, because the cookie content is used as input data when solving the puzzle.
The requested difficulty level for IKE_AUTH puzzles MUST NOT be 0; the Responder must always specify a concrete difficulty and must not allow the Initiator to self-select it.
The Responder MUST check all four returned keys when verifying a puzzle solution; the minimum trailing zero bit count across all four results is taken as the difficulty level achieved by the Initiator.
The Responder MUST NOT use puzzles in the IKE_AUTH exchange unless a puzzle was previously presented and solved in the preceding IKE_SA_INIT exchange.
When not under attack, the half-open SA timeout SHOULD be set high enough that the Initiator can send multiple retransmissions, minimizing the chance that transient network congestion causes IKE failure.
When processing "Hash and URL" Certificate Encoding, the Responder SHOULD read only the initial bytes to decode ASN.1 length, download no more than that many bytes, apply a configurable hard limit, and SHOULD provide the ability to disable or restrict this feature to trusted URLs.
When under attack, the Responder SHOULD prefer Initiators presenting a Session Resumption ticket (RFC 5723) but SHOULD NOT serve resumed Initiators exclusively, as this would lock out legitimate clients with no ticket.
The puzzle computation for IKE_AUTH differs from IKE_SA_INIT: S is the concatenation of Nr (Responder nonce, stripped of headers) and SPIr (Responder SPI from the IKE header). The task is otherwise identical: find four keys Ki such that PRF(Ki, Nr | SPIr) each has at least ZBC trailing zero bits.
The puzzle computation for IKE_SA_INIT uses the cookie as the unpredictable string S: find four distinct equal-sized keys Ki such that PRF(Ki, cookie) each has at least ZBC trailing zero bits. Cookie content only (not the Notify header) is used.
This document registers payload type 54 ("PS" — Puzzle Solution) in the IKEv2 Payload Types registry and notify message type 16434 ("PUZZLE") in the IKEv2 Notify Message Types — Status Types registry.
If the Initiator uses NULL Authentication (RFC 7619), its identity is never verified, allowing anonymous peers to mount post-SA DoS attacks (e.g., endless Child SA rekeying, IP address pool exhaustion). Responders permitting NULL Authentication must apply the post-SA countermeasures in Section 5.
If the Responder generates cookies as recommended in RFC 7296 Section 2.6, an attacker can reuse the same SPIi and Ni to obtain identical cookies and thereby reuse puzzle solutions. The Responder MUST use timestamps, counters, or frequent secret rotation to prevent reuse of puzzle solutions.
Puzzle difficulty must be balanced carefully: puzzles too easy fail to stop attackers; puzzles too hard cause unacceptable latency and power consumption for legitimate Initiators (especially battery-powered or mobile devices), which itself constitutes a DoS success. It is RECOMMENDED to dynamically adjust difficulty based on current Responder load.
The PS (Puzzle Solution) payload carries variable-length Puzzle Solution Data consisting of four equal-sized PRF keys. The key size equals (Payload Length - 4) / 4; for fixed-key PRFs the key size is that fixed size, otherwise 1 octet to preferred key length. Payload type is 54.
The PUZZLE notification payload carries: Protocol ID (1 octet, MUST be 0), SPI Size (1 octet, MUST be 0), Notify Message Type (2 octets, value 16434), PRF (2 octets, Transform ID of PRF algorithm to use), and Difficulty (1 octet, ZBC; 0 means Initiator chooses).