ESP Echo Protocol

In response to the operational need for a data-plane failure-detection mechanism for IP Security (IPsec) Encapsulating Security Payload (ESP) from , this document introduces the ESP Echo Protocol, including Echo Request and Echo Reply messages. This protocol assesses network path reachability dynamically and can optionally specify a reply path for Echo Reply messages. Initiators can also send one-way probes without eliciting replies (e.g., for keepalives and NAT state maintenance) by clearing the Reply path flag. The approach for specifying a preferred reply path is inspired by Return Path Specified LSP Ping . This document defines both unencrypted and encrypted ESP Echo modes. The unencrypted mode is used outside the context of a negotiated ESP SA (for example, during MOBIKE address exploration or for credential-free diagnostics), using fixed SPI values (7 and 8) without encryption. The encrypted mode is used within the context of an established ESP SA using unique negotiated SPIs. In both modes, packets use Next Header 144 (AGGFRAG_PAYLOAD). This document updates by defining new AGGFRAG_PAYLOAD sub-types for ESP Echo Request and Reply, which operate independently of IP-TFS aggregation and do not require USE_AGGFRAG negotiation. This document also updates Section 2.1 of by defining the fixed SPI values 7 and 8 for unencrypted ESP Echo packets. This document does not specify a Path MTU discovery algorithm. It defines only the messaging layer, ESP Echo Request and Reply packets with a Data field, that an implementation can use as probe packets. How probes are sent and how the result is used are out of scope; see and for existing algorithms.

This document uses the following terms defined in : Encapsulating Security Payload (ESP), Security Association (SA), Security Policy Database (SPD). This document uses the following terms defined in : AGGFRAG tunnel, AGGFRAG_PAYLOAD. This document uses the term MOBIKE as defined in . In accordance with ICMP , messages sent to elicit an echo response are termed "Echo Request", and the corresponding reply messages are termed "Echo Reply".

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Diagnosing operational problems in IPsec can be challenging. The ESP Echo Protocol addresses these challenges.

Prior to establishing an ESP SA, a node can verify whether the intermediate network permits ESP packets by sending an unencrypted ESP Echo Request. Depending on whether an ESP Echo Reply is received, the node can choose to enable UDP encapsulation, use a different IP protocol, or select an alternative server or interface. When using MOBIKE , a node can verify ESP reachability to a new candidate address before migrating the session, avoiding blackholing traffic.

Network operators can troubleshoot path reachability and MTU without requiring VPN or cryptographic credentials by sending unencrypted ESP Echo Requests. This allows enterprise support personnel to debug connectivity for guests independently, and enables operators to report path issues to transit ISPs along the routing path.

An IPsec session typically employs ESP, using IP or IPv6 packets. ESP parameters are negotiated using IKEv2, with default IKEv2 messages exchanged over UDP port 500. In scenarios where ESP packets are not encapsulated in UDP (i.e., using the ESP protocol), successful IKE negotiation may occur, but ESP packets might fail to reach the peer due to differences in the packet path or filtering policies compared to IKE packets (e.g., UDP is allowed while ESP is filtered, typically due to misconfiguration). When using UDP encapsulation, intermediate middleboxes may apply different filtering policies to UDP-encapsulated ESP versus standard UDP traffic. Operational experience suggests that networks and some home routers that drop ESP packets are common enough to cause problems for general-purpose VPN applications that require reliable performance on the Internet. ESP Echo assists in diagnosing these scenarios. When IKEv2 operates over TCP to accommodate large post-quantum key exchanges while ESP may use a separate network path, ESP Echo can verify ESP reachability independently of the IKEv2 control channel .

When there are multiple paths created using multiple Child SAs with identical Traffic Selectors as specified in , there is a need to probe each Child SA, including the network path, independently from an IPsec peer. Each SA may traverse different network paths and may have different policies. ESP Echo determines the reachability of each path independently.

