skip to content

An IKEv2 tunnel comes up cleanly, then drops and re-forms each time its Child SA is due for rekey; what in CREATE_CHILD_SA explains that?

level: seniorimportance: should knowfreq 20%

answer

  1. IKE_AUTH carries no KE payload
  2. a Child SA group appears later
  3. lifetimes are local, not negotiated
  4. new SA first, then delete the old
  5. a failed rekey closes the IKE SA

basics

~20 s

The first Child SA, built in IKE_AUTH, uses no Diffie-Hellman group; a Child SA group is first offered at the CREATE_CHILD_SA rekey. If the peers disagree that fails, RFC 7296 makes the endpoint close the IKE SA, and a fresh setup succeeds again.

solid answer

~50 s

In IKEv2 the first Child SA's keys come from `SK_d` and the `IKE_SA_INIT` nonces. `IKE_AUTH` carries no `KE` payload, so its SA proposal cannot hold a Diffie-Hellman transform other than NONE, and a group configured for Child SA forward secrecy is first used by the rekey: `HDR, SK {N(REKEY_SA), SA, Ni, [KEi,] TSi, TSr}`. If one gateway requires a group the other does not offer, the request draws `NO_PROPOSAL_CHOSEN`; if both accept groups but the `KEi` is in the wrong one, `INVALID_KE_PAYLOAD`. When rekeying fails as the SA expires, RFC 7296 says the endpoint MUST close the IKE SA and its Child SAs and MAY start new ones — and the new `IKE_AUTH` succeeds, because it never tests the group. Lifetimes are not negotiated: the end with the shorter one rekeys. Fix it by matching the Child SA proposals, group included, on both sides.

go deeper

for a junior

Recall that IPsec keys have lifetimes and that IKEv2 replaces an expiring SA through a CREATE_CHILD_SA exchange.

for a middle

Explain the create-then-delete order, the REKEY_SA notify, the optional KE payload for Child SAs, and why lifetimes are each side's own policy.

for a senior

Recognise a tunnel that flaps on a lifetime cycle as a rekey failure, find the Child SA group that IKE_AUTH never tested, and prove the fix by forcing a rekey.

for a principal

Decide where fresh Diffie-Hellman per Child SA is worth its cost, and make rekey and reauthentication intervals part of the agreed IKEv2 profile with every peer.

