Understanding how IKEv2 maintains secure VPN sessions requires a deep dive into Child Security Associations (Child SAs) and the rekeying mechanisms that refresh cryptographic material. For site owners, enterprise IT teams, and developers building or integrating VPN solutions, mastering the lifecycle of Child SAs and the precise behavior of rekey operations is essential for both security and reliability.

IKEv2 architecture recap: IKE SA vs Child SA

IKEv2 separates control-plane and data-plane security. The IKE Security Association (IKE SA) secures the management channel and authenticates peers, while one or more Child Security Associations (Child SAs) protect actual traffic (ESP or AH). The IKE SA holds long-lived keys (or keys refreshed periodically) and derives ephemeral keys for Child SAs. This separation enables flexible rekeying of data-plane SAs without tearing down the control plane.

Key material and key derivation

IKEv2 uses a suite of keys derived from a master secret using PRF-based key derivation. After IKE_SA_INIT and IKE_AUTH, both peers have shared secrets and nonces. These are used to derive:

  • SK_d – used as input to derive Child SA keying material
  • SK_ai / SK_ar – IKE SA integrity keys
  • SK_ei / SK_er – IKE SA encryption keys
  • SK_pi / SK_pr – used for authentication if needed

When a Child SA is created, SK_d and Child SA-specific nonces and optionally a new DH value are used to compute the Child SA keys: the ESP encryption and integrity keys (commonly labeled SK_ei / SK_er and SK_ai / SK_ar for the child context). The exact derivation follows RFC 4306 / RFC 5996 style PRF+ constructions and the transforms negotiated in the SA payload.

What exactly is a Child SA?

A Child SA defines:

  • Traffic selectors (which IP ranges and ports are protected)
  • Encryption and integrity algorithms
  • Lifetime parameters (time-based and byte-based)
  • SPIs (Security Parameter Indexes) for sender and receiver

Child SAs can be used for ESP tunnels or transport mode, and multiple Child SAs can coexist under one IKE SA (for example, multiple policies for different subnets). Each Child SA is independent for keys and lifetimes.

Rekeying fundamentals: why and when

Rekeying (a.k.a. SA refresh) is crucial for:

  • Limiting cryptographic exposure: rotating keys reduces the window for brute-force and cryptanalysis.
  • Adapting to policy: changing traffic selectors or crypto suites mid-connection.
  • Maintaining availability: recovering from soft errors or responding to reconfiguration without full tunnel teardown.

Triggers for rekeying include:

  • Time-based lifetime exhaustion (e.g., 1 hour default for many ESP SAs)
  • Byte-count lifetime (rekey after N bytes transferred)
  • Manual or operator-initiated rekey
  • Cryptographic policy change requested by one endpoint
  • IKE SA rekey (which may also force Child SA refresh)

Mechanics of Child SA rekeying

IKEv2 uses the CREATE_CHILD_SA request to create, rekey, or delete Child SAs. The exchange can be used for multiple purposes:

  • Initial Child SA creation (after IKE_AUTH)
  • Rekeying an existing Child SA (replace old SPI with new SPI and keys)
  • Obtaining additional Child SAs under the same IKE SA

A typical rekey flow is:

  • The initiator sends CREATE_CHILD_SA with an SA payload proposing new algorithms, a nonce, and optionally a fresh DH value (if PFS is desired).
  • The responder replies with SA, nonce, and possibly its DH value.
  • Both sides derive new Child SA keys using SK_d, the exchanged nonces, and the DH shared secret if present.
  • The responder includes the new SPI(s); after success, both sides install the new Child SA and begin using it for data traffic.

Notably, the fresh Child SA can be established concurrently with the old one to avoid packet loss during switchover. Implementations typically perform a soft rekey: maintain the old Child SA for a short overlap period until in-flight packets are drained and sequence numbers are clear.

Perfect Forward Secrecy (PFS) and optional DH

Using a new DH exchange during CREATE_CHILD_SA provides PFS for the Child SA keys—compromising long-term keys or the IKE SA keys will not reveal past Child SA traffic if DH was used for each rekey. RFCs allow rekeying without DH for efficiency, but this reduces forward secrecy.

Message contents and payload details

CREATE_CHILD_SA messages contain a series of payloads:

  • SA payload – contains proposed transforms (encryption, integrity, DH groups, lifetime values).
  • KE payload (optional) – contains a DH public value if PFS is used.
  • Nonce (Ni / Nr) – random values from initiator and responder, used in key derivation.
  • TSi / TSr – traffic selectors for the protected subnets; rekey can change selectors but mismatches may lead to policy intersection negotiation.
  • Encrypted payload(s) – further parameters are protected with IKE SA keys once the SA is established.