IPsec Security Associations (SAs) are negotiated as a pair of unidirectional SAs. When an initiator sends an ESP Echo Request to elicit a reply, it sets the Reply path flag (R=1) and explicitly specifies the target Reply path SPI on which the peer is to transmit the Echo Reply. This explicit specification enables probing across multi-SA deployments, such as multiple Child SAs with identical Traffic Selectors ( Section 2.9), per-CPU SAs, or primary and secondary paths. The responder SHOULD reply via the specified IPsec SA, though the final choice remains subject to local policy. If the responder sends the reply via a different path, the initiator can detect this mismatch and report it. Conversely, clearing the Reply path flag (R=0) allows initiators to send one-way ESP packets without eliciting replies, enabling lightweight keepalives, NAT and firewall pinhole maintenance, and cryptographic sequence advancement without return traffic.

Existing tools such as ICMP ping or traceroute assume IP connectivity. However, in IPsec gateway setups, the gateway itself may not have an IP address that matches the IPsec Security Policy Database (SPD). A peer MUST accept ESP Echo messages even when it does not match a local SPD. Standard IP diagnostic tools cannot target specific IPsec SAs when exploring multiple paths between the same endpoints.

Outgoing probes alone do not cover IPsec path health; incoming traffic must also be monitored. Incoming per-SA byte and packet counters maintained by IPsec are cryptographically verified: a counter can only increment if a valid authenticated ESP packet was received. These counters reliably indicate a viable path. This should be taken into account when probing IPsec paths. For example, when the crypto subsystem is overloaded, the responder may miss out on ESP Echo replies. Tracking the incoming traffic after the ping probe is sent allows applications to confirm the IPsec path is still viable.

IP Traffic Flow Security (IP-TFS) utilizes Next Header 144 (AGGFRAG_PAYLOAD) and defines a Congestion Control payload (sub-type 1) to measure round-trip time and packet loss within an active IP-TFS tunnel. The ESP Echo Protocol defined in this document also uses Next Header 144, defining dedicated Echo Request and Reply sub-types (sub-types [TBD2] and [TBD3]). The ESP Echo Protocol can be deployed in addition to active IP-TFS tunnels, or used independently across standard ESP SAs and unencrypted links. To determine which mechanism to use:

When either can be used: For basic link reachability checks and round-trip time measurement over an established, active IP-TFS tunnel (), either mechanism can be used. When using RFC 9347 Congestion Control payloads specifically as echo probes, they MUST be sent as independent ESP frames without concatenating other IPv4 or IPv6 data blocks.
When to use RFC 9347 Congestion Control: Use Congestion Control payloads when operating an active IP-TFS tunnel to provide real-time loss and delay feedback for IP-TFS rate adaptation algorithms.
When to use ESP Echo: Use the ESP Echo Protocol when verifying reachability, liveness, or probing Path MTU on standard (non-IP-TFS) ESP SAs; when probing specific return paths across multiple SAs; when sending unidirectional keepalives or maintaining NAT state without eliciting replies (R=0); or when probing unencrypted paths prior to SA negotiation (SPI 7 and 8).

Unlike normal IP-TFS operation where Congestion Control payloads are multiplexed directly into the aggregation stream, ESP Echo packets are always transmitted as standalone ESP control frames and MUST NOT be aggregated or fragmented with user data.

The ESP Echo Protocol operates in two modes:

Encrypted Mode: Used over established IPsec Security Associations (SAs) , where echo packets receive the same cryptographic protection as other traffic on the SA.
Unencrypted Mode: Used outside the context of a negotiated ESP SA using fixed SPI values 7 (Request) and 8 (Reply) without encryption (Section 5.5).

In both modes, an endpoint MAY send an ESP Echo Request to assess path reachability, probe path MTU, or maintain middlebox state. The ESP Next Header MUST be set to AGGFRAG_PAYLOAD (144) , carrying the ESP Echo payload format defined in Section 5.3, including optional Data. When an incoming request has the Reply path flag set (R=1), the receiving peer SHOULD reply on the specified SPI using an ESP packet with Next Header 144 (AGGFRAG_PAYLOAD) and the ESP Echo Reply payload. When R=0, the receiver MUST NOT reply.

Under standard inbound processing, decrypted ESP packets are verified against the Security Policy Database (SPD) traffic selectors associated with the SA. Because Next Header 144 (AGGFRAG_PAYLOAD) control messages---including all ESP Echo Request and Reply payloads defined in this document---are non-IP control messages without inner IP headers or traffic addresses, they MUST NOT be subjected to inbound SPD traffic selector verification. This exemption applies equally to Encrypted Mode (Section 5.3) and Unencrypted Mode (Section 5.5) ESP Echo payloads.

