Summary

  • draft-ietf-ipsecme-ikev2-reliable-transport-07 lets IKEv2 use TCP while ESP uses direct IP or UDP encapsulation, but a completed IKE exchange and a valid Child SA do not prove that the ESP path is reachable.
  • Operators need separate receipts for negotiation, per-transport NAT state, encrypted ESP response, application traffic and the fallback decision; authentication can remain sound while availability is absent.

The green light appears first on the wrong instrument.

An initiator opens TCP port 4500. The responder answers. A large key exchange crosses a reliable byte stream. The peers authenticate. They derive keys. A Child SA appears in both systems. Every control-plane panel looks respectable.

Then the first protected packet meets a firewall rule that never applied to TCP. Or it reaches a NAT whose UDP mapping does not exist. The tunnel has cryptographic state, but the application still has no road.

That is the practical importance of the active IPsecME working-group draft titled Separate Transports for IKE and ESP. Revision 07 is a Standards Track Internet-Draft in the IETF stream and has reached the Datatracker state “WG Consensus: Waiting for Write-Up”. It is not yet an RFC, and the frozen record contains no deployment or interoperability claim. Its value is narrower and more immediate: it refuses to let one transport’s success stand in for another transport’s reachability.

IKEv2 historically uses UDP. RFC 9329 added TCP encapsulation for IKE and ESP when UDP cannot get through. That solves an access problem, but carrying the protected data inside TCP brings its own performance costs. The pressure becomes sharper as post-quantum exchanges enlarge public keys and control messages. Revision 07 therefore proposes a split: keep IKE on TCP, where large exchanges are easier to carry, while allowing ESP to use direct IP or UDP encapsulation when that faster path is available.

The proposal uses an empty status notification called SEPARATE_TRANSPORTS. If both peers agree, later IKE exchanges remain on TCP. Child SAs are still created by IKEv2, but ESP is sent directly over IP or over UDP port 4500 when NAT traversal is needed. If the responder does not echo the capability, IKE and ESP remain together on TCP under RFC 9329.

This is a capability agreement, not a delivery receipt.

The distinction is easy to miss because the control exchange is unusually persuasive. It is authenticated. It produces fresh keys. It creates state with familiar names. It can even carry post-quantum material whose size was the reason TCP was selected. Yet none of those facts says that a middlebox will admit native ESP, preserve a UDP mapping, or apply the same policy it applied to the TCP connection.

The draft says this directly. When IKE_SA_INIT begins over UDP, the successful request and response implicitly demonstrate that UDP is reachable. When the same exchange begins over TCP, there is no implicit evidence that ESP traffic is reachable. After the Child SA is established, the initiator should verify the ESP path unless it already has equivalent evidence, such as incoming protected traffic.

That ordering matters. The Child SA can be cryptographically correct before its intended carriage is operational. Revision 07’s security section is careful on this point: failure to confirm ESP reachability does not by itself weaken IKEv2 authentication or the cryptographic protection of the negotiated Child SA. The failure is availability. Calling it an authentication failure would misdiagnose the system; calling the authenticated SA a working tunnel would overstate it.

NAT makes the separation physical. Middleboxes maintain state per transport. A live TCP connection for IKE supplies no keepalive benefit to the UDP mapping used by ESP. The peers must maintain that ESP mapping separately. A protected ESP packet arriving from a new address or port may update the ESP SAs created by the same IKE SA, but it must not silently rewrite the peer endpoint used by the IKE SA. Conversely, a protected IKE message can update the IKE endpoint without becoming evidence for the ESP endpoint.

One peer identity, two live paths, two state machines.

Revision 07 supplies an evidence procedure for the uncertain case. If NAT was detected, the initiator should probe UDP-encapsulated ESP on port 4500. If no NAT was detected, it should try direct ESP and, after a short delay without response, also try UDP encapsulation because some middleboxes reject IP traffic without a UDP or TCP header. The first responsive path wins. The draft compares this to Happy Eyeballs: preference without allowing preference to become a long outage.

Encrypted ESP Echo is offered as one way to perform the check. That is a strong receipt for a bounded question: protected ESP request and response traversed this path under this SA. It is not a universal application receipt. It does not prove that every traffic selector is correct, every packet size passes, the service behind the tunnel is healthy, or business traffic reached its final consumer. The evidence ladder still has another rung.

If ESP reachability cannot be confirmed, the draft does not leave the ambiguous Child SA in place and hope. The initiator must delete the current IKE SA and re-establish it over TCP without proposing separate transport for ESP. In effect, the system exchanges the preferred data path for the coupled RFC 9329 fallback. Local policy still has a decision to make: is ESP-over-TCP acceptable, with its performance and failure-mode tradeoffs, or should establishment stop?

That policy is not a cosmetic deployment knob. A security team may prize continuity through restrictive networks. A latency-sensitive operator may reject TCP carriage for bulk tunnel traffic. A regulated environment may require proof that a particular path was tested before protected workloads are admitted. The same protocol outcome can therefore lead to fallback, quarantine or abort depending on the service’s risk budget.

Mobility reopens the case. MOBIKE can move an IKE SA and its Child SAs to new addresses, but the previous ESP reachability result does not migrate as a fact about the new path. When ESP has been using TCP and the initiator detects an address change, revision 07 requires a fresh UDP reachability test before switching back. Where NAT exists, the new mapping learned for IKE is not automatically the mapping for ESP. The control session’s continuity must not launder stale data-plane evidence.

Session resumption has the same discipline. The draft says the separate-transport choice must not be stored in the resumption ticket because network conditions may change while a client is inactive. Resumption accelerates the security relationship; it does not freeze the old network. Transport must be renegotiated.

This is where the draft aligns with Heng Lu’s minimum-specification and reality-layer arguments. The protocol shares the smallest interoperable capability: the peers can separate transports. The later decision remains local because only the current endpoint can observe current NAT, filtering, response and service conditions. Symbolic state—“IKE established”, “Child SA installed”, “resumed”—does not outrank observed packet movement. Running code is not the presence of a configuration object. It is the protected exchange that actually crosses the selected road.

The useful operational record is therefore plural:

  1. what transport carried IKE_SA_INIT and later IKE exchanges;
  2. whether SEPARATE_TRANSPORTS was offered and accepted;
  3. whether NAT was detected and which ESP carriage was selected;
  4. whether the correct independent mapping and keepalive existed;
  5. which protected probe answered, from which address and under which SA;
  6. whether representative application traffic crossed after the probe;
  7. whether fallback, abort or continued operation was authorized;
  8. whether mobility or resumption forced a fresh verdict.

Compressing those records into “VPN up” creates the exact ambiguity that the draft is designed to remove.

Sources