Internet Key Exchange Protocol Version 2 (IKEv2)
obsoleted by
- rfc-7296 — Internet Key Exchange Protocol Version 2 (IKEv2)
obsoletes
- rfc-4306 — Internet Key Exchange (IKEv2) Protocol
- rfc-4718 — IKEv2 Clarifications and Implementation Guidelines
updated by
Extracted elements (31)
Cookie generation is designed to require zero saved responder state: the recommended formula is Hash(Ni | IPi | SPIi | <secret>), allowing the responder to recompute and verify on arrival of the second IKE_SA_INIT without storing per-client context, thereby defeating CPU and memory exhaustion attacks from forged-source flooding.
IKEv2 does not negotiate SA lifetimes in the protocol. Since dead-peer detection and the retransmission mechanism allow each endpoint to independently determine when a peer is unreachable, there is no architectural need to agree on a common SA lifetime; endpoints manage rekeying schedules locally.
NAT traversal uses NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP Notify payloads in IKE_SA_INIT to detect NAT presence. When a NAT is detected, both IKE and ESP/AH traffic is UDP-encapsulated on port 4500. Implementations MUST understand both UDP-encapsulated and non-encapsulated IPsec packets when receiving.
All IKE_SA_INIT exchanges MUST complete before any other exchange type, then all IKE_AUTH exchanges MUST complete; after that, CREATE_CHILD_SA and INFORMATIONAL exchanges may occur in any order.
All IKEv2 implementations MUST be able to send, receive, and process IKE messages up to 1280 octets long, and SHOULD support up to 3000 octets. All IKE messages sent on UDP port 4500 MUST begin with four zero bytes so receivers can distinguish them from IKE traffic on port 500.
An endpoint MUST NOT conclude peer failure based on ICMP messages or unprotected IKE Notify messages. Failure MUST only be concluded after repeated unanswered retransmissions or upon receiving a cryptographically protected INITIAL_CONTACT notification on a different IKE SA to the same authenticated identity.
An IKE endpoint MUST NOT exceed the peer's stated window size for transmitted requests. It MUST retain each outstanding request until the response arrives, and MUST retain a copy of prior responses equal to its declared window size to support retransmission. Retransmission times MUST increase exponentially.
Both parties in the IKE_AUTH exchange MUST verify that all signatures and MACs are computed correctly. If shared-secret authentication is used, the names in the ID payload MUST correspond to the key used to generate the AUTH payload.
If a payload's critical flag is set and the payload type is unrecognized, the message MUST be rejected with an UNSUPPORTED_CRITICAL_PAYLOAD Notify containing the one-octet payload type. Payloads in IKE response messages MUST NOT have the critical flag set.
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. RESERVED fields MUST be set to zero on transmission and ignored on receipt. Unrecognized payload types MUST be skipped if the critical flag is not set.
If the initiator guesses the wrong Diffie-Hellman group in IKE_SA_INIT, the responder replies with INVALID_KE_PAYLOAD and the initiator MUST retry with the corrected group, proposing its full suite list again to prevent an active attacker from forcing a weaker algorithm selection.
The initiator is solely responsible for retransmission on timeout; the responder MUST NOT retransmit a response unless it receives a retransmission of the corresponding request. A retransmission from the initiator MUST be bitwise identical to the original request starting from the IKE header.
The REKEY_SA notification MUST be included in a CREATE_CHILD_SA exchange that replaces an existing ESP or AH SA; it identifies the SA being rekeyed by the initiator's inbound SPI. When rekeying a Child SA, the new SA SHOULD NOT have different Traffic Selectors or algorithms than the old one.
When a responder detects a large number of half-open IKE SAs it SHOULD reply with a COOKIE Notify (data 1–64 octets). If the response includes a COOKIE, the initiator MUST retry IKE_SA_INIT with the cookie as the first payload and all other payloads unchanged.
When deleting an ESP or AH SA, both members of the SA pair MUST be closed. The recipient of a Delete payload MUST close the designated SAs. Delete payloads for both directions of an SA pair MUST NOT appear in a single message; only inbound-half SPIs are listed in the Delete payload.
The Authentication (AUTH) payload (type 39) carries the authentication method type (1 byte) and authentication data proving knowledge of the private key or shared secret corresponding to the sender's identity. It covers a signed octet string constructed from the first IKE message, the nonce from the peer, and the prf(SK_px, IDx') value.
The Configuration (CP) payload exchanges internal network configuration attributes during IKEv2, including INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS, INTERNAL_IP4_DNS, and related attributes, enabling a remote endpoint to request an IP address owned by the security gateway for the duration of the SA.
The CREATE_CHILD_SA exchange creates new Child SAs and rekeys existing IKE SAs and Child SAs via a single request/response pair. Either endpoint may initiate it. A KE payload MAY be included for additional Diffie-Hellman forward secrecy; when rekeying an IKE SA the KEi payload MUST be included.
The Encrypted payload (SK, type 46) wraps all inner payloads with encryption and integrity protection. It contains an initialization vector, ciphertext (inner payloads plus padding), padding length octet, and an integrity checksum. Every message after IKE_SA_INIT is wrapped entirely in an Encrypted payload.
The IKE_AUTH exchange is the second request/response pair, transmitting identities (IDi, IDr), proving knowledge of secrets via AUTH payloads, and establishing the first Child SA using SA, TSi, TSr payloads. All payloads after the header are encrypted and integrity-protected with keys derived in IKE_SA_INIT.
The IKE_SA_INIT exchange is the first request/response pair, negotiating cryptographic algorithms, exchanging nonces, and performing a Diffie-Hellman exchange. The initiator sends SAi1, KEi, and Ni; the responder replies with SAr1, KEr, Nr, and optionally CERTREQ. SKEYSEED and all IKE SA keys are derived from this exchange.
The INFORMATIONAL exchange carries Notification, Delete, and Configuration payloads for errors and housekeeping. It MUST ONLY occur after initial exchanges and is cryptographically protected. An empty INFORMATIONAL request (containing only the required Encrypted payload) functions as a liveness probe.
The Message ID is a 32-bit field in every IKE header used to match requests to responses and detect retransmissions. It is zero for IKE_SA_INIT (including retries caused by COOKIE or INVALID_KE_PAYLOAD) and incremented for each subsequent exchange. Message IDs are cryptographically protected and provide replay protection.
The SA payload encodes one or more Proposal substructures, each identifying a protocol (IKE=1, AH=2, ESP=3), an SPI, and one or more Transform substructures specifying algorithm types and IDs. The initiator may list multiple proposals in mix-and-match fashion; the responder selects exactly one complete proposal.
Traffic Selector payloads (TSi, TSr) specify IP address ranges, port ranges, and IP protocol numbers for traffic to be protected by a Child SA. The Traffic Selector type distinguishes IPv4 (TS_IPV4_ADDR_RANGE) and IPv6 (TS_IPV6_ADDR_RANGE) selectors. The responder may narrow but MUST NOT widen the initiator's proposed selectors.
Section 6 updates IANA registries for IKEv2 including: IKE Exchange Types, IKE Payload Types, Notify Message Types (error range 0–16383, status range 16384–65535), Transform Types and IDs for encryption/PRF/integrity/DH, Authentication Method values, Traffic Selector Types, and Configuration Attribute Types.
The IKE_SA_INIT exchange is unauthenticated; a man-in-the-middle who intercepts it can see the initiator's proposed algorithms and nonce. Initiator identity is revealed in IKE_AUTH only to an active attacker who can complete IKE_SA_INIT but not the authenticated IKE_AUTH exchange. Unprotected Notify messages MUST be rate-limited and not used as a basis for trust.
Traffic Selector authorization must be enforced: a security gateway MUST NOT permit an initiator to claim Traffic Selectors broader than those its authenticated identity is authorized to protect. Failure allows a compromised peer to intercept or inject traffic for IP addresses it does not own.
Dead Peer Detection: if no cryptographically protected message has been received recently on an IKE SA or any Child SA, the endpoint sends an empty INFORMATIONAL request. If repeated retransmissions go unanswered for the timeout period, the IKE SA and all associated Child SAs are discarded. Receipt of any fresh protected message resets the liveness timer.
Every payload is preceded by a 4-byte Generic Payload Header: 1-octet Next Payload type, 1-octet where bit 7 is the Critical flag and bits 0–6 are RESERVED, and 2-octet Payload Length inclusive of this header. The critical flag governs how unrecognized payload types are handled.
The IKE fixed header is 28 bytes: two 8-octet SPIs (Initiator SPI first, Responder SPI second), 1-octet Next Payload type, 1-octet major/minor version, 1-octet Exchange Type, 1-octet Flags (bits: Initiator, Version, Response), 4-octet Message ID, 4-octet total message Length.