Summary

  • RFC 7296 gives an IKE SA and its Child SAs separate identities and lifetimes. Rekeying the IKE SA creates new control keys, SPIs and message state; its surviving successor inherits the existing Child SAs rather than silently replacing them.
  • A Child-SA rekey is a different exchange with its own SPI lineage, selectors, algorithms, keys and collision rules. In a simultaneous rekey, the candidate associated with the lowest nonce is the redundant SA to close—the lowest nonce does not win.
  • A credible maintenance receipt joins three ledgers: control lineage, custody of every inherited or replaced Child SA, and running evidence from protected control messages and packets. “Rekey succeeded” is too coarse to prove either traffic-key rotation or service continuity.

At the point of handover, the tunnel can look uneventful. Packets still cross. The authenticated peers are unchanged. A dashboard may increment one rekey counter and return to green. Underneath, however, one protected relationship has been replaced while several others continue with their old keys and identifiers.

That is not an exception in IKEv2. It is part of the architecture. The IKE SA protects the exchanges by which peers maintain security state. Child SAs carry AH or ESP traffic. When the control association is rekeyed, the surviving new IKE SA becomes custodian of Child SAs created under the old one. Custody moves; the children need not be recreated.

Tero Kivinen is one of five named authors of RFC 7296, with Charlie Kaufman, Paul Hoffman, Yoav Nir and Pasi Eronen. His documented contribution is a useful route into this boundary, not a claim of sole authorship or present authority over implementations. The operational lesson is similarly bounded: a shared exchange can make succession interoperable without deciding every lifetime, authorization rule or packet outcome.

One protocol maintains two kinds of association

IKEv2 combines mutual authentication with the establishment and maintenance of security associations. The IKE SA is the protected control context. It carries requests and responses for creating, rekeying and deleting Child SAs. A Child SA is the one-way packet-protection association used by AH or ESP; paired Child SAs normally cover the two traffic directions.

The initial IKE_AUTH exchange often creates both the authenticated IKE SA and the first Child SA, which makes them easy to treat as one object. RFC 7296 refuses that shortcut. Failure to create the Child SA does not necessarily undo the completed IKE SA. A later Child creation failure likewise should not tear down the control association.

RFC 6023 makes the separation even more visible by defining an authenticated IKE SA without a Child SA. Such a control association can support liveness, NAT detection, protected notifications and later Child creation. That Experimental RFC belongs to Yoav Nir, Hannes Tschofenig, Hui Deng and Raj Singh, not to Kivinen; it is relevant here because it demonstrates that control existence and traffic carriage are independent states.

The first field in any rekey event must therefore be association type. Without it, the event cannot say whether control keys changed, traffic keys changed, both changed through separate operations, or neither transition reached usable state.

CREATE_CHILD_SA is a shared envelope, not one operation

After the initial exchanges, either endpoint can initiate CREATE_CHILD_SA. Despite its name, the exchange can create a new Child SA, rekey an existing Child SA, or rekey the IKE SA itself. The payloads and notifications determine which job is being attempted.

For a new Child SA, the initiator proposes security transforms, supplies a nonce, may include key-exchange material, and proposes initiator and responder traffic selectors. The responder can narrow those selectors. For a Child rekey, REKEY_SA identifies the inbound AH or ESP SA being replaced by protocol and SPI. The new Child should not unexpectedly change selectors or algorithms from the old Child.

For an IKE rekey, the exchange creates fresh initiator and responder IKE SPIs and fresh control key material. Message IDs and window state begin again on the new association; the old IKE SA retains its own counters while it finishes outstanding work. A common exchange shape provides collision-free vocabulary, but it does not erase the identity of the association being changed.

An implementation can refuse later CREATE_CHILD_SA requests. Local capacity and policy remain local. IANA registration tells peers what exchange, payload, transform and notification numbers mean; it does not prove that a peer supports a code point, accepted a proposal or completed the transition.

Rekey is make-before-break succession

RFC 7296 defines rekeying as creating a new SA and then deleting the old one. The old record is not edited in place. That ordering matters because the new association must become usable before the old protection context disappears.

When an IKE rekey succeeds, the new IKE SA inherits all Child SAs from the original. Future protected maintenance messages for those Children belong under the successor. The initiator then deletes the old IKE SA; its request to delete itself is the old association's final request.