ESP Echo Request and Reply packets are standalone control messages. When transmitting ESP Echo packets, implementations MUST NOT aggregate or fragment ESP Echo payloads with IP-TFS data blocks or other AGGFRAG sub-types. Each ESP Echo packet MUST be carried in its own dedicated ESP packet with Next Header set to 144 (AGGFRAG_PAYLOAD).

The ESP Echo payload format consists of a fixed 12-octet header followed by optional Data:

ESP Echo Payload Format

Sub-Type: ECHO-REQUEST or ECHO-REPLY
Reply path (R): 1-bit flag. Set to 1 to request an Echo Reply; set to 0 when no reply is requested.
Reserved: 7 bits
Data Length: Length of the following Data field in octets (16 bits)
Identifier: A 16-bit request identifier. The identifier SHOULD be set to a unique value to distinguish between different ESP Request sessions. The responder copies it from the request.
Sequence number: A 16-bit field that increments with each echo request sent.
Reply path SPI: 32 bits. When R=1, specifies the target SPI for the reply, or 0 to let the responder reply on any SA to the peer. When R=0, the sender SHOULD set it to 0 and the receiver MUST ignore it.
Data: Zero or more octets of arbitrary data that follows the header. In an Echo Reply, this data is copied from the request up to the reply path MTU.

The ESP trailer MUST be constructed using the minimum allowable padding required by the cipher algorithm and . In unencrypted mode (), the padding length MUST NOT exceed 3 octets.

When R=1, the Reply path SPI field MUST specify the target SPI for the reply. For unencrypted requests (outer SPI 7), the Reply path SPI MUST be set to 8 (ESP-ECHO-REPLY) or 0, and the responder MUST send the Echo Reply with outer SPI 8 in either case. If an unencrypted request on SPI 7 has R=1 and the Reply path SPI is neither 8 nor 0, the responder MUST treat this as a protocol error and MUST NOT reply. For encrypted requests, the Reply path SPI identifies the SA on which the initiator expects to receive the Echo Reply. The initiator MUST set it to the SPI of an inbound SA that it has established with the responder, that is, an SA whose SPI the initiator allocated and which is present in its local SAD for that peer. An initiator that does not care which SA carries the reply sets R=1 and the Reply path SPI to 0; the responder then MAY send the Echo Reply on any established outbound SA to the initiator, preferring the SA paired with the one on which the request was received. For any other Reply path SPI value, the responder MUST validate the requested Reply path SPI against its own SAD: the SPI is acceptable only if it identifies an established outbound SA from the responder to the initiator. If it does, the responder SHOULD send the Echo Reply on that SA. Otherwise the responder MUST NOT send the reply on that SPI, to prevent amplification and reflection to unrelated peers, though it MAY reply on the SA paired with the one on which the request was received. When R=0, the responder MUST NOT reply, and any value in the Reply path SPI field MUST be ignored. When replying (R=1), the responder SHOULD copy the request message and MUST change the Sub-type to ECHO-REPLY; if the responder copies the request message, it MUST copy up to the reply path MTU.

An IPv4 or IPv6 node that desires to determine whether the path to a particular destination supports ESP packets outside the context of a negotiated ESP SA sends an unencrypted ESP Echo Request packet to that destination. In this mode, packets use the standard ESP packet format described in Section 2 of with the NULL encryption algorithm and no integrity protection (AUTH_NONE ):

The SPI field MUST be set to 7 (ESP-ECHO-REQUEST) for requests and 8 (ESP-ECHO-REPLY) for replies.
The Next Header field in the ESP trailer MUST be set to 144 (AGGFRAG_PAYLOAD).
Under NULL encryption and no integrity protection ( Section 2.7), the Initialization Vector (IV) and Integrity Check Value (ICV) fields are omitted (0 octets in length).
The ESP Sequence Number SHOULD be set to 0, and replay protection MUST NOT be enabled.
The ESP trailer contains 0 to 3 octets of Padding as needed to align the trailer to a 4-octet boundary , followed by a 1-octet Pad Length and the 1-octet Next Header (144).

