Protocol Support for High Availability of IKEv2/IPsec
Extracted elements (29)
IPsec replay counter synchronization uses a delta increment rather than explicit counter values, because there may be numerous Child SAs under a single IKE SA and sending per-SA absolute values would be expensive. All Child SAs are incremented uniformly by the same delta, which constrains them to all use ESN or all not use ESN.
The two synchronization mechanisms (IKE Message ID and IPsec replay counter) are handled with separate notifications rather than a single combined one, providing flexibility for implementations to support either or both independently.
When it is difficult to estimate the correct replay counter increment, the document recommends skipping forward by a very large number (e.g., 2**30) followed by a rekey shortly afterwards, rather than risking counter reuse. This trades SA lifetime for guaranteed anti-replay correctness.
Session resumption (RFC 5723) and SA counter synchronization after failover are mutually exclusive: resumption is initiated by the peer detecting a need to re-establish, whereas counter synchronization is initiated by the newly active gateway. Both can coexist in the same implementation without interaction.
The IKEv2 Redirect mechanism (RFC 5685) and SA counter synchronization after failover are mutually exclusive in the failover scenario: Redirect requires the active member to detect shutdown ahead of time, which is not possible in an unplanned failover.
After receiving a valid IKEV2_MESSAGE_ID_SYNC response, the standby member MUST NOT process the same response again and MUST discard any additional responses.
After sending its 'receive' counter, the cluster member MUST reject (silently drop) any incoming IKE messages that are outside its declared window.
Both the IKEV2_MESSAGE_ID_SYNC request and response MUST NOT contain any additional payloads other than an optional IPSEC_REPLAY_COUNTER_SYNC notification in the request, and both MUST be sent with a Message ID value of zero.
During IKE_AUTH exchange, the responder MUST NOT assert support of a synchronization capability (IKEV2_MESSAGE_ID_SYNC_SUPPORTED or IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED) unless such support was also asserted by the initiator. Only mutually negotiated capabilities may be used.
For SAs using counter mode ciphers (CTR or GCM), the initial vector MUST NOT be repeated; in load-sharing cases, implementations MUST ensure no IV is ever reused across cluster members.
If IPSEC_REPLAY_COUNTER_SYNC is included in the same message as IKEV2_MESSAGE_ID_SYNC, the peer MUST process the Message ID notification first (which might cause the entire message to be dropped as a replay), then MUST increment the replay counters for all Child SAs by the requested amount.
IPsec peers MUST accept the long-term existence of multiple parallel SAs even when QoS mechanisms are not in use, because load-sharing clusters may need multiple outbound SAs with the same selectors.
M2 (the peer's reply counter) MUST be at least the higher of the received M1 and one more than the highest sender value previously received from the cluster. P2 MUST be the higher of received P1 and one more than the highest sender value used by the peer.
The IKE Message ID synchronization request value M1 MUST be chosen so that it is larger than any value known to have been used; it is RECOMMENDED to increment the known value at least by the size of the IKE sender window.
The nonce field in the IKEV2_MESSAGE_ID_SYNC notification MUST be returned unchanged in the response; a response MUST be silently dropped if the received nonce does not match the sent nonce.
The peer MUST respond to any synchronization message it receives from the newly active cluster member, provided that support for the capability used was previously negotiated.
The peer MUST silently drop any received IKE Message ID synchronization message if M1 is lower than or equal to the highest send counter value it has previously seen from the cluster, including prior synchronization messages.
The peer's capabilities with regard to the HA synchronization extension are part of the IKEv2 SA state and MUST be shared between cluster members so that a newly active member knows whether it can invoke synchronization.
To avoid DoS attacks from replayed out-of-window messages, the peer MUST NOT initiate counter synchronization for any particular IKE SA more than once per failover event.
Upon failover, the newly active member MUST increment its own outgoing IPsec replay counter to prevent traffic being dropped by the peer as replay. IPsec allows the replay counter to skip forward by any amount; where the increment is difficult to estimate, 2**30 is suggested.
IKEV2_MESSAGE_ID_SYNC_SUPPORTED (notify type 16420) is a zero-data notification exchanged in IKE_AUTH request/response to advertise support for IKE Message ID synchronization. SPI Size and Protocol ID are both set to 0.
IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED (notify type 16421) is a zero-data notification exchanged in IKE_AUTH request/response to advertise support for IPsec replay counter synchronization. SPI Size and Protocol ID are both set to 0.
The SA Counter Synchronization exchange is an IKEv2 Informational exchange initiated by the newly active cluster member after failover. It carries IKEV2_MESSAGE_ID_SYNC and/or IPSEC_REPLAY_COUNTER_SYNC notifications to re-align IKE Message ID counters and IPsec replay counters with the peer.
This document registers four new IKEv2 Notify Message Types in the IANA IKEv2 Notify Message Types registry: IKEV2_MESSAGE_ID_SYNC_SUPPORTED (16420), IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED (16421), IKEV2_MESSAGE_ID_SYNC (16422), and IPSEC_REPLAY_COUNTER_SYNC (16423).
Message ID synchronization messages are sent with Message ID zero, making them potentially vulnerable to replay attacks. Replay of a sync request is mitigated by requiring the cluster's Send counter to be strictly monotonically increasing; the peer silently drops requests that violate this. Replay of a sync response is mitigated by the nonce field that must match the outstanding request.
Out-of-window or potentially replayed messages could be used to trigger counter synchronization exchanges as a denial-of-service vector. This is mitigated by the rule that a peer MUST NOT initiate counter synchronization for a given IKE SA more than once per failover event.
Failover state transitions: (1) Active member crashes → standby detects failover and becomes active; (2) Newly active member sends SA Counter Synchronization exchange (Message ID zero) → peer authenticates and responds with reconciled counters; (3) Both sides update their Message ID and replay counters to the negotiated values and resume normal operation.
IKEV2_MESSAGE_ID_SYNC notification (type 16422) carries: Nonce Data (4 octets), EXPECTED_SEND_REQ_MESSAGE_ID (4 octets), and EXPECTED_RECV_REQ_MESSAGE_ID (4 octets), all in network byte order. Sent with Message ID zero.
IPSEC_REPLAY_COUNTER_SYNC notification (type 16423) carries a single 'Incoming IPsec SA delta value' field: 4 octets when ESN bit is 0, 8 octets when ESN bit is 1 for the Child SAs. All Child SAs of an IKE SA must uniformly use ESN or not.