How does an IKEv2 gateway decide its peer is dead, and why must it not treat an ICMP unreachable or an unprotected notify as proof?

## Why IPsec needs a liveness check An IKE endpoint may lose all its state at any time — a crash, a reboot, a failover to a box that never saw the SAs. Its peer still holds the IKE SA and the Child SAs and keeps encrypting packets towards it. Those packets fall into a **black hole**: they are sent, nothing complains in a trustworthy way, and the tunnel looks up on one side only. RFC 7296 section 2.4 therefore requires that an endpoint confirm the other side is alive when it has reason to doubt it. The RFC notes the mechanism is sometimes called **dead peer detection (DPD)**, although it really detects live peers. ## The mechanism: an empty INFORMATIONAL exchange 1. The gateway notices that **no cryptographically protected message** has arrived on the IKE SA or any of its Child SAs recently. Receiving traffic is itself the proof of life, so the case that matters is a gateway that has only been sending. 2. It sends an `INFORMATIONAL` request containing an IKE header and an Encrypted payload with **no payloads inside**. It is protected with the IKE SA's keys, like every message after setup. 3. The peer MUST respond — every IKE request gets a response, and an empty one is allowed. 4. If no response arrives, the sender **retransmits** the identical request. Retransmission intervals MUST increase exponentially so a congested path is not made worse. 5. Only when repeated attempts have gone unanswered for a timeout period does it conclude the peer has failed, then **discard the IKE SA and every Child SA** negotiated under it. ## What counts as proof | Evidence | May prompt a liveness check | May conclude the peer failed | |---|---|---| | ICMP unreachable or other routing information | yes | no | | Unprotected notify, e.g. about an unknown SPI | yes, rate-limited | no | | Fresh protected message on the IKE SA or a Child SA | — | proves it alive | | Repeated unanswered requests over a timeout period | — | yes | | Protected `INITIAL_CONTACT` on a new IKE SA from the same identity | — | yes, for the old SAs | The rule comes from IKE's design goal of surviving denial-of-service attacks: anything an off-path attacker can forge — ICMP, or a notify sent outside the IKE SA's protection — must never be enough to tear a tunnel down. RFC 7296 also says implementations MUST limit the rate at which they act on unprotected messages, and may ignore them when a protected message arrived recently. ## Timers belong to the implementation RFC 7296 deliberately leaves the number of retries and the timeouts unspecified, because they do not affect interoperability. Its only guidance is a suggestion — retransmit at least a dozen times over at least several minutes — plus the exponential backoff requirement. Any specific "probe every N seconds, give up after M tries" value is a local setting, not the protocol's rule. The same reasoning removes any need to negotiate an SA lifetime: if repeated requests go unacknowledged, the IKE SA and its Child SAs are deleted. The RFC adds a design constraint: because liveness of the IKE SA vouches for all its Child SAs, an implementation must stop sending over any SA if a failure prevents it receiving on all associated SAs, and Child SAs that can fail independently without the IKE SA being able to send a Delete must be negotiated under separate IKE SAs. ## After a reboot: INITIAL_CONTACT A rebooted peer that builds a new IKE SA can include **`INITIAL_CONTACT`** in its first `IKE_AUTH` message. It asserts that this IKE SA is the only one active between the two authenticated identities, so the recipient may delete older IKE SAs to that identity at once instead of waiting for a timeout. It MUST NOT be sent by an identity that may legitimately be connected more than once, such as a roaming user allowed on two devices. ## The IKEv1 equivalent IKEv1 had no built-in liveness exchange. Informational RFC 3706 described a traffic-based method using `R-U-THERE` and `R-U-THERE-ACK` notifies, sent only after an idle period with traffic to send; its idle interval, the "worry metric", was left to each implementation. IKEv1 itself is now deprecated by RFC 9395.