Internet Key Exchange Protocol Version 2 (IKEv2)
obsoletes
- rfc-5996 — Internet Key Exchange Protocol Version 2 (IKEv2)
updated by
- rfc-7427 — Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)
- rfc-7670 — Generic Raw Public-Key Support for IKEv2
- rfc-8247 — Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)
- rfc-8983 — Internet Key Exchange Protocol Version 2 (IKEv2) Notification Status Types for IPv4/IPv6 Coexistence
- rfc-9370 — Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)
- rfc-9827 — Renaming the Extended Sequence Numbers (ESN) Transform Type in the Internet Key Exchange Protocol Version 2 (IKEv2)
also
- std-79
Extracted elements (31)
Cookies are designed to be stateless at the responder: Cookie = VersionIDofSecret | Hash(Ni | IPi | SPIi | secret). This lets the responder validate a returning initiator without retaining per-initiator state, defending against CPU and state exhaustion DoS attacks from forged IP addresses.
IKEv2 eliminates explicit SA lifetime negotiation: if liveness detection (DPD) determines a peer is dead after repeated timeouts, the IKE SA and all Child SAs are simply deleted and rebuilt. This removes the complexity and race conditions inherent in synchronized lifetime counters.
On INVALID_KE_PAYLOAD the initiator must re-propose its full cryptographic suite list (not just reuse the previous one minus the bad group) because the rejection is unauthenticated; an active attacker could otherwise force negotiation of a weaker cipher suite.
IKEv1 has no 'higher-version capable' flag, so an active attacker can force two IKEv2-capable nodes into speaking IKEv1. Implementations that negotiate down to v1 when both peers support v2 SHOULD log the downgrade event.
All IKE_SA_INIT exchanges MUST complete before any other exchange type, then all IKE_AUTH exchanges MUST complete; only then may CREATE_CHILD_SA and INFORMATIONAL exchanges occur in any order.
All IKEv2 implementations MUST be able to send, receive, and process IKE messages up to 1280 octets long, and SHOULD be able to handle messages up to 3000 octets. Implementations MAY shorten messages by omitting certificates or crypto suite proposals to stay within limits.
An endpoint MUST NOT conclude that a peer has failed based on unauthenticated routing information (e.g., ICMP) or unprotected IKE Notify messages. Failure MUST be concluded only after repeated authenticated contact attempts time out or a cryptographically protected INITIAL_CONTACT arrives on a different IKE SA to the same identity.
An IKE endpoint MUST NOT exceed the peer's stated window size for transmitted requests; if the peer's window is N, the endpoint must wait for responses to all requests through X-N before sending request X. The endpoint MUST keep a copy of each outstanding request and a number of previous responses equal to its declared window size.
Both parties in the IKE_AUTH exchange MUST verify that all signatures and MACs are computed correctly. If a shared secret is used for authentication, the names in the ID payload MUST correspond to the key used to generate the AUTH payload.
If an endpoint receives an IKE message with a higher major version number, it MUST drop the message and SHOULD send an unauthenticated INVALID_MAJOR_VERSION Notify containing the highest version it supports. An endpoint supporting major versions n through m MUST support all versions in between.
If the critical flag is set in a payload header and the payload type is unrecognized, the message MUST be rejected with an UNSUPPORTED_CRITICAL_PAYLOAD Notify containing the one-octet payload type. An unrecognized payload type with the critical flag clear MUST be silently ignored.
In the unlikely event that Message IDs grow too large to fit in 32 bits, the IKE SA MUST be closed or rekeyed. Message IDs are reset to zero in the new IKE SA after rekeying.
On receiving INVALID_KE_PAYLOAD, the initiator MUST retry IKE_SA_INIT with the indicated Diffie-Hellman group and MUST re-propose its full set of acceptable cryptographic suites; omitting suites is prohibited because the rejection was unauthenticated and could be forged.
The initiator is responsible for retransmission; the responder MUST never retransmit a response unless it receives a retransmission of the request. A retransmission MUST be bitwise identical to the original request from the IKE header onward. Retransmission times MUST increase exponentially to avoid network flooding.
The KEi payload MUST be included in the CREATE_CHILD_SA request when rekeying an IKE SA, providing mandatory forward secrecy. Additionally, all PRFs used with IKEv2 MUST accept variable-sized keys.
The REKEY_SA notification MUST be included in a CREATE_CHILD_SA exchange whose purpose is to replace an existing ESP or AH SA. The SPI field in the Notify payload identifies the SA being rekeyed as seen in inbound packets.
The UDP payload of all IKE messages sent on port 4500 MUST begin with four zero bytes so that the receiver can distinguish IKE traffic from UDP-encapsulated ESP.
When a responder issues a COOKIE notification, the initiator MUST retry IKE_SA_INIT with the COOKIE notification as the first payload and all other payloads unchanged. Cookie data MUST be between 1 and 64 octets.
When deleting ESP or AH SAs, both directions of the SA pair MUST be closed. Delete payloads list inbound SPIs; the recipient MUST close the designated SAs. One MUST NOT send Delete payloads for both directions of a pair in a single message.
The Configuration (CP) payload enables an IKE initiator to request an internal IP address from the responder security gateway. Defined attributes include INTERNAL_IP4_ADDRESS, INTERNAL_IP4_DNS, INTERNAL_IP4_NBNS, INTERNAL_IP6_ADDRESS, and INTERNAL_IP6_DNS.
The Encrypted Payload (SK, type 46) wraps all subsequent message payloads after IKE_SA_INIT. Encryption uses SK_e and integrity uses SK_a, derived from SKEYSEED with separate keys per direction. Every IKE_AUTH, CREATE_CHILD_SA, and INFORMATIONAL message body is entirely encapsulated.
The Notify Payload (type 41) carries error or status notifications with fields: Protocol ID (1 octet), SPI Size (1 octet), Notify Message Type (2 octets), SPI (variable), and Notification Data (variable). Error types include UNSUPPORTED_CRITICAL_PAYLOAD (1), INVALID_KE_PAYLOAD (17), AUTHENTICATION_FAILED (24), and NO_PROPOSAL_CHOSEN (14).
The Security Association (SA) payload contains one or more Proposal substructures, each identifying a protocol (IKE=1, AH=2, ESP=3), an SPI, and one or more Transform substructures (Transform Type + Transform ID) for algorithm negotiation. An initiator proposes multiple suites in mix-and-match fashion; the responder selects exactly one.
The Traffic Selector (TS) payload (types 44/45 for TSi/TSr) contains one or more traffic selector entries each specifying TS Type, IP Protocol ID, Selector Length, Start/End Port, and Start/End IP Address, defining the address/port ranges protected by a Child SA.
IANA maintains IKEv2 parameter registries including: Exchange Types, IKE Payload Types, Transform Types (Encryption, PRF, Integrity, DH Group, ESN), Transform IDs per type, Notify Message Types, ID Types, Certificate Encoding Types, and Configuration Attribute Types. RFC 7296 updates all references from RFC 5996.
Identity confidentiality: initiator and responder identities (IDi, IDr) are carried inside the IKE_AUTH exchange, which is encrypted under keys derived from IKE_SA_INIT, hiding them from passive eavesdroppers. A man-in-the-middle who intercepts IKE_SA_INIT but cannot complete IKE_AUTH can still see the initiator's identity.
Implementations MUST rate-limit actions triggered by unprotected IKE messages and MUST NOT act on ICMP or unprotected Notify messages when deciding whether a peer has failed, as these can be trivially forged by an on-path attacker.
Traffic Selector Authorization: a responder MUST confirm that the Traffic Selectors proposed by the initiator are consistent with the responder's security policy before accepting a Child SA. Accepting overly broad TSes could silently bypass access controls.
IKE SA lifecycle: UNESTABLISHED → IKE_SA_INIT (crypto negotiation, DH, nonces) → IKE_AUTH (identity, AUTH payload, first Child SA) → ESTABLISHED. From ESTABLISHED: CREATE_CHILD_SA adds or rekeys Child SAs; INFORMATIONAL deletes SAs or checks liveness. DELETE payload or timeout transitions to CLOSED.
The Generic Payload Header is 4 octets: Next Payload type (1 octet), Critical flag + RESERVED (1 octet), Payload Length (2 octets, inclusive of header). All IKE payloads share this header as a common prefix.
The IKE Header is 28 octets: IKE_SA Initiator SPI (8 octets), IKE_SA Responder SPI (8 octets), Next Payload (1 octet), MjVer|MnVer (1 octet), Exchange Type (1 octet), Flags (1 octet), Message ID (4 octets), Length (4 octets).