]> Google LLC

1600 Amphitheatre Parkway Mountain View, California 94043 United States of America dschinazi.ietf@gmail.com

MASQUE Internet-Draft CONNECT-UDP allows proxying UDP packets over HTTP. This document describes an extension to CONNECT-UDP that allows conveying ECN information on proxied UDP packets. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction CONNECT-UDP allows proxying UDP packets over HTTP. This document describes an extension to CONNECT-UDP that allows conveying ECN information on proxied UDP packets.

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 when, and only when, they appear in all capitals, as shown here.

Context Identifiers The "Context Identifiers" section of defines the concept of context IDs and how they can be used to extend CONNECT-UDP. When a client wishes to use ECN with CONNECT-UDP, it generates an unique client-allocated context ID. In this document, we'll refer to that context ID as the "chosen context ID". Note that, by definition of client-allocated context IDs, the chosen context ID will always be a non-zero even number. We also add the restriction that the chosen context ID MUST be strictly less than 10¹⁵. If the client has run out of available context ID values that match this requirement for this CONNECT-UDP request, it MUST NOT use the ECN extension with this CONNECT-UDP request.

ECN Header Definition The "ECN" header field is an Item Structured Field, see ; its value MUST be a Integer; any other value type MUST be handled as if the field were not present by recipients (for example, if this field is included multiple times, its type will become a List and the field will therefore be ignored). This document does not define any parameters for the "ECN" header field value, but future documents might define parameters. Receivers MUST ignore unknown parameters. When present, the "ECN" header indicates that the sender supports this extension, and communicates the chosen context ID as the "ECN" field value. For example, if the client chosen context ID is 42, it would send the following:

Example Client ECN Field

Clients MUST NOT indicate support for this extension unless they know that the protocol running over UDP that is being proxied supports ECN, and will react appropriately to Congestion Experienced (CE) markings. Proxies MUST NOT indicate support for this extension unless they know they have the ability to read and write the IP ECN bits on its target-bound UDP sockets. This extension is said to have been negotiated when both client and proxy indicated support for it in their CONNECT-UDP request and response. When indicating support for this extension, the proxy send the client's chosen context ID as the "ECN" field value. For example, the proxy could reply with:

Example Proxy ECN Field

Encoding of ECN bits When an HTTP Datagram associated with a CONNECT-UDP stream uses the chosen context ID as its context ID, its "Payload" field contains the following format (using the notation from the "Notational Conventions" section of ):

CONNECT-UDP Payload with ECN

Must be Zero:

6 bits that MUST be sent as zero. Receivers MUST validate that these bits are zero and MUST silently drop the HTTP Datagram if they have any other value. Extensions to this mechanism MAY relax this requirement.

ECN Bits:

The ECN bits, sent in the same order as they appear in the IP header.

UDP Payload:

The UDP Payload, as defined in the "HTTP Datagram Payload Format" section of .

When the proxy receives a datagram with the chosen context ID, it sets the IP packet's ECN bits accordingly on the UDP packet it sends to the target. Similarly, in the other direction the ECN Bits field represents which ECN bits were seen on the UDP packets received from the target.

A Note about Future Extensions This CONNECT-UDP extension uses an HTTP field to register its chosen context ID. Future extensions to CONNECT-UDP can use the same strategy to register their chosen context ID(s) via another HTTP field. This strategy is best for CONNECT-UDP extensions that only need to register context IDs during the HTTP request and response. Some extensions may need to register context IDs after the request and response have been exchanged, for example an extension that wishes to compress QUIC connection IDs is not aware of all connection IDs at request time. In such cases, extensions can use new Capsule Types (see ) to perform context ID registration.

Security Considerations This document does not have additional security considerations beyond those defined in .

IANA Considerations This document will request IANA to register the following entry in the "HTTP Field Name" registry:

Field Name:

ECN

Template:

None

Status:

provisional (permanent if this document is approved)

Reference:

This document

Comments:

None

Normative References Google LLC This document describes how to proxy UDP over HTTP. Similar to how the CONNECT method allows proxying TCP over HTTP, this document defines a new mechanism to proxy UDP. It is built using HTTP Extended CONNECT. This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values. Google LLC Cloudflare This document describes HTTP Datagrams, a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection. In HTTP/3, HTTP Datagrams can be conveyed natively using the QUIC DATAGRAM extension. When the QUIC DATAGRAM frame is unavailable or undesirable, they can be sent using the Capsule Protocol, a more general convention for conveying data in HTTP connections. Both are intended for use by HTTP extensions, not applications. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.

Acknowledgments This proposal was inspired directly or indirectly by prior work from many people. The author would like to thank contributors the MASQUE working group.