The handover has at least four distinct times: successor created, successor accepted by the peer, Child custody attached to the successor, and predecessor deleted. A single timestamp called “rekey time” cannot show a gap or premature teardown. The safest record also names the first valid control exchange protected by the successor.

IKEv2 does not negotiate one universal lifetime. Each endpoint applies its own lifetime policy, and the shorter local policy usually initiates replacement. Timer, byte-volume, activity and implementation choices therefore belong to the local decision record. The protocol coordinates a handoff; it does not appoint one remote lifetime authority.

Inherited Child SAs keep their own cryptographic history

An inherited Child SA does not receive new traffic keys merely because its parent control association changed. Its inbound and outbound SPIs, traffic selectors, algorithms, key epoch, sequence and replay state, counters and lifetime continue until a separate Child operation changes them.

That makes the phrase “the VPN was rekeyed” dangerously ambiguous. If the evidence contains only new IKE SPIs and control algorithms, it proves a control-plane rotation. A claim that all packet-protection keys changed requires old and new Child SPI pairs, Child proposals and selected transforms, new Child key epochs, activation evidence and deletion of the replaced Child pair.

The standards split reinforces the point. RFC 8247 gives algorithm guidance for IKEv2 and explicitly does not update ESP packet-encryption algorithms. RFC 8221 separately addresses ESP and AH algorithms. Kivinen is among the authors of both documents, with different co-authors, but the relevant evidence is their scope: control crypto posture and data-plane crypto posture require separate columns.

This is also a lifecycle boundary. Upgrading IKE algorithms can leave long-lived Children on an older acceptable suite until their own timers or policy trigger replacement. Conversely, a Child can be rekeyed while the IKE SA continues. Operators should not compress these two clocks into one compliance date.

Authentication does not authorize every traffic selector

The IKE SA establishes peer identity evidence and protects negotiation. It does not grant the authenticated peer permission to claim any source and destination range. RFC 4301 places a Peer Authorization Database decision between peer authentication and acceptance of Child-SA traffic selectors.

A proposed TSi and TSr set may be narrowed to what local policy permits. That decision must survive control succession. If Child custody moves to a new IKE SA, the record should preserve which selector set was authorized, under which policy version, for which authenticated peer. Inheritance is not an opportunity to widen the protected traffic silently.

This separation prevents a common audit error. “Peer authenticated” answers who completed the identity step. “Child installed” says a pair of packet-protection associations exists. “Selectors authorized” says the asserted traffic range passed local policy. None of those statements can substitute for the other two.

Heng Lu's Minimum Initial Specification provides a useful lens. The protocol standardizes enough messages and identifiers for independently operated peers to coordinate. The future policy choice—whether to accept another Child, which selectors to allow, and when to rotate it—remains with the participant that bears the local consequence.

Transition evidence is asymmetric

The responder must be ready to accept packets on a newly created SA before it sends the successful response. The initiator can start sending after it processes that response. The responder cannot immediately know that the response arrived or that the initiator installed its outbound half.

During a Child rekey, the responder therefore continues to send on the old SA until it receives valid traffic on the other half of the new pair or an IKE request to close the old pair. If the initiator has no application packet queued, it can send a dummy ESP packet as a readiness signal.

That dummy packet is evidence of transition, not proof that an application transaction completed. Likewise, a successful create response is evidence of negotiation, not proof that return traffic, replay state, routing and the application path all worked. Running outcome requires its own observations.

Endpoints and selectors cannot serve as the unique Child identity. IKEv2 permits parallel Child SAs between the same endpoints with the same selectors, including for differentiated service. SPI pairs and lineage are indispensable. A dashboard grouped only by peer and subnet can merge a predecessor, a survivor and a redundant collision candidate into one misleading row.

Simultaneous Child rekey creates a temporary family

If both endpoints use similar lifetime policies, both can initiate a Child rekey at nearly the same time. Jitter lowers the probability but does not eliminate it. For a period, the peers can hold the old Child pair and two newly created pairs.

When several SAs are eligible to receive, inbound processing must accept packets on each valid candidate. The peers then compare the four nonces from the two rekey exchanges, octet by octet. RFC 7296's rule is easy to reverse in prose: the SA created by the exchange containing the lowest nonce is the redundant one to close. The lowest nonce loses; it does not select the survivor.

Deletion duties are divided. The creator of the surviving rekeyed pair deletes the replaced old pair. The creator of the redundant new pair deletes that redundant pair. The receipt must retain all candidates long enough to explain both deletions instead of rewriting history around the final survivor.

