Cloning the IKE Security Association in the Internet Key Exchange Protocol Version 2 (IKEv2)
Extracted elements (19)
A dedicated IKE SA is kept per VPN (rather than multiplexing Child SAs under one IKE SA) to simplify reachability tests and VPN maintenance. Cloning preserves this one-IKE-SA-per-VPN invariant while avoiding re-authentication.
Cloning is designed to complement MOBIKE (RFC 4555): after cloning an IKE SA, each new SA can be migrated to a different interface using MOBIKE. This avoids adding new protocol machinery and leverages the widely-deployed MOBIKE extension.
IKE SA cloning was motivated by the high cost (multiple round trips, user interaction for EAP-SIM/EAP-TLS, crypto overhead) of full IKEv2 re-authentication when establishing VPNs on multiple interfaces. Reusing an authenticated SA avoids this delay while enabling parallel VPNs.
The cloning mechanism reuses the CREATE_CHILD_SA/IKE SA rekey exchange with an additional CLONE_IKE_SA notification rather than introducing a new exchange type. This minimizes changes to existing IKEv2 implementations.
In a regular IKEv2 SA rekey (without CLONE_IKE_SA), the old SA is deleted after the rekey completes per RFC 7296 Section 2.8. The CLONE_IKE_SA notification explicitly overrides this behavior, causing both SAs to coexist. Implementations must distinguish cloned rekeys from standard rekeys.
When both VPN endpoints have multiple interfaces (n x m topology), care must be taken to avoid duplicate VPN creation by both ends simultaneously or conflicting MOBIKE moves. The protocol does not prescribe coordination; local policy governs which VPNs to clone and when.
If the initiator requests more cloned IKE SAs than the responder can handle (explicit or implicit limit), the responder SHOULD reject the request with NO_ADDITIONAL_SAS. This is a permanent condition; the initiator SHOULD NOT retry until existing SAs are deleted.
The CLONE_IKE_SA notification MUST appear only in the request message of the CREATE_CHILD_SA exchange concerning IKE SA rekey. If it appears in any other message, it MUST be ignored.
The CLONE_IKE_SA_SUPPORTED notification MUST be sent in the IKE_AUTH exchange (in the first IKE_AUTH message from the initiator and in the last IKE_AUTH message from the responder). If both peers send this notification, they may clone the IKE SA; otherwise the IKE SA MUST NOT be cloned.
When the IKE SA is cloned, peers MUST NOT transfer existing Child SAs created by the old IKE SA to the newly created IKE SA. All signaling for those Child SAs continues over the old IKE SA.
When the responder is temporarily unable to clone the IKE SA (e.g., insufficient resources or the SA is being deleted), the responder SHOULD reject the request with the TEMPORARY_FAILURE notification. The initiator MAY retry after waiting.
IKE SA cloning allows a peer to derive a new parallel IKE SA from an existing one using a modified IKE SA rekey procedure, without performing a new authentication exchange. The new SA coexists with the old SA rather than replacing it.
The CLONE_IKE_SA_SUPPORTED notification is exchanged in IKE_AUTH to advertise capability. The CLONE_IKE_SA notification is included by the initiator in a CREATE_CHILD_SA request for IKE SA rekey to signal that the old SA should not be deleted after the new one is created.
To set up VPNs on multiple interfaces without re-authentication, peers combine IKE SA cloning with MOBIKE: (1) establish initial IKE SA and VPN on Interface_0, (2) clone the IKE SA via CREATE_CHILD_SA with CLONE_IKE_SA, (3) create a Child SA for the second VPN under the new IKE SA, then (4) use MOBIKE UPDATE_SA_ADDRESSES to migrate that VPN to Interface_1.
IANA allocated two values in the 'IKEv2 Notify Message Types - Status Types' registry: 16432 for CLONE_IKE_SA_SUPPORTED and 16433 for CLONE_IKE_SA.
Accounting systems that track VPN service usage based on the liveliness of a single IKE SA may be circumvented if the original IKE SA is deleted while service continues on the cloned SA. Accounting implementations should track service from the first IKE SA establishment until the last associated IKE SA is removed.
Cloning an IKE SA may enable resource exhaustion: a single end user can populate multiple IKE SAs against a system that limits total SA count, or bypass per-SA Child SA limits. Implementations should enforce limits on cloned SAs per authenticated identity and evaluate Child SA counts across all IKE SAs belonging to a user.
When IKE SA cloning is used for load balancing, IKE SA state (including session keys) must be transferred between cluster nodes. Implementations must apply appropriate technical and administrative protections for this sensitive state data during transfer.
Both CLONE_IKE_SA_SUPPORTED and CLONE_IKE_SA use the standard IKEv2 Notify Payload format. Protocol ID is set to zero (1 octet), SPI Size is set to zero (1 octet), and Notify Message Type is 16432 for CLONE_IKE_SA_SUPPORTED or 16433 for CLONE_IKE_SA (2 octets).