Summary

  • The 1 October revision of an IPSECME working-group Internet-Draft limits what a new TCP connection carrying a protected IKE message can change: that connection is used for the IKE SA alone and must not alter the source address or port of any associated ESP SA. The new wording explicitly identifies the new connection and its changed source IP address and/or port.
  • The same revision treats missing inbound ESP, where bidirectional traffic is expected, as a possible connectivity warning. Encrypted ESP ping remains an alternative check. A working-group draft requested for publication is not an RFC, and neither the symptom nor a working IKE exchange proves the fate of an ESP path.

An operator can see a successful IKEv2 exchange over TCP and still have no usable data tunnel. That is not a contradiction: IKE negotiates and maintains security associations, while ESP carries the protected traffic. The IPSECME proposal allows these flows to travel separately—TCP for IKE when large exchanges justify it, direct IP or UDP-encapsulated ESP where that path works. The benefit is to avoid forcing ESP onto TCP merely because the control exchange needs a reliable transport. The cost is a sharper evidentiary boundary: the control connection cannot stand in for evidence about the data path.

Draft 08, dated 1 October, makes one part of that boundary more exact. Its NAT section previously referred to a protected IKE message from a new source address or port. It now says the message arrives on a new TCP connection with a different source IP address and/or port. A host outside NAT uses that connection only for the IKE SA and must not change the source IP address or port for any Child ESP SA established under it. An integrity-valid ESP packet from a changed source has its own, separately scoped update rule. The distinction prevents a control-path event from silently rewriting the endpoint against which data packets are sent.

This is not the invention of separate transports in revision 08. The underlying proposal already describes a SEPARATE_TRANSPORTS notification. An initiator may start on UDP port 4500 and move later IKE exchanges to TCP after an echo from the responder, or start on TCP where the initial exchange itself is large. With separate transports negotiated, ESP uses direct IP or UDP encapsulation if available. If a TCP-start responder does not echo the notification, the draft requires both IKE and ESP over TCP under the existing RFC 9329 mechanism. Those modes establish context for the narrower new-connection wording; they are not new claims for this revision.

The second edit shifts the operational cue. Where traffic should flow in both directions, an absence of incoming ESP packets may signal a connectivity problem. The previous version pointed to encrypted ESP ping as a way to detect trouble; revision 08 also permits that explicit probe. Silence is a lead, not a verdict. An idle application, policy choice, asymmetric flow or measurement gap can look quiet. An operator needs expected-traffic context and, where appropriate, a path probe before declaring that a firewall or NAT broke ESP.

The broader draft already says a TCP IKE connection does not keep the UDP NAT mapping for ESP alive. Those mappings must be maintained independently. It also says a TCP-start IKE exchange supplies no implicit proof that ESP is reachable: after a Child SA is established, the initiator should verify the ESP path unless it has other evidence, and if reachability cannot be confirmed it must delete and re-establish the IKE SA without proposing separate ESP transport. This fallback is not an automatic promotion of a successful handshake into a healthy tunnel. It is a different mode selected after a failed or unconfirmed data-path test.

Datatracker lists the document as an active working-group Internet-Draft submitted for publication, with publication requested. Its notification value remains to be assigned in the draft text. None of this reports implementation adoption, an outage or an approved standard. The practical news is the precision of the boundary: new IKE control connectivity updates IKE state; ESP state and reachability need their own evidence.

Sources