On successful negotiation the responder returns a SA payload that includes the new SPI(s). The requester then knows which SPI to use for sending encrypted traffic to the peer.

Sequence numbers and replay protection

ESP Child SAs use sequence numbers (and optionally extended sequence numbers, ESN) to prevent replays. During a rekey, both old and new SAs have their own sequence space. Implementations must ensure sequence numbers are not reused and must correctly manage anti-replay windows across the transition. Typically the old SA remains valid to receive late-arriving packets while new traffic is sent using the new SPI/keys.

Soft vs hard rekeying policies

Operators should understand two concepts:

  • Soft rekey – a proactive exchange started before lifetime expiry (e.g., at 80% of lifetime) to ensure a smooth transition.
  • Hard rekey – immediate rekey on expiry that may abruptly close the old SA; this risks packet loss if not coordinated with traffic flows.

Best practices call for soft rekeying with overlap and monitoring (byte counters and time) integrated into the VPN implementation.

Failure modes and recovery

Rekeying can fail for several reasons:

  • Negotiation of incompatible transforms (mismatched crypto proposals)
  • Traffic selector conflicts
  • Lost or delayed CREATE_CHILD_SA messages
  • Policy or NAT changes in the network

When a rekey fails, the usual behavior is:

  • Retry CREATE_CHILD_SA with adjusted proposals or increased retransmissions.
  • Fall back to previous Child SA until it expires or manual intervention occurs.
  • Use INFORMATIONAL messages for error reporting, including INVALID_KE, NO_PROPOSAL_CHOSEN, or DELETE payloads.

Implementation notes and interoperability

For developers integrating IKEv2 into products or automating VPN management, keep these points in mind:

  • Set clear lifetime policies: choose reasonable time and byte lifetimes that balance security and performance (e.g., 1h / 1GB is common but depends on requirements).
  • Support both DH and non-DH rekeys; make PFS configurable and enable it where security is paramount.
  • Ensure robust retransmission and timeout behavior for CREATE_CHILD_SA exchanges.
  • Implement SPI management carefully to avoid collisions and ensure clean garbage collection of expired SPIs.
  • Log rekey events with timestamps and reasons to aid debugging and forensic analysis.

StrongSwan, libreswan and other stacks

Different IKEv2 stacks offer configurable parameters for rekey behavior. For example, strongSwan and libreswan expose lifetime, rekey margin, and PFS toggles. When troubleshooting interoperability, compare SA proposals, DH groups, lifetimes, and traffic selectors closely. Packet captures using tools like Wireshark show the CREATE_CHILD_SA exchanges, SA payloads and KE/Nonce payloads—valuable for debugging.

Security considerations and best practices

When designing rekey strategies, follow these recommendations:

  • Prefer PFS for sensitive traffic to minimize the impact of long-term secret compromise.
  • Rotate keys proactively (soft rekey) instead of waiting for hard expiry to reduce reconnection disruption.
  • Use strong, modern cipher suites (AEAD ciphers like AES-GCM, ChaCha20-Poly1305) to simplify key management and integrity.
  • Monitor rekey failures and unusual rekey frequencies that might indicate an attack or misconfiguration.

Practical example: a rekey packet flow

Here’s a simplified packet-flow to illustrate a typical secure rekey:

  • Initiator calculates current lifetime usage and decides to rekey at 80%.
  • Initiator sends CREATE_CHILD_SA (I) with SA(initProposal), Ni, KEi (optional), TSi.
  • Responder evaluates the proposal, returns SA(responderChoice), Nr, KEr (if KE used), and new SPIr.
  • Both sides derive new Child SA keys via SK_d, Ni, Nr, and DH result if KE used.
  • Initiator receives responder’s message and completes the exchange; then begins sending traffic using new SPI and keys.
  • Responder keeps the old SA active for a short overlap period to accept late packets.

Conclusion

Child SA rekeying in IKEv2 is a carefully designed mechanism that allows VPNs to refresh encryption material without tearing down control-plane state. For administrators and developers, implementing robust rekey policies—favoring soft rekeys, supporting PFS, and handling failure cases gracefully—ensures both high availability and strong forward secrecy. Monitoring and logging of CREATE_CHILD_SA exchanges provide the visibility needed to diagnose issues and verify that rekey behavior aligns with security policies.

For more detailed guides, practical configuration examples, and resources tailored to enterprise and developer audiences, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.