Network Working Group M. Thomson Internet-Draft Mozilla Intended status: Informational C. Huitema Expires: 18 April 2025 Private Octopus Inc. 奥 一穂 (K. Oku) Fastly 15 October 2024 Transparent Rate Adaptation Indications for Networks (TRAIN) Protocol draft-thomson-scone-train-protocol-00 Abstract On-path network elements can sometimes be configured to apply rate limits to flows that pass them. This document describes a method for signaling to endpoints that rate limiting policies are in force and approximately what that rate limit is. 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://martinthomson.github.io/train-protocol/draft-thomson-train- protocol.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-thomson-scone-train-protocol/. Source for this draft and an issue tracker can be found at https://github.com/martinthomson/train-protocol. 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 18 April 2025. Thomson, et al. Expires 18 April 2025 [Page 1] Internet-Draft TRAIN Protocol October 2024 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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Independent of Congestion Signals . . . . . . . . . . . . 4 3.2. Unspecified Scope . . . . . . . . . . . . . . . . . . . . 4 3.3. Per-Flow Signal . . . . . . . . . . . . . . . . . . . . . 5 3.4. Undirectional Signal . . . . . . . . . . . . . . . . . . 5 3.5. Advisory Signal . . . . . . . . . . . . . . . . . . . . . 5 4. Conventions and Definitions . . . . . . . . . . . . . . . . . 6 5. TRAIN Packet . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Rate Signals . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Processing TRAIN Packets . . . . . . . . . . . . . . . . 8 6. Negotiating TRAIN . . . . . . . . . . . . . . . . . . . . . . 8 7. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Applying Rate Limit Signals . . . . . . . . . . . . . . . 8 7.2. Providing Opportunities to Apply Rate Limit Signals . . . 9 7.3. Feedback To Sender About Signals . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 9.1. Passive Attacks . . . . . . . . . . . . . . . . . . . . . 11 9.2. Active Attacks . . . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10.1. TRAIN Version . . . . . . . . . . . . . . . . . . . . . 13 10.2. train_supported Transport Parameter . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 14 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Thomson, et al. Expires 18 April 2025 [Page 2] Internet-Draft TRAIN Protocol October 2024 1. Introduction Many access networks limit the maximum data rate that attached devices are able to attain. This is often done without any indication to the applications running on devices. The result can be that application performance is degraded, as the manner in which rate limits are enforced can be incompatible with the rate estimation or congestion control algorithms used at endpoints. Having the network indicate what its rate limiting policy is, in a way that is accessible to endpoints, might allow applications to use this inforation when adapting their send rate. The Transparent Rate Adaptation Indications for Networks (TRAIN) protocol is negotiated by QUIC endpoints. This protocol provides a means for network elements to signal the maximum available sustained throughput, or rate limits, for flows of UDP datagrams that transit that network element to a QUIC endpoint. 2. Overview QUIC endpoints can negotiate the use of TRAIN by including a transport parameter (Section 6) in the QUIC handshake. Endpoints then occasionally coalesce a TRAIN packet with ordinary QUIC packets that they send. Network elements that have rate limiting policies can detect flows that include TRAIN packets. The network element can indicate a maximum sustained throughput by modifying the TRAIN packet as it transits the network element. +--------+ +---------+ +----------+ | QUIC | | Network | | QUIC | | Sender | | Element | | Receiver | +---+----+ +----+----+ +----+-----+ | | | +--- TRAIN --->| TRAIN+rate | | +QUIC +---- +QUIC --->| | | | Validate QUIC packet | | | and record rate | | | QUIC endpoints that receive modified TRAIN packets observe the indicated version, process the QUIC packet, and then record the indicated rate. Thomson, et al. Expires 18 April 2025 [Page 3] Internet-Draft TRAIN Protocol October 2024 Indicated rate limits apply only in a single direction. Separate indications can be sent for the client-to-server direction and server-to-client direction. The indicated rates do not need to be the same. Indicated rate limits only apply to the path on which they are received. A connection that migrates or uses multipath [QUIC-MP] cannot assume that rate limit indications from one path apply to new paths. 3. Applicability This protocol only works for flows that use the TRAIN packet (Section 5). The protocol requires that packets are modified as they transit a network element, which provides endpoints strong evidence that the network element has the power to drop packets; though see Section 8 for potential limitations on this. The rate limit signal that this protocol carries is independent of congestion signals, limited to a single path and UDP packet flow, unidirectional, and strictly advisory. 3.1. Independent of Congestion Signals Rate limit signals are not a substitute for congestion feedback. Congestion signals, such as acknowledgments, provide information on loss, delay, or ECN markings [ECN] that indicate the real-time condition of a network path. Congestion signals might indicate a throughput that is different from the signaled rate limit. Endpoints cannot assume that a signaled rate limit is achievable if congestion signals indicate otherwise. Congestion could be experienced at a different point on the network path than the network element that indicates a rate limit. Therefore, endpoints need to respect the send rate constraints that are set by a congestion controller. 3.2. Unspecified Scope Modifying a packet does not prove that the rate limit that is indicated would be achievable. A signal that is sent for a specific flow is likely enforced at a different scope. The extent of that scope is not carried in the signal. For instance, limits might apply at a network subscription level, such that multiple flows receive the same signal. Thomson, et al. Expires 18 April 2025 [Page 4] Internet-Draft TRAIN Protocol October 2024 Endpoints can therefore be more confident in the rate limit signal as an indication of the maximum achievable throughput than as any indication of expected throughput. That throughput will only be achievable when there is no significant data flowing in the same scope. In the presence of other flows, congestion limits are likely to determine actual throughput. This makes the application of signals most usefully applied to a downlink flow in access networks, close to an endpoint. In that case, capacity is less likely to be split between multiple active flows. 3.3. Per-Flow Signal The same UDP address tuple might be used for multiple QUIC connections. A single signal might be lost or only reach a single application endpoint. Network elements that signal about a flow might choose to send additional signals, using connection IDs to indicate when new connections could be involved. 3.4. Undirectional Signal The endpoint that receives a rate limit signal is not the endpoint that might adapt its sending behavior as a result of receiving the signal. This ensures that the rate limit signal is attached to the flow that it is mostly likely to apply to. An endpoint might need to communicate the value it receives to its peer in order to ensure that the limit is respected. This document does not define how that signaling occurs as this is specific to the application in use. 3.5. Advisory Signal A signal does not prove that a higher rate would not be successful. Endpoints that receive this signal therefore need to treat the information as advisory. As an advisory signal, network elements cannot assume that endpoints will respect the signal. Though this might reduce the need for more active rate limiting, how rate limit enforcement is applied is a matter for network policy. Thomson, et al. Expires 18 April 2025 [Page 5] Internet-Draft TRAIN Protocol October 2024 The time and scope over which a rate limit applies is not specified. The effective rate limit might change without being signaled. The signaled limit can be assumed to apply to the flow of packets on the same UDP address tuple for the duration of that flow. Rate limiting policies often apply on the level of a device or subscription, but endpoints cannot assume that this is the case. A separate signal can be sent for each flow. 4. 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 [BCP14] when, and only when, they appear in all capitals, as shown here. 5. TRAIN Packet A TRAIN packet is a QUIC long header packet that follows the QUIC invariants; see Section 5.1 of [INVARIANTS]. Figure 1 shows the format of the train packet using the conventions from Section 4 of [INVARIANTS]. TRAIN Packet { Header Form (1) = 1, Reserved (1), Rate Signal (6), Version (32) = 0xTBD, Destination Connection ID Length (8), Destination Connection ID (0..2040), Source Connection ID Length (8), Source Connection ID (0..2040), } Figure 1: TRAIN Packet Format The most significant bit (0x80) of the packet indicates that this is a QUIC long header packet. The next bit (0x40) is reserved and can be set according to [QUIC-BIT]. The entire payload of the TRAIN packet is carried in the Rate Signal field that forms the low 6 bits (0x3f) of the first byte. Values for this field are described in Section 5.1. This packet includes a Destination Connection ID field that is set to the same value as other packets in the same datagram; see Section 12.2 of [QUIC]. Thomson, et al. Expires 18 April 2025 [Page 6] Internet-Draft TRAIN Protocol October 2024 The Source Connection ID field is set to match the Source Connection ID field of any packet that follows. If the next packet in the datagram does not have a Source Connection ID field, which is the case for packets with a short header (Section 5.2 of [INVARIANTS]), the Source Connection ID field is empty. TRAIN packets SHOULD be included as the first packet in a datagram. This is necessary in many cases for QUIC versions 1 and 2 because packets with a short header cannot precede any other packets. 5.1. Rate Signals | Note: The exact set of rates that are included is subject to | negotiation. We should aim to find typical rate limits that | are used in real networks and by real applications. The Rate Signal field of a TRAIN packet is set to 0xTBD when sent by a QUIC endpoint. Receiving value indicates that there is no rate limit in place or that the TRAIN protocol is not supported by network elements on the path. The values from Table 1 are specified to carry a the corresponding rate limit signal. +=============+============+ | Rate Signal | Rate Limit | +=============+============+ | 0xTBD | X Mbps | +-------------+------------+ | 0xTBD | X Mbps | +-------------+------------+ | 0xTBD | X Mbps | +-------------+------------+ | 0xTBD | X Mbps | +-------------+------------+ | 0xTBD | X Mbps | +-------------+------------+ | 0xTBD | X Mbps | +-------------+------------+ | 0xTBD | X Mbps | +-------------+------------+ | 0xTBD | X Mbps | +-------------+------------+ Table 1: Table of Rate Signals and Rate Limits TODO: Work out how reserved values can be used, if at all. Thomson, et al. Expires 18 April 2025 [Page 7] Internet-Draft TRAIN Protocol October 2024 5.2. Processing TRAIN Packets Processing a TRAIN packet involves reading the value from the Rate Signal field. However, this value MUST NOT be used unless another packet from the same datagram is successfully processed. Therefore, a TRAIN packet always needs to be coalesced with other QUIC packets. A TRAIN packet is defined by the use of the longer header bit (0x80 in the first byte) and the TRAIN protocol version (0xTBD in the next four bytes). A TRAIN packet MAY be discarded, along with any packets that come after it in the same datagram, if the Source Connection ID is not consistent with those coalesced packets, as specified in Section 5. A TRAIN packet MUST be discarded if the Destination Connection ID does not match one recognized by the receiving endpoint. 6. Negotiating TRAIN A QUIC endpoint indicates that it is willing to receive TRAIN packets by including the train_supported transport parameter (0xTBD). This transport parameter is valid for QUIC versions 1 [QUIC] and 2 [QUICv2] and any other version that recognizes the versions, transport parameters, and frame types registries established in Sections 22.2, 22.3, and 22.4 of [QUIC]. 7. Deployment QUIC endpoints can enable the use of the TRAIN protocol by sending TRAIN packets Section 5. Network elements then apply or replace the Rate Signal field (Section 7.1) according to their policies. 7.1. Applying Rate Limit Signals A network element detects a TRAIN packet by observing that a packet has a QUIC long header and the TRAIN protocol version of 0xTBD. A network element then conditionally replaces the six bits of the Rate Signal field with a value of its choosing. A network element might receive a packet that already includes a rate limit signal. If the network element wishes to signal a lower rate limit, they can replace the Rate Signal field with a different value that indicates the lower limit. If the network element wishes to signal a higher rate limit, they leave the Rate Signal field alone, preserving the signal from the network element that has a lower rate limit policy. Thomson, et al. Expires 18 April 2025 [Page 8] Internet-Draft TRAIN Protocol October 2024 The following pseudocode indicates how a TRAIN packet might be detected and replaced. This assumes a target rate that is preconfigured and a means of comparing the rate signal in the packet to the target rate signal. target_rate_signal = rate_signal_for(target_rate) is_long = packet[0] & 0x80 == 0x80 is_train = compare(packet[1..5], TRAIN_VERSION) if is_long and is_train: packet_rate_signal = packet[0] & 0x3f if target_rate_signal.is_lower_than(packet_rate_signal): packet[0] = packet[0] & 0xc0 | target_rate_signal | TODO: When defining the signal values, make this comparison | easy. 7.2. Providing Opportunities to Apply Rate Limit Signals Endpoints that wish to offer network elements the option to add rate limit markings can send TRAIN packets at any time. This is a decision that a sender makes when constructing datagrams, so TRAIN packets can be sent as frequently as the application requires. Endpoints MUST send any TRAIN packet they send as the first packet of a datagram, coalesced with additional packets. An endpoint that receives and discards a TRAIN without also successfully processing another packets from the same datagram SHOULD ignore any rate limit signal. Such a datagram might be entirely spoofed. 7.3. Feedback To Sender About Signals Information about rate limits is intended for the sending application. Any signal from network elements can be propagated to the receiving application using an implementation-defined mechanism. This document does not define a means for indicating what was received. That is, the expectation is that any signal is propagated to the application for handling, not handled automatically by the transport layer. How a receiving application communicates the rate limit signal to a sending application will depend on the application in use. Different applications can choose different approaches. For example, in an application where a receiver drives rate adaptation, it might not be necessary to define additional signaling. Thomson, et al. Expires 18 April 2025 [Page 9] Internet-Draft TRAIN Protocol October 2024 A sender can use any acknowledgment mechanism provided by the QUIC version in use to learn whether datagrams containing TRAIN packets were likely received. This might help inform whether to send additional TRAIN packets in the event that a datagram is lost. However, rather than relying on transport signals, an application might be better able to indicate what has been received and processed. TRAIN packets could be stripped from datagrams in the network, which cannot be reliably detected. This could result in a sender falsely believing that no network element applied a rate limit signal. 8. Security Considerations The modification of packets provides endpoints proof that a network element is in a position to drop datagrams and thereby enforce the indicated rate limit. Section 7.2 states that endpoints only accept signals if the datagram contains a packet that it accepts to prevent an off-path attacker from inserting spurious rate limit signals. Some off-path attackers may be able to both observe traffic and inject packets. Attackers with such capabilities could observe packets sent by an endpoint, create datagrams coalescing an arbitrary TRAIN packet and the observed packet, and send these datagrams such that they arrive at the peer endpoint before the original packet. Spoofed packets that seek to advertise a higher limit than might otherwise be permitted also need to bypass any rate limiters. The attacker will thus get arbitrary TRAIN packets accepted by the peer, with the result being that the endpoint receives a false or misleading rate limit. The recipient of a rate limit signal therefore cannot guarantee that the signal was generated by an on-path network element. However, the capabilities required of an off-path attacker are substantially similar to those of on path elements. The actual value of the rate limit signal is not authenticated. Any signal might be incorrectly set in order to encourage endpoints to behave in ways that are not in their interests. Endpoints are free to ignore limits that they think are incorrect. The congestion controller employed by a sender provides real-time information about the rate at which the network path is delivering data. Similarly, if there is a strong need to ensure that a rate limit is respected, network elements cannot assume that the signaled limit will be respected by endpoints. Thomson, et al. Expires 18 April 2025 [Page 10] Internet-Draft TRAIN Protocol October 2024 9. Privacy Considerations The focus of this analysis is the extent to which observing TRAIN packets could be used to gain information about endpoints. This might be leaking details of how applications using QUIC operate or leaks of endpoint identity when using additional privacy protection, such as a VPN. Any network element that can observe the content of that packet can read the rate limit that was applied. Any signal is visible on the path, from the point at which it is applied to the point at which it is consumed at an endpoint. On path elements can also alter the TRAIN signal to try trigger specific reactions and gain further knowledge. In the general case of a client connected to a server through the Internet, we believe that TRAIN does not provide much advantage to attackers. The identities of the clients and servers are already visible through their IP addresses. Traffic analysis tools already provide more information than the data rate limits set by TRAIN. There are two avenues of attack that require more analysis: * that the passive observation of TRAIN packets might help identify or distinguish endpoints; and * that active manipulation of TRAIN signals might help reveal the identity of endpoints that are otherwise hidden behind VPNs or proxies. 9.1. Passive Attacks If only few clients and server pairs negotiate the usage of TRAIN, the occasional observation of TRAIN packets will "stick out". That observation, could be combined with observation of timing and volume of traffic to help identify the endpoint or categorize the application that they are using. A variation of this issue occurs if TRAIN is widely implemented, but only used in some specific circumstances. In that case, observation of TRAIN packets reveals information about the state of the endpoint. If multiple servers are accessed through the same front facing server, Encrypted Client Hello (ECH) may be used to prevent outside parties to identify which specific server a client is using. However, if only a few of these servers use TRAIN, any TRAIN packets will help identify which specific server a client is using. Thomson, et al. Expires 18 April 2025 [Page 11] Internet-Draft TRAIN Protocol October 2024 This issue will be mitigated if TRAIN becomes widely implemented, and if the usage of TRAIN is not limited to the type of applications that make active use of the signal. QUIC implementations are therefore encouraged to make the feature available unconditionally. Endpoints might send TRAIN packets whenever a peer can accept them. 9.2. Active Attacks Suppose a configuration in which multiple clients use a VPN or proxy service to access the same server. The attacker sees the IP addresses in the packets behind VPN and proxy and also between the users and the VPN, but it does not know which VPN address corresponds to what user address. Suppose now that the attacker selects a flow on the link between the VPN/proxy and server. The attacker applies rate limit signals to TRAIN packets in that flow. The attacker chooses a bandwidth that is lower than the "natural" bandwidth of the connection. A reduction in the rate of flows between client and VPN/proxy might allow the attacker to link the altered flow to the client. +--------+ | Client |------. +--------+ \ +-------+ '---->| | +--------+ +--------+ | VPN |<==========>| | | Client |------------->| / |<==========>| Server | +--------+ | Proxy |<==========>| | .---->| | ^ +--------+ +--------+ / +-------+ | | Client |======' | +--------+ ^ Apply rate limit signal \ \ Observe change An attacker that can manipulate TRAIN headers can also simulate congestion signals by dropping packets or by setting the ECN CE bit. That will also likely result in changes in the congestion response by the affected client. A VPN or proxy could defend against this style of attack by removing TRAIN (and ECN) signals. There are few reasons to provide per-flow rate limit signals in that situation. Endpoints might also either disable this feature or ignore any signals when they are aware of the use of a VPN or proxy. Thomson, et al. Expires 18 April 2025 [Page 12] Internet-Draft TRAIN Protocol October 2024 10. IANA Considerations This document registers a new QUIC version (Section 10.1) and a QUIC transport parameter (Section 10.2). 10.1. TRAIN Version This document registers the following entry to the "QUIC Versions" registry maintained at https://www.iana.org/assignments/quic (https://www.iana.org/assignments/quic), following the guidance from Section 22.2 of [QUIC]. Value: 0xTBD Status: permanent Specification: This document Change Controller: IETF (iesg@ietf.org) Contact: QUIC Working Group (quic@ietf.org) Notes: TRAIN Protocol 10.2. train_supported Transport Parameter This document registers the train_supported transport parameter in the "QUIC Transport Parameters" registry maintained at https://www.iana.org/assignments/quic (https://www.iana.org/assignments/quic), following the guidance from Section 22.3 of [QUIC]. Value: 0xTBD Parameter Name: train_supported Status: Permanent Specification: This document Date: This date Change Controller: IETF (iesg@ietf.org) Contact: QUIC Working Group (quic@ietf.org) Notes: (none) 11. References 11.1. Normative References [BCP14] Best Current Practice 14, . At the time of writing, this BCP comprises the following: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Thomson, et al. Expires 18 April 2025 [Page 13] Internet-Draft TRAIN Protocol October 2024 Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [INVARIANTS] Thomson, M., "Version-Independent Properties of QUIC", RFC 8999, DOI 10.17487/RFC8999, May 2021, . [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [QUIC-BIT] Thomson, M., "Greasing the QUIC Bit", RFC 9287, DOI 10.17487/RFC9287, August 2022, . [QUICv2] Duke, M., "QUIC Version 2", RFC 9369, DOI 10.17487/RFC9369, May 2023, . 11.2. Informative References [ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, . [QUIC-MP] Liu, Y., Ma, Y., De Coninck, Q., Bonaventure, O., Huitema, C., and M. Kühlewind, "Multipath Extension for QUIC", Work in Progress, Internet-Draft, draft-ietf-quic-multipath-10, 8 July 2024, . Acknowledgments TODO acknowledge. Authors' Addresses Martin Thomson Mozilla Email: mt@lowentropy.net Christian Huitema Private Octopus Inc. Thomson, et al. Expires 18 April 2025 [Page 14] Internet-Draft TRAIN Protocol October 2024 Email: huitema@huitema.net Kazuho Oku Fastly Email: kazuhooku@gmail.com Additional contact information: 奥 一穂 Fastly Thomson, et al. Expires 18 April 2025 [Page 15]