Packet loss can deliver a late rekey request after the target SA has already been replaced. CHILD_SA_NOT_FOUND can be a non-fatal consequence of the collision, not proof that no rekey happened. The event needs the request's target SPI, arrival order and known lineage before an alert can classify it.

IKE rekey collision decides who inherits the Children

Both peers can also rekey the IKE SA simultaneously. The temporary state then contains the old IKE SA and two new candidates, each initially associated with one exchange. The same nonce ordering closes the new IKE SA associated with the lowest nonce.

Only the surviving new IKE SA should inherit all Child SAs. That sentence turns collision resolution into a custody decision. It is not enough for both peers to agree that one IKE candidate lost. They must also agree on the complete Child set attached to the survivor before the old control association is removed.

An asymmetric race can arrive after one peer has started closing the old IKE SA. RFC 7296 uses TEMPORARY_FAILURE for a rekey request that reaches that state. After the old-SA delete arrives, the peer that observed the race can abandon its own attempt. A temporary error is therefore part of an orderly resolution, not automatically an outage.

The collision receipt should name both request/response exchanges, nonce set, redundant candidate, surviving successor, old-SA deletion and the inherited Child inventory observed by each peer. If the inventories disagree, the system has a custody failure even if the control handshake itself returned success.

Later multiple-key exchange keeps the same boundary

RFC 9370 updates RFC 7296 with multiple key exchanges and IKE_FOLLOWUP_KE. During IKE rekey or Child creation and rekey, more than one key exchange can contribute to derived key material. The extension also requires simultaneous rekey collisions to be resolved before follow-up exchanges continue.

RFC 9370 has a separate seven-author group and should not be attributed to Kivinen. Its relevance is architectural: as the negotiated chain becomes richer, a generic success flag becomes less informative. The receipt must say which extension was negotiated, which exchanges completed, which candidate survived and which association obtained the resulting keys.

An IANA code point makes the new vocabulary unambiguous. It does not establish deployment prevalence, product conformance or useful packet delivery. Those remain empirical questions for each implementation and path.

Kivinen's signature marks contribution, not control

The IETF Datatracker profile reviewed on 31 August 2026 lists Tero Kivinen as IPsecme chair, a Tools Team member, and a Security Area Directorate reviewer and secretary. It lists 16 RFCs and no active Internet-Drafts. Those are dated facts, not a permanent office or a certification of any product.

RFC 7296 is collective work by five named authors and the IETF process. RFC 8247 and RFC 8221 have their own co-author sets. RFC 6023 and RFC 9370 belong to other authors. Keeping those boundaries visible matters because technical traceability can otherwise be converted into institutional ownership.

Kivinen's contribution helps make the protocol's succession rules inspectable. It does not let an author choose an operator's lifetime, selector policy, algorithm deployment or incident conclusion. In Heng Lu's agency terms, the standards process supplies a narrowly scoped coordination instrument; the people operating each endpoint remain accountable for choices and evidence on their own control surface.

The same discipline applies to this article. It describes what the cited specifications say. It does not establish how often vendors implement the rules correctly, which installed products support later extensions, or whether a named network has rotated any key.

Use three receipts instead of one rekey counter

The control-lineage receipt begins with peer identity evidence, old and new IKE SPI pairs, proposals and selected algorithms, nonces, Message IDs, local lifetime trigger, collision candidates, successor decision, first protected successor exchange and old-SA deletion. It says who became the control parent.

The Child-custody receipt lists every inbound and outbound Child SPI, selector set, PAD/SPD authorization decision and policy version, mode, algorithms, key epoch, local lifetime, predecessor parent, successor parent, inherited-or-replaced status and deletion. It says what moved and what actually rotated.

The running-outcome receipt records packet acceptance on old and new Child pairs, replay and sequence behavior, drop reasons, dummy readiness packet if used, first useful bidirectional traffic, switchover interval and application-observed continuity. It says whether the protected path worked, without mistaking one packet for business completion.

Joined by SPI lineage and time, the three receipts support a defensible conclusion. A successful IKE rekey proves a new control association and, if verified, correct Child custody. It does not by itself prove Child-key rotation. A live Child flow proves packet continuity; it does not prove that future maintenance messages have the correct parent or that the old IKE SA can be safely deleted.

Sources