]> Google LLC

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

Google LLC

1600 Amphitheatre Parkway Mountain View CA 94043 United States of America abhisinghietf@gmail.com

Transport MASQUE quic http datagram udp proxy tunnels quic in quic turtles all the way down masque http-ng listen The mechanism to proxy UDP in HTTP only allows each UDP Proxying request to transmit to a specific host and port. This is well suited for UDP client-server protocols such as HTTP/3, but is not sufficient for some UDP peer-to-peer protocols like WebRTC. This document proposes an extension to UDP Proxying in HTTP that enables such use-cases. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the MASQUE Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The mechanism to proxy UDP in HTTP allows creating tunnels for communicating UDP payloads to a fixed host and port. Combined with the HTTP CONNECT method (see ), it allows proxying the majority of a Web Browser's HTTP traffic. However WebRTC relies on ICE to provide connectivity between two Web browsers, and ICE relies on the ability to send and receive UDP packets to multiple hosts. While in theory it might be possible to accomplish this using multiple UDP Proxying HTTP requests, HTTP semantics do not guarantee that distinct requests will be handled by the same server. This can lead to the UDP packets being sent from distinct IP addresses, thereby preventing ICE from operating correctly. Consequently, UDP Proxying requests cannot enable WebRTC connectivity between peers. This document describes an extension to UDP Proxying in HTTP that allows sending and receiving UDP payloads to multiple hosts within the scope of a single UDP Proxying HTTP request.

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. This document uses terminology from and notational conventions from . This document uses the terms Integer and List from to specify syntax and parsing.

Proxied UDP Listener Mechanism In unextended UDP Proxying requests, the target host is encoded in the HTTP request path or query. For Listener UDP Proxying, it is instead conveyed in each HTTP Datagram, see . When performing URI Template Expansion of the UDP Proxying template (see ), the client sets both the target_host and the target_port variables to the '*' character (ASCII character 0x2A). Before sending its UDP Proxying request to the proxy, the client allocates an even-numbered context ID, see . The client then adds the "connect-udp-listen" header field to its UDP Proxying request, with its value set as the allocated context ID, see .

HTTP Datagram Payload Format When HTTP Datagrams associated with this Listener UDP Proxying request contain the context ID in the connect-udp-listen header field, the format of their UDP Proxying Payload field (see ) is defined by :

Listener UDP Proxying HTTP Datagram Format

IP Version:

The IP Version of the following IP Address field. MUST be 4 or 6.

IP Address:

The IP Address of this proxied UDP packet. When sent from client to proxy, this is the target host to which the proxy will send this UDP payload. When sent from proxy to client, this represents the source IP address of the UDP packet received by the proxy. This field has a length of 32 bits when the corresponding IP Version field value is 4, and 128 when the IP Version is 6.

UDP Port:

The UDP Port of this proxied UDP packet in network byte order. When sent from client to proxy, this is the target port to which the proxy will send this UDP payload. When sent from proxy to client, this represents the source UDP port of the UDP packet received by the proxy.

UDP Payload:

The unmodified UDP Payload of this proxied UDP packet (referred to as "data octets" in ).

The connect-udp-listen Header Field The "connect-udp-listen" header field’s value is an Integer. It is set as the Context ID allocated for Listener UDP Proxying; see . Any other value type MUST be handled as if the field were not present by the recipients (for example, if this field is defined multiple times, its type becomes a List and therefore is to be ignored). This document does not define any parameters for the connect-udp-listen header field value, but future documents might define parameters. Receivers MUST ignore unknown parameters.

Proxy behavior After accepting the Connect-UDP Listener proxying request, the proxy uses a UDP port to transmit UDP payloads received from the client to the target IP Address and UDP Port specified in each Listener Datagram Payload received from the client. The proxy uses the same port to listen for UDP packets from any authorized target and encapsulates the packets in the Listener Datagram Payload format, specifying the IP and port of the target and forwards it to the client.