The inner payload utilizes the same fixed format defined in Section 5.3. When requesting an unencrypted Echo Reply, the sender sets the Reply path flag (R=1) and sets the Reply path SPI field to 8 (ESP-ECHO-REPLY). To send a one-way unencrypted probe without eliciting a reply, the sender sets R=0, and the Reply path SPI field is ignored by the receiver. Senders MAY include arbitrary data in the Data field up to the path MTU to verify large packet transmission; when R=1, the responder SHOULD copy the request data up to the reply path MTU. When no reply is received, a sender MUST NOT conclude that the network path is unable to transmit ESP packets. The absence of a reply can be caused by any of the following:

The remote peer does not support the ESP Echo Protocol (or local policy chooses not to reply).
The network path does not support ESP packets (e.g., protocol 50 is dropped by intermediate middleboxes or firewalls).
Intermediate network nodes permit regular ESP traffic with operational negotiated SPIs, but drop ESP packets with reserved SPI values (7 or 8).

Senders SHOULD still attempt to establish standard ESP Security Associations if no alternative paths or protocols are available. Because unencrypted ESP Echo packets operate outside the context of a negotiated ESP SA, receivers MUST NOT require a dynamically negotiated Security Association to accept and process incoming packets with SPI values 7 and 8 (arriving over raw ESP protocol 50 or UDP/TCP encapsulation). Implementations MAY process these packets directly or MAY utilize static SADB entries configured with NULL encryption () and no authentication to maintain administrative, policy, or rate-limiting information for unencrypted probing.

There is no distinction between ESP Echo packets and other ESP packets for the purposes of processing encapsulation under (UDP encapsulation) and (TCP encapsulation). If an implementation is capable of receiving UDP or TCP encapsulated packets, it SHOULD accept encapsulated ESP packets with SPI values 7 and 8 on either, without the negotiation of an SA. When TCP encapsulation is used , path MTU discovery is ineffective. Because TCP segments and reassembles stream traffic, packets exceeding the path MTU are segmented rather than dropped by network bottlenecks. Consequently, over TCP encapsulation, ESP Echo functions as an SA reachability and liveness check rather than an MTU probe.

A peer announces support for the ESP Echo Protocol by including the Notification Status Type `ESP_ECHO_SUPPORTED` in the IKE_AUTH exchange during IKEv2 negotiation . When `ESP_ECHO_SUPPORTED` has been negotiated, the peer SHOULD reply to ESP Echo Requests received on all Child SAs established under the IKE SA. The initiator can reliably interpret the absence of a reply after a configurable timeout as an indication of path failure.

This document requests that IANA allocate two new values from the "Security Parameters Index (SPI)" registry: This document defines two new registrations for the IANA ESP PAYLOAD Sub-Types. This document defines one new registration for the IANA "IKEv2 Notify Message Status Types" .

When an explicit reply path is requested, the ESP Echo responder SHOULD make best effort to reply via this path; however, if local policies do not allow this, it MAY reply via another SA. A typical implementation can create an ESP Echo socket with an assigned outgoing SPI and matched source and destination addresses. Applications can then transmit ESP Echo Request payloads directly over the socket. For unencrypted probing using SPIs 7 and 8, packet capture tools on security gateways can filter specifically for these SPI values to debug transit reachability and MTU without decrypting user traffic.

The authors thank Tero Kivinen, Andrew McGregor, Valery Smyslov, and Paul Wouters for their thorough reviews and comments.

The security considerations are similar to other request-reply protocols such as ICMP. ESP Echo does not enable amplification attacks because an Echo Reply is never larger than the corresponding Echo Request. It can also be rate limited or filtered using ingress filtering per BCP 38 . To prevent downgrade attacks where security is compromised, IPsec nodes MUST NOT fall back to unencrypted plaintext communication if ESP Echo probing fails; nodes MAY attempt session migration (e.g., via MOBIKE) or switch to UDP encapsulation. In unencrypted mode, intermediate nodes might selectively permit or forge packets with SPI 7 or 8; however, within an established ESP SA, Encrypted Mode cryptographically authenticates all echo requests and replies.