Summary

  • draft-ietf-ipsecme-encrypted-esp-ping-03 proposes an authenticated Echo Request and Response carried inside an established ESP Security Association, with an optional requested return-path SPI.
  • A matched response is narrow proof about the outbound SA and the actually observed inbound SA; it does not prove that ordinary traffic matched the same policy, followed the same path or reached its application.
  • After response support is negotiated, a timeout matters, but the draft itself requires a wider record: responder resources, authenticated incoming counters, requested-versus-actual return SA, retries and the operator decision.

The dashboard contains two green marks and one failed transaction. IKE is established. An Encrypted ESP Echo has crossed the network and returned. The application request, sent through what staff call the same tunnel, has timed out.

There is no contradiction. “The tunnel” is an operational shorthand wrapped around several independent decisions.

The current posted text is revision 03 of Encrypted ESP Echo. Its Datatracker record identifies an active IPsecME Working Group Internet-Draft posted on 4 May 2026. The document history ends at that posted revision. A separate submission record shows a revision 04 upload on 28 September, but only in uploaded state. It is not the current posted document. Revision 03 is work in progress, not an RFC, implementation report or deployment measurement.

The proposal begins after an IPsec SA exists. An initiator sends an Echo Request as an ESP packet on that established SA, using AGGFRAG_PAYLOAD as its next-header value. One mode reuses the congestion-control payload after USE_AGGFRAG; the other negotiates a new ENCRYPTED_PING_SUPPORTED notification in IKE_AUTH and uses a dedicated request/response payload. The live ESP AGGFRAG payload registry and IKEv2 status-notify registry do not yet contain the draft's proposed names. Its IANA values remain placeholders.

The dedicated payload carries a 16-bit request identifier, a 16-bit Echo sequence number, optional data and, when requested, a 32-bit return-path SPI. These fields make the experiment correlatable. They do not merge its layers. The Echo sequence number is not the ESP SA's packet sequence number. The requested SPI is not evidence that the responder used it. Optional data may be shortened or omitted when the responder is constrained.

That distinction matters because an IPsec SA is directional. RFC 4301 calls it a simplex connection; ordinary bidirectional protection requires a pair. The same architecture requires support for parallel SAs with the same selectors and leaves sender-side distribution among them to local implementation. A primary fibre route and a satellite backup can therefore present the same Traffic Selectors while holding different SPIs, paths, loss conditions and local policies.

Revision 03 lets the initiator ask for one return SPI. The initiator must first find it in its local SA database for the same peer. The responder then validates it against its own view. If policy does not permit that SPI, the responder must not use it and may answer through the SA on which the request arrived. Even where it is permitted, the draft says the responder should make a best effort and retains the final decision locally. The initiator should detect when the observed response SA differs from the requested one.

That mismatch is not bookkeeping trivia. A returned Echo can establish that the request traversed outbound SA A and that the answer arrived on inbound SA C. It cannot be presented as proof that inbound SA B—the requested fibre path—worked. Nor does a response on C erase the fact that a policy choice redirected the diagnostic. The safe receipt records both the request and the execution.

The same limit applies to a positive result. RFC 4303 explains how a received ESP packet is associated with an SAD entry using SPI and, where configured, addresses, then authenticated and checked. That is strong evidence for one protected packet. It is not a receipt from the inner application. RFC 4301 separately makes ordinary packet handling depend on Security Policy Database selectors and a local PROTECT, DISCARD or BYPASS decision.

The draft deliberately places Echo outside ordinary Security Policy matching and says a peer must accept it even when the gateway lacks a matching local SPD address. That makes the diagnostic useful. It also prevents a successful Echo from proving that a customer packet with particular inner addresses, ports and protocol would be selected, mapped to the same SA, forwarded after decapsulation or accepted by a service.

Packet size creates another difference. An Echo may be small, padded or intentionally shaped. A business packet may exceed a path limit, meet different fragmentation handling or carry a selector that chooses another SA. RFC 9347 defines AGGFRAG and the congestion-control payload that the draft reuses. It expressly does not make IP-TFS a reliable inner-IP delivery service or provide per-packet acknowledgements. A healthy diagnostic capsule cannot stand in for every traffic shape within the tunnel.

Now reverse the scene. The Echo times out.

After ENCRYPTED_PING_SUPPORTED is negotiated, revision 03 describes a commitment to answer requests on the peers' ESP SAs. That makes silence more informative than silence from a peer that never advertised support. Yet the next sentences preserve local resource constraints and say a timeout may be treated as an indication of failure. Elsewhere the draft warns not to infer return-path unreachability from silence alone or tear down the connection before checking incoming traffic.

The reason is unusually concrete. IPsec per-SA incoming packet and byte counters advance only after valid authenticated ESP packets are received. A responder's cryptographic subsystem may be overloaded and miss the Echo response while ordinary authenticated traffic continues. Increasing counters do not prove that the specific Echo was answered, that the opposite direction is healthy or that an application received data. They do prove that “the entire encrypted path is dead” is too broad a diagnosis.

Control-plane success has the same boundary. RFC 7296 establishes IKE and Child SAs, but the draft's use case includes IKE passing while ESP is filtered or follows another path. Separate Transports for IKE and ESP makes that distinction more explicit when IKE uses TCP while ESP remains elsewhere. The separate pre-IKE ESP Echo proposal is an unauthenticated mechanism and must not be mistaken for this post-IKE receipt.

The return-path idea has a useful precedent. RFC 7110 added a specified reply path to LSP Ping because an unreliable return path could create a false negative for a working forward LSP. Revision 03 borrows the idea, not every MPLS procedure. The shared lesson is that request reachability and reply reachability are separate questions, and a missing answer collapses them unless the operator records the return choice.

The defensible evidence chain is therefore explicit. Preserve the draft revision and IANA state; IKE capability exchange; peer identities; request time, ID and sequence; outbound SPI; requested return SPI; actual response SPI; integrity and replay verdict; counter deltas; responder resource state; ordinary packet selectors and SPD decision; inner and outer sizes; and an application acknowledgement. Then preserve the local action taken from those facts.

This is the practical application of Heng Lu's reality-layer distinction. A capability label, an installed SA, an emitted packet, an authenticated response and a customer outcome do not become interchangeable because a dashboard calls all of them “tunnel health”. Minimum Initial Specification keeps the common layer narrow: define enough wire behaviour for peers to create verifiable evidence, while leaving retry, demotion and teardown policy with the operator who bears the consequence. Running-Code Primacy places the final weight on observed operation rather than publication or negotiation alone.

Sources