IKEv2 SA Lifetimes: Soft Rekey, Hard Expiry, Separate Reauth

Timers decide when a tunnel's keys are replaced, and the two thresholds involved are often read as one. They are not. A soft lifetime asks the peer to build a replacement while the current security association still carries traffic, and a hard lifetime is the deadline after which the old association is gone whether or not the replacement worked. Between them sits an overlap window that exists so packets do not fall into a gap.

What a lifetime actually bounds

An IPsec security association is a bundle of cryptographic state: keys for one direction, a security parameter index, an algorithm set and a selector. The lifetime bounds how long that state may be used, which limits how much traffic one key protects. It is a containment measure for the key, not a statement about how long a user session should last.

IKE control associations have their own keys and their own lifetimes, separate from the child associations that carry data. That is the first place people conflate two schedules.

Soft starts the replacement, hard ends the old state

When the soft threshold approaches, the peer initiates a replacement. Implementations usually fire early and randomize the moment so that a headend with hundreds of tunnels does not rekey all of them at once. In IKEv2 the replacement is a CREATE_CHILD_SA exchange carrying fresh nonces, plus a Diffie-Hellman exchange when perfect forward secrecy is configured. The result is a new pair of associations with new keys.

The overlap matters. For a short period the peer may hold the old and new associations, and a capture can show two sets of identifiers. That is the mechanism working, not a fault.

The hard threshold is unforgiving. If replacement has not completed by then, the old association must be retired and traffic protected only by it stops. Repeated failed rekeys that run all the way to hard expiry are the operational signal to investigate, because the tunnel is being propped up by a deadline each cycle.

Usage limits can fire before any clock

Time is not the only bound. Implementations can cap the bytes or packets protected by one key, and a busy tunnel will hit a usage limit long before a multi-hour timer. strongSwan exposes separate lifetime and margin settings for time, bytes and packets, which means the effective renewal point is whichever threshold arrives first, minus the configured margin.

When a tunnel renews far more often than its configured hours suggest, check the byte and packet limits before blaming the clock. A saturation link and an idle link with the same time settings will have visibly different rekey rates, and only one of them is following the timer.

Each peer enforces its own policy

IKEv2 does not negotiate a single lifetime that both peers must display identically. Each side applies its local policy and may initiate replacement when its own limit approaches, as described in RFC 7296 section 2.8. So a mismatch between two peers' configured hours is not automatically a defect, though wildly different values can produce churn if one side keeps replacing state the other just installed.

Coordination means compatible behaviour: overlapping windows long enough for the exchange, margins that leave room for retries, and monitoring that shows which side initiated each renewal.

Rekeying is not reauthentication

A rekey refreshes keys under the existing authenticated relationship. A reauthentication repeats the identity check, whether that is a certificate exchange or an EAP conversation. The two run on separate schedules and a successful rekey says nothing about whether the account should still have access.

That distinction matters for revocation. Disabling an account, revoking a certificate or terminating a session are access decisions that need explicit policy in the implementation; they do not follow from the SA timer, and a rekey can continue happily for an identity that has already been deprovisioned.

What to record per tunnel

Log which association triggered the renewal, the old and new identifiers, the threshold that fired and whether replacement completed inside the overlap. Those four fields make a rekey problem visible before it becomes an outage, and they distinguish a policy that is aggressive from one that is failing.

Keep the access-removal schedule next to that record rather than inside it. Cryptographic hygiene and identity policy are different controls, and a tunnel that rotates keys on time can still be holding a session nobody meant to keep.