Path Aware Networking RG M. Welzl Internet-Draft University of Oslo Intended status: Informational 21 October 2024 Expires: 24 April 2025 On-Path Proxy Discovery draft-welzl-panrg-oppd-00 Abstract This document surveys possibilities for On-Path Proxy Discovery (OPPD). It is meant to help the conversation in a planned side meeting at IETF-121 in Dublin (see the github page linked under "About This Document" for coordinates). The draft title indicates PANRG as a target of this document just because we thought that PANRG should be informed. What a suitable target is, and if this is even the right type of document, should all be discussed at the side meeting. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://mwelzl.github.io/oppd/draft-welzl-panrg-oppd.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-welzl-panrg-oppd/. Discussion of this document takes place on the Path Aware Networking RG Research Group mailing list (mailto:panrg@irtf.org), which is archived at https://mailarchive.ietf.org/arch/browse/panrg. Subscribe at https://www.ietf.org/mailman/listinfo/panrg/. Source for this draft and an issue tracker can be found at https://github.com/mwelzl/oppd. 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/. Welzl Expires 24 April 2025 [Page 1] Internet-Draft On-Path Proxy Discovery October 2024 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 24 April 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. General assumptions . . . . . . . . . . . . . . . . . . . . . 4 5. A survey of possibilities . . . . . . . . . . . . . . . . . . 4 5.1. Endpoint to proxy . . . . . . . . . . . . . . . . . . . . 4 5.1.1. Special packet of base connection . . . . . . . . . . 4 5.1.2. Header options . . . . . . . . . . . . . . . . . . . 5 5.2. Proxy to endpoint . . . . . . . . . . . . . . . . . . . . 5 5.2.1. Special packet of base connection . . . . . . . . . . 5 5.2.2. Header options . . . . . . . . . . . . . . . . . . . 5 6. A survey of open issues . . . . . . . . . . . . . . . . . . . 5 7. Examined material that was not included . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 10.2. Informative References . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 Welzl Expires 24 April 2025 [Page 2] Internet-Draft On-Path Proxy Discovery October 2024 1. Introduction Proxies can carry out functions that improve the performance of an end-to-end connection. These function can be quite diverse, ranging from minimal help (e.g. just offering information) to more significant interference, e.g. splitting an end-to-end connection in half, for reliability, congestion control or both. It is commonly desirable for such proxies to be located on the path(s) that a connection already traverses, rather than using a tunneling or forwarding approach to enforce a path. This is naturally the case for transparent "Performance Enhancing Proxies" (PEPs) that have been implemented for TCP, but the transparent nature of such proxies has caused a number of problems in the past. Non- transparent proxies leave the choice of utilizing and configuring a performance enhancing function to end systems -- and such a choice requires a means to detect the proxy and explicitly communicate with it. With QUIC, the encryption of packet headers necessitates using non-transparent instead of transparent proxies, and research works such as the Sidekick [Sidekick] and Secure Middlebox-Assisted QUIC (SMAQ) [SMAQ] have shown that this is both possible and beneficial. There are various ways in which On-Path Proxy Discovery (OPPD) can work, and they differ from the ways in which end systems learn about proxies that are not necessarily on-path. This document surveys some possibilities that are available for OPPD. 2. Conventions and Definitions 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. Terminology * Base connection: an end-to-end connection between two endpoints on which an on-path proxy is expected to carry out a performance- improving function. * Endpoint: an entity that communicates with one or more other endpoints using a specific base connection. It is locally identified by the base connection's 5-tuple of IP address pair, protocol and port numbers. Welzl Expires 24 April 2025 [Page 3] Internet-Draft On-Path Proxy Discovery October 2024 4. General assumptions * On-path proxies are expected to carry out functions in relation to a base connection. Thus, they must be on the same path, which, given the prevalence of functions such as Equal-Cost Multi-Path routing (ECMP) [RFC2992], means that communication with them must use the same 5-tuple as the base connection. * Endpoint initiation: OPPD must be initiated by an endpoint. First, in the presence of Network Address Translators (NATs) [RFC2663], this is the only way to ensure that communication with the proxy uses the same IP addresses and port numbers as the base connection. Second, in this way, endpoints can execute some kind of flow control to avoid the reception of many unsolicited announcements. * Proxies must somehow prove that they are on-path, akin to the way it is done with several ICMP messages that include the first 64 bits of the original packet that evoked them [RFC792]. Naturally, the part of the original packet that is to be returned must not be too easy to guess--e.g. a nonce of a certain minimum length. This establishes a certain minimal level of trust, since on-path devices are in the position to do whatever they want with a connection's packets anyway -- for example discard, rate-limit or duplicate them. 5. A survey of possibilities Please insert your ideas below -- or add a description of a scheme that already exists. 5.1. Endpoint to proxy 5.1.1. Special packet of base connection Sidekick [Sidekick] endpoints signal proxy support by sending a distinguished packet containing a 128-byte sidekick-request marker over the base connection's 5-tuple. Such inline signaling could confuse receiving endpoints, but sidekicks target protocols such as QUIC that discard cryptographically unauthenticated data anyway. Secure Middlebox-Assisted QUIC [SMAQ] leaves the design of a proxy discovery solution as future work, but also suggests to multiplex the necessary signaling over the same 5-tuple as the base connection. Welzl Expires 24 April 2025 [Page 4] Internet-Draft On-Path Proxy Discovery October 2024 5.1.2. Header options An endpoint could use a newly defined TCP option or UDP option [I-D.ietf-tsvwg-udp-options] to signal proxy support. Such an option could be specified to be ignored by the receiving endpoint, and receiving endpoints that are not upgraded to support the option should ignore it anyway. In case of QUIC, for example, the QUIC implementation at the receiving endpoint would not even be informed about the message in the option. This approach might have the advantage of not possibly confusing the receiving endpoint, and it does not require the endhost to send an additional packet. 5.2. Proxy to endpoint 5.2.1. Special packet of base connection A sidekick proxy replies to a sidekick-request packet by sending a special packet from the receiver's IP address and port number back to the endpoint [Sidekick]. This packet contains a sidekick-reply marker, an opaque session ID, and an IP address and port number for communicating with the proxy. Upon receiving the sidekick-reply packet, the sender begins communicating directly with the proxy from a different UDP port. It initially sends back the session ID and configuration parameters to start receiving quACKs (special ACKs crafted by a Sidekick proxy). 5.2.2. Header options A proxy could insert a newly defined TCP option or UDP option [I-D.ietf-tsvwg-udp-options] in a returning packet (e.g., an ACK) to answer back to the endpoint that originally announced its proxy support. This approach does not require the proxy to send an additional packet. 6. A survey of open issues Just an idea, having a separate list of common problems to be considered might be helpful. For example: * How to handle multiple proxies on a path? - Suggestion: Each proxy could send a special packet back to the endpoint, or add its information to a header option as long as there is enough space. * How to deal with multi-path? Welzl Expires 24 April 2025 [Page 5] Internet-Draft On-Path Proxy Discovery October 2024 - Suggestion: we ignore it, we just apply the discovery per path. Endpoints are expected to initiate the discovery process for every path at which they want to make use of a proxy should a proxy be available. This list will become longer as we add mechanisms to the preceding section. 7. Examined material that was not included [I-D.kuehlewind-quic-proxy-discovery] lists several possibilities for proxy discovery, but the proxies in question need not be on-path. One notable possibility mentioned in [I-D.kuehlewind-quic-proxy-discovery] is the use of Port Control Protocol (PCP) options; this is, in some sense, an on-path discovery method since PCP talks to NATs, which are necessarily on-path. However, there is no reason to limit the discovery process described in the present document to scenarios with NATs only. OPPD shares the on-path communication constraint with Path Layer UDP Substrate (PLUS). As such, there are commonalities between PLUS and OPPD such as the potential sharing of ports. However, the PLUS wire image in [I-D.trammell-plus-spec] was designed for the endpoint-to- network direction of signaling, which eliminates the need for an on- path proxy to prove that it has seen a packet. Being designed to support in-network measurement and state maintenance, PLUS is generally a much more sophisticated construct than what we expect to need for OPPD. 8. Security Considerations The idea of OPPD is only to discover on-path proxies. These devices must make it reasonably credible that they are indeed on-path; see the last item in Section 4. Further security considerations will depend on the use case. 9. IANA Considerations This document has no IANA actions. 10. References 10.1. Normative References Welzl Expires 24 April 2025 [Page 6] Internet-Draft On-Path Proxy Discovery October 2024 [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, . 10.2. Informative References [I-D.ietf-tsvwg-udp-options] Touch, J. D. and C. M. Heard, "Transport Options for UDP", Work in Progress, Internet-Draft, draft-ietf-tsvwg-udp- options-37, 13 October 2024, . [I-D.kuehlewind-quic-proxy-discovery] Kühlewind, M. and Z. Sarker, "Discovery Mechanism for QUIC-based, Non-transparent Proxy Services", Work in Progress, Internet-Draft, draft-kuehlewind-quic-proxy- discovery-01, 27 January 2020, . [I-D.trammell-plus-spec] Trammell, B. and M. Kühlewind, "Path Layer UDP Substrate Specification", Work in Progress, Internet-Draft, draft- trammell-plus-spec-01, 13 March 2017, . [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, . [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000, . [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . [Sidekick] "Sidekick: In-Network Assistance for Secure End-to-End Transport Protocols", Usenix NSDI 2024 , 2024. Welzl Expires 24 April 2025 [Page 7] Internet-Draft On-Path Proxy Discovery October 2024 [SMAQ] "Secure Middlebox-Assisted QUIC", IFIP NETWORKING 2023 , 2023. Author's Address Michael Welzl University of Oslo Email: michawe@ifi.uio.no Welzl Expires 24 April 2025 [Page 8]