Security Considerations The security considerations described in also apply here. Since TURN can be run over this mechanism, implementors should review the security considerations in . Since unextended UDP Proxying requests carry the target as part of the request, the proxy can protect unauthorized targets by rejecting requests before creating the tunnel, and communicate the rejection reason in response header fields. Listener UDP Proxying requests do not have this ability. Therefore, proxies MUST validate the target on every datagram and MUST NOT forward individual datagrams with unauthorized targets. Proxies can either silently discard such datagrams or abort the corresponding request stream.

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

Field Name:

connect-udp-listen

Template:

None

Status:

provisional (permanent if this document is approved)

Reference:

This document

Comments:

None

References Normative References This document describes how to proxy UDP in HTTP, similar to how the HTTP CONNECT method allows proxying TCP in HTTP. More specifically, this document defines a protocol that allows an HTTP client to create a tunnel for UDP communications through an HTTP server that acts as a proxy. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. 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 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. 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. This document describes HTTP Datagrams, a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection. In HTTP/3, HTTP Datagrams can be sent unreliably using the QUIC DATAGRAM extension. When the QUIC DATAGRAM frame is unavailable or undesirable, HTTP Datagrams can be sent using the Capsule Protocol, which is a more general convention for conveying data in HTTP connections. HTTP Datagrams and the Capsule Protocol are intended for use by HTTP extensions, not applications. Informative References This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). This document obsoletes RFC 5245. If a host is located behind a NAT, it can be impossible for that host to communicate directly with other hosts (peers) in certain situations. In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called "Traversal Using Relays around NAT" (TURN), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. The TURN protocol was designed to be used as part of the Interactive Connectivity Establishment (ICE) approach to NAT traversal, though it can also be used without ICE. This document obsoletes RFCs 5766 and 6156. Apple Inc. Google LLC Google LLC Ericsson Ericsson This document describes how to proxy IP packets in HTTP. This protocol is similar to UDP proxying in HTTP, but allows transmitting arbitrary IP packets. More specifically, this document defines a protocol that allows an HTTP client to create an IP tunnel through an HTTP server that acts as an IP proxy. This document updates RFC 9298.

Example In the example below, the client is configured with URI Template "https://example.org/.well-known/masque/udp/{target_host}/{target_port}/" and wishes to use WebRTC with another browser over a listener UDP Proxying tunnel. It contacts a STUN server at 192.0.2.42. The STUN server, in response, sends the proxy's IP address to the other browser at 203.0.113.33. Using this information, the other browser sends a UDP packet to the proxy, which is proxied over HTTP back to the client. :method = CONNECT :protocol = connect-udp :scheme = https :path = /.well-known/masque/udp/*/*/ :authority = proxy.example.org connect-udp-listen = 2 capsule-protocol = ?1 DATAGRAM --------> Quarter Stream ID = 11 Context ID = 2 IP Version = 4 IP Address = 192.0.2.42 UDP Port = 1234 UDP Payload = Encapsulated UDP Payload <-------- STREAM(44): HEADERS :status = 200 capsule-protocol = ?1 /* Wait for STUN server to respond to UDP packet. */ <-------- DATAGRAM Quarter Stream ID = 11 Context ID = 2 IP Version = 4 IP Address = 192.0.2.42 UDP Port = 1234 UDP Payload = Encapsulated UDP Payload /* Wait for the STUN server to send the proxy's IP and */ /* port to the other browser and for the other browser */ /* to send a UDP packet to the proxy. */ <-------- DATAGRAM Quarter Stream ID = 11 Context ID = 2 IP Version = 4 IP Address = 203.0.113.33 UDP Port = 4321 UDP Payload = Encapsulated UDP Payload ]]>

Comparison with CONNECT-IP While the use-cases described in could be supported using IP Proxying in HTTP , it would require that every HTTP Datagram carries a complete IP header. This would lead to both inefficiencies in the wire encoding and reduction in available Maximum Transmission Unit (MTU). Furthermore, Web browsers would need to support IPv4 and IPv6 header generation, parsing, validation and error handling.

Acknowledgments This proposal is the result of many conversations with MASQUE working group participants.