IP Security Maintenance and Extensions A. Antony Internet-Draft S. Klassert Intended status: Standards Track secunet Expires: 5 January 2025 4 July 2024 Encrypted ESP Echo Protocol draft-antony-ipsecme-encrypted-esp-ping-01 Abstract This document defines an Encrypted ESP Echo Function, a novel mechanism designed to assess the reachability of an IP Security (IPsec) network path using Encapsulating Security Payload (ESP) packets. The primary objective of this function is to facilitate the detection of end-to-end path status dynamically in a reliable and efficient manner, only using encrypted ESP packets between the IPsec peers. The Encrypted Echo message can use existing congestion control payloads from RFC9347 or the message format specified here, with an optional preferred return path Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 5 January 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components Antony & Klassert Expires 5 January 2025 [Page 1] Internet-Draft Encrypted Esp Ping July 2024 extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. ESP Blocked or Filtered . . . . . . . . . . . . . . . . . 3 3.2. Probing Multiple Paths . . . . . . . . . . . . . . . . . 3 3.3. Probe Return Path . . . . . . . . . . . . . . . . . . . . 4 3.4. Manually Probing a Constant Rate on the AGGFRAG Tunnel . 4 3.5. Why Not Use Existing IP Tools . . . . . . . . . . . . . . 4 3.6. Also Track Incoming Traffic for livenss check . . . . . . 5 4. Protocol Specification . . . . . . . . . . . . . . . . . . . 5 4.1. Using Congestion Control Payload . . . . . . . . . . . . 5 4.2. Encrypted ESP Ping Payload Format . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Operational Considerations . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction In response to the operational need for a robust data-plane failure- detection mechanism for IP Security (IPsec) Encapsulating Security Payload (ESP), this document introduces Encrypted ESP Ping; Echo request and response. This protocol offers a solution for assessing network path reachability and can optionally specify a return path for echo reply messages. This document covers only Encrypted ESP Ping, while [I-D.colitti-ipsecme-esp-ping] specifies an unauthenticated ESP Ping. 1.1. Terminology This document uses the following terms defined in IKEv2 [RFC4301]: Encapsulating Security Payload (ESP), Security Association (SA), Security Policy Database (SPD). This document uses the following terms defined in IKEv2 [RFC9347]: constant rate on the AGGFRAG tunnel. Antony & Klassert Expires 5 January 2025 [Page 2] Internet-Draft Encrypted Esp Ping July 2024 This document uses the following terms defined in [RFC7110]: Return Path Specified LSP Ping 2. Requirements Language 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 [RFC2119] [RFC8174]when, and only when, they appear in all capitals, as shown here. 3. Use cases Diagnosing operational problems in IPsec can be challenging. The proposed Encrypted ESP echo function aims to address these challenges and provide a reliable diagnostic tool. 3.1. ESP Blocked or Filtered 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 protocol ESP, 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 a misconfiguration). Additionally, 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 hard to diagnose. Operational experience suggests that networks and some home routers that drop ESP packets are common enough to be a problem for general- purpose VPN applications desiring to work reliably on the Internet. Encrypted ESP Ping would be a great help to diagnose these scenarios. 3.2. Probing Multiple Paths When there are multiple paths created using multiple Child SAs with identical Traffic Selectors as specified in [RFC7296]or more explicitly in [I-D.ietf-ipsecme-multi-sa-performance], 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. The ESP Encrypted Ping would specifically help determine the reachability of each path independently. Antony & Klassert Expires 5 January 2025 [Page 3] Internet-Draft Encrypted Esp Ping July 2024 3.3. Probe Return Path IPsec Security Associations (SAs) are negotiated as a pair, consisting of two unidirectional SAs in one exchange. IKEv2 [RFC7296] Section 2.9 allows installing multiple Child SAs with identical Traffic Selectors. When there are multiple paths, the Encrypte 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 sender proposes a specific SPI as the preferred return path. The proposed return path SPI MUST be present on the local system with the same endpoint as the destination. A specific return path is necessary when the sender would like to probe a path, and there are multiple possible paths present. For example, if there is a path 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 sender requests a return path, the receiver SHOULD try to respond via that path, IPsec SA. However, the final decision is up to the receiver. If the receiver decides to send the response via a different path than the requested return path, the sender would notice the chosen path in the response. An example is Return Path Specified LSP ping specified in [RFC7110]. 3.4. Manually Probing a Constant Rate on the AGGFRAG Tunnel In IPsec setups, maintaining a constant traffic rate can help in disguising actual traffic patterns, providing enhanced security. The AGGFRAG tunnel enables constant rate probing to ensure consistent bandwidth usage, helping to mitigate the risk of traffic analysis by adversaries. This approach is particularly useful to discover possible bandwidth where maintaining a uniform traffic pattern is critical for security, using IP-TFS. 3.5. Why Not Use Existing IP Tools 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). Due to this, ESP messages must be used without relying on the SPD. Additionally, 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 Antony & Klassert Expires 5 January 2025 [Page 4] Internet-Draft Encrypted Esp Ping July 2024 3.6. Also Track Incoming Traffic for livenss check In addition to probing the outgoing paths, it is essential to monitor and account for the incoming traffic to ensure comprehensive network visibility of IPsec. Incoming SA traffic counters are unique to IPsec compared to other tunneling or native IP connections. In IPsec, the incoming 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. However, tracking the incoming traffic after the ping probe is sent would help applications to recognize the IPsec path is still viable. 4. Protocol Specification In a typical use case, after completing an IPsec SA negotiation, [RFC7296], 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 packet must be encrypted. If the SPIs are negotiated it SHOULD utilize an SPI value previously negotiated, e.g. negotiated through IKEv2. The sender sets the ESP Next Header value to AGGFRAG_PAYLOAD which has the value 144, as specified in [RFC9347]. This can be followed by different echo request sub-type payloads with a well defined format and optional empty data blocks following it. The receiving IPsec peer, having established ESP through IKE, MAY respond to an ESP Echo Response. When replying to an encrypted ESP Echo Request, the ESP Echo Response MUST be encrypted and utilize the corresponding SPI. The receiver also sets the ESP Next Header value to AGGFRAG_PAYLOAD: 144, followed by the requested sub-type AGGFRAG_PAYLOAD Payload starts from ESP Next Header value: 144 and followed one of the two Request payloads specified. 4.1. Using Congestion Control Payload IP-TFS Congestion Control AGGFRAG_PAYLOAD Payload Format as specified in [RFC9347] 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 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] Antony & Klassert Expires 5 January 2025 [Page 5] Internet-Draft Encrypted Esp Ping July 2024 The Echo request and response payloads are not subject to IPsec Security Policy(SP), typically negotiated using IKEv2 a nd manually configured. End padding padding would be necessary of the the tunnel is always sending fixed size ESP payload or 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. 4.2. Encrypted ESP Ping Payload Format 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-type (2) | Reserved |R|Data Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Identifier (ID)|Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Return path SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+-+-+- Figure 1: Congestion Control Payload Format * Sub-Type: ESP-ECHO-REQUEST or ESP-ECHO-RESPONSE * Reserved: 7 bits * Return path: 1 bit flag, set when requesting a specific return path * Data Length : number of data octets following, length 16 bits * Identifier : A 16-bit request identifier. The identifier might be set to a unique value to distinguish between different ESP Request sessions. Response copy it from the request * Sequence number: A 16-bit field that increments with each echo request sent. Antony & Klassert Expires 5 January 2025 [Page 6] Internet-Draft Encrypted Esp Ping July 2024 * Return path: 32 bits, optional requested return path SPI, when R is set. * Data : Optional data that follows the Echo request. 5. Security Considerations 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. Further this can be rate limited or filtered using ingress filtering per BCP 38 [RFC2827] 6. IANA Considerations This document updates [RFC9347] to allow ESP Echo Request and ESP Echo Response without a successful negotiation of USE_AGGFRAG. This document defines two new registrations for the IANA ESP [AGGFRAG] PAYLOAD Sub-Types. Value ESP AGGFRAG_PAYLOAD Sub-Type Reference ----- ------------------------------ --------------- 3 ESP-ECHO-REQUEST [this document] 4 ESP-ECHO-RESPONSE [this document] Figure 2 7. Operational Considerations 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 would be a ESP Echo socket. And the socket would allow to set outgoing SPI at creation, optionally matching source and destination address. Once this set before sending any data. Userspcace can only write payload 8. References 8.1. Normative References [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . Antony & Klassert Expires 5 January 2025 [Page 7] Internet-Draft Encrypted Esp Ping July 2024 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . [RFC9347] Hopps, C., "Aggregation and Fragmentation Mode for Encapsulating Security Payload (ESP) and Its Use for IP Traffic Flow Security (IP-TFS)", RFC 9347, DOI 10.17487/RFC9347, January 2023, . [I-D.ietf-ipsecme-multi-sa-performance] Antony, A., Brunner, T., Klassert, S., and P. Wouters, "IKEv2 support for per-resource Child SAs", Work in Progress, Internet-Draft, draft-ietf-ipsecme-multi-sa- performance-09, 2 May 2024, . [I-D.colitti-ipsecme-esp-ping] Colitti, L., Linkova, J., and M. Richardson, "ESP Echo Protocol", Work in Progress, Internet-Draft, draft- colitti-ipsecme-esp-ping-02, 4 April 2024, . [AGGFRAG] IANA, "ESP AGGFRAG_PAYLOAD Sub-Types", . 8.2. Informative References Antony & Klassert Expires 5 January 2025 [Page 8] Internet-Draft Encrypted Esp Ping July 2024 [RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord, "Return Path Specified Label Switched Path (LSP) Ping", RFC 7110, DOI 10.17487/RFC7110, January 2014, . Acknowledgments ACKs TBD Authors' Addresses Antony Antony secunet Security Networks AG Email: antony.antony@secunet.com Steffen Klassert secunet Security Networks AG Email: steffen.klassert@secunet.com Antony & Klassert Expires 5 January 2025 [Page 9]