## How IKEv2 rekeys Keys should protect only a limited amount of time and data, so every IPsec security association has a lifetime. In IKEv2 (RFC 7296) an SA is **rekeyed by creating a new SA and then deleting the old one**, using the `CREATE_CHILD_SA` exchange inside the existing IKE SA. It has three forms: | Purpose | Request | KE payload | |---|---|---| | New Child SA | `SK {SA, Ni, [KEi,] TSi, TSr}` | optional | | Rekey a Child SA | `SK {N(REKEY_SA), SA, Ni, [KEi,] TSi, TSr}` | optional | | Rekey the IKE SA | `SK {SA, Ni, KEi}` | mandatory | The `REKEY_SA` notify names the SA being replaced by the SPI its sender expects in inbound packets. RFC 7296 says the replacement SHOULD NOT change traffic selectors or algorithms. Once the new pair is up and traffic has moved, the old one is removed with an `INFORMATIONAL` exchange carrying a Delete payload. ## Lifetimes are local policy Unlike IKEv1, which negotiated lifetimes, IKEv2 lets **each end enforce its own lifetime** and rekey when it sees fit. Consequences: - If a gateway uses a one-hour Child SA lifetime and its peer eight hours, the one-hour side always initiates the rekey. - Mismatched lifetimes are never a setup error and never appear in any notify. - Rekeying should be **proactive**: the new SA should exist before the old one becomes unusable, since an expired SA MUST NOT be used. - If both ends rekey at the same moment, both may succeed. RFC 7296 asks for jittered timing, requires accepting traffic on either SA while both exist, and resolves the duplicate by nonces: the SA created with the lowest of the four nonces, compared octet by octet, SHOULD be closed by the endpoint that created it. ## Why the first Child SA hides a group mismatch `CREATE_CHILD_SA` may carry a `KE` payload, giving the new Child SA keys from a fresh Diffie-Hellman exchange: `KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr)`. This is how IKEv2 offers forward secrecy per Child SA (what forward secrecy guarantees is a cryptography-foundations topic). `IKE_AUTH`, however, has no `KE` or nonce payloads, and RFC 7296 says its SA payloads cannot carry a Diffie-Hellman transform other than NONE. So: 1. Gateway A's Child SA policy requires a group; gateway B's lists none, or a different one. 2. `IKE_AUTH` creates the first Child SA without any group, so the mismatch is invisible — the tunnel works. 3. At the first rekey the group appears in the proposal for the first time. 4. The responder finds no matching proposal (`NO_PROPOSAL_CHOSEN`), or a proposal whose group differs from the `KEi` sent (`INVALID_KE_PAYLOAD`, naming its group). 5. As the old SA expires, the rekey has failed. ## What happens when a rekey fails RFC 7296 makes in-place rekeying optional for minimal implementations, but its fallback is strict: if an SA has expired or is about to and rekeying fails, the implementation **MUST close the IKE SA and any associated Child SAs, and MAY start new ones**. The new setup runs `IKE_SA_INIT` and `IKE_AUTH` again — which succeed, because `IKE_AUTH` still never tests the group. The tunnel therefore drops and re-forms on a cycle set by the shorter lifetime, losing packets each time, rather than staying down. A responder can also refuse with `NO_ADDITIONAL_SAS` if it accepts no further Child SAs on that IKE SA, which some minimal implementations do; the outcome is the same. ## Diagnosis and fix 1. Correlate the drops with the shorter Child SA lifetime on either gateway. 2. Find the `CREATE_CHILD_SA` carrying `REKEY_SA` and the notify that answered it. 3. Compare the Child SA proposals on both sides, **including the Diffie-Hellman group** that does not matter at setup. 4. Make them match, then force a rekey to prove it rather than waiting a full lifetime. ## IKE SA rekey versus reauthentication Rekeying the IKE SA (always with a `KE`) makes new keys and resets Message IDs, and the new IKE SA inherits all Child SAs — but it does **not** authenticate the peers again. Reauthentication is a fresh `IKE_SA_INIT` and `IKE_AUTH`, new Child SAs, then deletion of the old IKE SA. RFC 9370 extends both paths with up to seven additional key exchanges, carried in `IKE_FOLLOWUP_KE` when rekeying.

  • Does rekeying the IKEv2 IKE SA re-check the peers' credentials?
    No. RFC 7296 separates the two. Rekeying the IKE SA with `CREATE_CHILD_SA` must include a KE payload, so it yields fresh keys and resets Message IDs, but it carries no `AUTH` or EAP payloads. Reauthentication means a new `IKE_SA_INIT` and `IKE_AUTH`, new Child SAs, and then deleting the old IKE SA, which proves each peer still holds its long-term credentials.
  • What happens if both IKEv2 gateways start a Child SA rekey at the same moment?
    Both rekeys can succeed and leave redundant SAs. RFC 7296 asks for jittered rekey timing to make this rare and requires accepting traffic on either SA while both exist. The SA created with the lowest of the four nonces, compared octet by octet, SHOULD be closed by the endpoint that created it, and the initiator of the surviving SA deletes the replaced one.
  • What does RFC 9370 add to IKEv2 rekeying?
    RFC 9370 allows up to seven additional key exchanges alongside the main one, negotiated as transform types ADDKE1 to ADDKE7, so a post-quantum method can be combined with a classical group. During initial setup they run in IKE_INTERMEDIATE exchanges; when an IKE SA is rekeyed or more Child SAs are created, they run in the new IKE_FOLLOWUP_KE exchange.

saying these in an interview costs you the question

  • IKEv2 peers must agree on SA lifetimes or the tunnel will not establish.
  • A working first Child SA proves both sides' Child SA groups match.
  • Rekeying deletes the old SA first and then negotiates its replacement.
  • Rekeying the IKE SA re-authenticates both peers.
  • If a rekey fails, the old Child SA simply keeps running.