Encrypted 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 Encrypted ESP Ping, including the Echo Request and Response. This protocol assesses network path reachability dynamically and can optionally specify a return path for echo Reply messages. Encrypted ESP Ping supports two modes of operation. In the first mode, peers that have negotiated USE_AGGFRAG can use the existing Congestion Control payload for echo requests and responses. In the second mode, peers negotiate ENCRYPTED_PING_SUPPORTED via IKEv2, which uses a new payload format defined in this document and commits the peer to responding. The approach for specifying a preferred return path is inspired by Return Path Specified LSP Ping . This document covers only Encrypted ESP Ping, typically used after an IKE negotiation, while specifies an unauthenticated ESP Ping to be used before IKE negotiation. This document updates by defining new AGGFRAG_PAYLOAD sub-types for ESP Echo Request and Response, which may be used under ENCRYPTED_PING_SUPPORTED negotiation without requiring USE_AGGFRAG.

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.

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. Encrypted ESP Echo addresses these challenges; Encrypted ESP Ping is one such tool.

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, ESP packets may encounter different filtering policies. This is typically due to broken packet filtering. Although this is less likely, it is still possible and can be difficult to diagnose. 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. Encrypted ESP Ping would greatly assist in diagnosing these scenarios. When IKEv2 operates over TCP to accommodate large post-quantum key exchanges while ESP may use a separate network path, Encrypted ESP Ping 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. Encrypted ESP Ping determines the reachability of each path independently.

IPsec Security Associations (SAs) are negotiated as a pair, consisting of two unidirectional SAs in one exchange. IKEv2 Section 2.9 allows installing multiple Child SAs with identical Traffic Selectors. When there are multiple paths, the Encrypted ESP Ping SHOULD support requesting an echo response via a specific return path IPsec SA. To request a return path, additional attributes are necessary. The initiator would propose a specific SPI as the preferred return path. A specific return path SPI is necessary when to probe a specific path among multiple possible SAs between same peer. Multiple paths can exist for various reasons, such as a primary and secondary path scenario. For example over a satellite link and over fiber, the receiving peer may have a policy to respond via the fiber path even when the request arrives via the satellite link. If the initiator requests a return path, the responder SHOULD try to respond via that IPsec SA. However, the final decision is up to the responder. If the responder decides to send the response via a different path than the requested return path, the initiator SHOULD detect this mismatch and report it, e.g., via a status code to the requesting, local, process.

AGGFRAG probes, whether sent at a constant or variable rate, can derive reachability information for the IPsec SA, similar to Encrypted ESP Ping. Since the probes are sent over an IPsec tunnel, the reachability information is reliable. IP Traffic Flow Security (IP-TFS) uses AGGFRAG at a constant rate; an Encrypted ESP Ping application may also send AGGFRAG payloads for manual diagnostic purposes.

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 Encrypted ESP Ping messages even when it does not math a local SPD. In the case of multiple SAs as mentioned above, IP tools would find it hard, if not impossible, to generate IP traffic to explore multiple paths specifically

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 Encrypted ESP Ping responses. Tracking the incoming traffic after the ping probe is sent allows applications to confirm the IPsec path is still viable.

After an IPsec SA negotiation, , an IPsec peer wishing to verify the viability of the current network path for ESP packets MAY initiate an ESP Echo Request. The ESP Echo Request MUST be sent as an ESP packet using the established SA, receiving the same level of protection as any other traffic on that SA. It SHOULD use an SPI value previously established, whether negotiated through IKEv2 or configured manually. The initiator sets the ESP Next Header field to AGGFRAG_PAYLOAD (144), as specified in . The ESP payload contains one of the echo request sub-type payloads defined in this document, optionally followed by padding. The receiving IPsec peer, having established ESP through IKE, MAY respond with an ESP Echo Response. The ESP Echo Response MUST be sent as an ESP packet using the corresponding SA and SPI. The responder also sets the ESP Next Header field to AGGFRAG_PAYLOAD (144), followed by the response sub-type payload. Two payload formats are defined: the existing Congestion Control payload (Section 4.1) and the new Encrypted ESP Ping payload (Section 4.2).

IP-TFS Congestion Control AGGFRAG_PAYLOAD Payload Format as specified in Section 6.1.2 can be used for Echo Request and response. When using this payload for Echo Request and response, IPv4 or IPv6 Data Block MUST NOT be concatenated, especially when USE_AGGFRAG is not successfully negotiated. This request does not support requesting a specific return path. [AA when using USE_AGGFRAG tunnel is negotiated, responder may concatenate AGGFRAG_PAYLOAD Congestion control probe] The Echo request and response payloads are not subject to IPsec Security Policy (SP), typically negotiated using IKEv2 and manually configured. End padding would be necessary if the tunnel is always sending fixed size ESP payload or to possibly detect path anomalies. When probing do not take the lack of a response alone as an indication of the unreachability of the return path using ESP echo; also consider the received bytes on the return path. IPsec has a unique advantage over other tunneling protocols when the return path shows incoming bytes, indicating that the path is partially functional. This is especially useful when used as a liveness check on busy paths. When there is no response, instead of concluding that the path is not viable and taking action, such as tearing down the IPsec connection, read the incoming bytes. This would help avoid tearing down busy paths due to the missing ESP echo response.

Control Payload Format

Sub-Type: ESP-ECHO-REQUEST or ESP-ECHO-RESPONSE
Return path (R): 1 bit flag, set when requesting a specific return path SPI
Reserved: 7 bits
Data Length: number of data octets following, length 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.
Return path: 32 bits, optional requested return path SPI, when R is set to one.
Data : Optional data that follows the Echo request.

The responder SHOULD copy the request message and MUST change the Sub-type to ESP-ECHO-RESPONSE. The SHOULD allows a responder to send a minimal response with a shorter or empty data section when resources are constrained.

On the initiator, the return path SPI in the request MUST be in the local SADB with the same peer as the destination. The responder should also validate the requested return path SPI. When the SPI does not match the initiator in the SPD, the responder MUST NOT respond via the requested SPI. This is specifically to avoid amplification or DDoS. However, the responder MAY respond using the SPI of the SA on which the request was received.

A peer negotiates support for Encrypted ESP Ping Mode 2 using the Notification Status Type `ENCRYPTED_PING_SUPPORTED` during the IKEv2 negotiation, in the IKE_AUTH exchange. When this has been negotiated, the peer has committed to responding to ESP Echo Requests on all ESP SAs between the two peers, and the initiator can reliably interpret a lack of response as path failure. When ENCRYPTED_PING_SUPPORTED has been negotiated, the peer SHOULD respond to ESP Echo Requests. Responding remains subject to local resource constraints, but the negotiation represents a commitment to support this functionality. A lack of response after a configurable timeout MAY be treated as an indication of path failure. For Mode 1 (USE_AGGFRAG), the commitment to respond is implicit in the USE_AGGFRAG negotiation itself.

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 return path is requested and the ESP Echo responder SHOULD make best effort to respond via this path, however, if local policies do not allow this respond via another SA. A typical implementation involves creating an ESP Echo socket, which allows setting an outgoing SPI during initialization,and matching source and destination address. Once socket is setup before sending any data, only write payload with optionally specifying return path.

The authors thank Valery Smyslov for his thorough review and comments.

The security considerations are similar to other unconnected request-reply protocols such as ICMP or ICMPv6 echo. The proposed ESP echo and response does not constitute an amplification attack because the ESP Echo Reply is almost same size as the ESP Echo Request. It can also be rate limited or filtered using ingress filtering per BCP 38