Network Working Group D. Schinazi Internet-Draft Google LLC Intended status: Experimental 12 March 2021 Expires: 13 September 2021 The MASQUE Protocol draft-schinazi-masque-protocol-03 Abstract This document describes MASQUE (Multiplexed Application Substrate over QUIC Encryption). MASQUE is a framework that allows concurrently running multiple networking applications inside an HTTP/3 connection. For example, MASQUE can allow a QUIC client to negotiate proxying capability with an HTTP/3 server, and subsequently make use of this functionality while concurrently processing HTTP/3 requests and responses. Discussion of this work is encouraged to happen on the MASQUE IETF mailing list masque@ietf.org or on the GitHub repository which contains the draft: https://github.com/DavidSchinazi/masque-drafts. 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 13 September 2021. Copyright Notice Copyright (c) 2021 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. Schinazi Expires 13 September 2021 [Page 1] Internet-Draft MASQUE March 2021 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 2. MASQUE Negotiation . . . . . . . . . . . . . . . . . . . . . 3 3. MASQUE Applications . . . . . . . . . . . . . . . . . . . . . 4 3.1. HTTP Proxy . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. HTTP Proxy Negotiation . . . . . . . . . . . . . . . 4 3.2. DNS over HTTPS . . . . . . . . . . . . . . . . . . . . . 4 3.2.1. DNS over HTTPS Negotiation . . . . . . . . . . . . . 5 3.3. QUIC Proxying . . . . . . . . . . . . . . . . . . . . . . 5 3.3.1. QUIC Proxy Compression . . . . . . . . . . . . . . . 5 3.3.2. QUIC Proxy Negotiation . . . . . . . . . . . . . . . 6 3.3.3. QUIC Proxy Encoding . . . . . . . . . . . . . . . . . 6 3.3.4. QUIC Proxy Routing . . . . . . . . . . . . . . . . . 9 3.4. UDP Proxying . . . . . . . . . . . . . . . . . . . . . . 9 3.4.1. UDP Proxy Compression . . . . . . . . . . . . . . . . 9 3.4.2. UDP Proxy Negotiation . . . . . . . . . . . . . . . . 9 3.4.3. UDP Proxy Encoding . . . . . . . . . . . . . . . . . 9 3.5. IP Proxying . . . . . . . . . . . . . . . . . . . . . . . 11 3.5.1. IP Proxy Negotiation . . . . . . . . . . . . . . . . 11 3.5.2. IP Proxy Encoding . . . . . . . . . . . . . . . . . . 11 3.6. Service Registration . . . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5.1. MASQUE Well-Known URI . . . . . . . . . . . . . . . . . . 12 5.2. MASQUE Applications Registry . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Normative References . . . . . . . . . . . . . . . . . . 13 6.2. Informative References . . . . . . . . . . . . . . . . . 14 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction This document describes MASQUE (Multiplexed Application Substrate over QUIC Encryption). MASQUE is a framework that allows concurrently running multiple networking applications inside an HTTP/3 connection (see [HTTP3]). For example, MASQUE can allow a QUIC client to negotiate proxying capability with an HTTP/3 server, and subsequently make use of this functionality while concurrently processing HTTP/3 requests and responses. Schinazi Expires 13 September 2021 [Page 2] Internet-Draft MASQUE March 2021 MASQUE Negotiation is performed using HTTP mechanisms, but MASQUE applications can subsequently leverage QUIC [QUIC] features without using HTTP. Discussion of this work is encouraged to happen on the MASQUE IETF mailing list masque@ietf.org or on the GitHub repository which contains the draft: https://github.com/DavidSchinazi/masque-drafts. 1.1. 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. 2. MASQUE Negotiation In order to negotiate the use of the MASQUE protocol, the client starts by sending a MASQUE request in the HTTP data of an HTTP POST request to "/.well-known/masque/initial". The client can use this to request specific MASQUE applications and advertise support for MASQUE extensions. The MASQUE server indicates support for MASQUE by sending an HTTP status code 200 response, and can use the data to inform the client of which MASQUE applications are now in use, and various configuration parameters. Both the MASQUE negotiation initial request and its response carry a sequence of MASQUE applications, as shown in Figure 1: 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MASQUE Application 1 (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MASQUE Application 2 (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MASQUE Application N (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Sequence of MASQUE Applications Each MASQUE Application is encoded as an (identifier, length, value) tuple, as shown in Figure 2: Schinazi Expires 13 September 2021 [Page 3] Internet-Draft MASQUE March 2021 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MASQUE Application ID (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MASQUE Application Length (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MASQUE Application Value (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: MASQUE Application Encoding The MASQUE Application Length field contains the length of the MASQUE Application Value field. The contents of the MASQUE Application Value field are defined by its corresponding MASQUE application. When parsing, endpoints MUST ignore unknown MASQUE applications. A given MASQUE application ID MUST NOT appear twice in a given sequence of MASQUE applications. 3. MASQUE Applications When the MASQUE server accepts the client's MASQUE initial request, it advertises support for MASQUE Applications, which will be multiplexed over this HTTP/3 connection. 3.1. HTTP Proxy The client can make proxied HTTP requests through the server to other servers. In practice this will mean using the HTTP CONNECT method to establish a stream over which to run TLS to a different remote destination. The proxy applies back-pressure to streams in both directions. 3.1.1. HTTP Proxy Negotiation Use of the HTTP Proxying MASQUE application is negotiated by sending the "http_proxying" (type 0x00) type-length-value during MASQUE negotiation. The length MUST be zero. 3.2. DNS over HTTPS The client can send DNS queries using DNS over HTTPS [DOH] to the MASQUE server. Schinazi Expires 13 September 2021 [Page 4] Internet-Draft MASQUE March 2021 3.2.1. DNS over HTTPS Negotiation Use of the DNS over HTTPS MASQUE application is negotiated by sending the "dns_over_https" (type 0x01) type-length-value during MASQUE negotiation. When sent by the client, the length MUST be zero. When sent by the server, the value contains the DoH URI Template encoded as a non-null-terminated UTF-8 string. 3.3. QUIC Proxying By leveraging QUIC client connection IDs, a MASQUE server can act as a QUIC proxy while only using one UDP port. To allow this, the MASQUE server informs the client of a required client connection ID length during negotiation. The client is then able to send proxied packets to the MASQUE server who will forward them on to the desired IP address and UDP port. Return packets are similarly forwarded in the opposite direction. Compared to UDP proxying, this mode has the advantage of only requiring one UDP port to be open on the MASQUE server, and can lower the overhead on the link between client and MASQUE server by compressing connection IDs. 3.3.1. QUIC Proxy Compression To reduce the overhead of proxying, QUIC Proxying leverages compression to elide the connection IDs on the link between the client and MASQUE server. This uses the concept of a compression context. Compression contexts are indexed using a datagram flow identifiers [H3DGRAM], and contain the tuple (client connection ID, server connection ID, server IP address, server port). Any time and endpoint wants to send a proxied packet to its peer, it searches its list of compression contexts looking for one that matches the address, port and connection IDs from the proxied packet. If there was no match, the endpoint creates a new compression context and adds it to the list. Compression contexts also carry a boolean value representing whether the context has been validated, which means that this endpoint is confident that its peer is aware if the given compression context. Compression contexts that were created by the peer start off validated, whereas locally-created ones are not validated until the endpoint receives a packet using that compression context, or an acknowledgement for a sent packet that uses the context. Schinazi Expires 13 September 2021 [Page 5] Internet-Draft MASQUE March 2021 The DATAGRAM frame [DGRAM] format below allows both endpoints to immediately start sending proxied QUIC packets using unvalidated compression contexts. Once contexts are vaidated, the server IP address, server port and the connection IDs can be ommited. TODO: garbage collect obsolete compression contexts. 3.3.2. QUIC Proxy Negotiation Use of the QUIC Proxying MASQUE application is negotiated by sending the "quic_proxying" (type 0x02) type-length-value during MASQUE negotiation. When sent by the client, the value contains a single variable-length integer, called "new_quic_proxy_compression_context_flow_id", that represents the DATAGRAM flow ID used to negotiate compression contexts. When sent by the server, the value contains two variable-length integers, the DATAGRAM flow ID used to negotiate compression contexts (called "new_quic_proxy_compression_context_flow_id"), followed by the required connection ID length. 3.3.3. QUIC Proxy Encoding Once negotiated, the QUIC Proxying MASQUE Application only uses DATAGRAM frames, whose content is shown in Figure 3 and Figure 4. Schinazi Expires 13 September 2021 [Page 6] Internet-Draft MASQUE March 2021 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow Identifier (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New Compression Context ID (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CCIDL (8) | | +-+-+-+-+-+-+-+-+ Client Connection ID (0..160) + | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SCIDL (8) | | +-+-+-+-+-+-+-+-+ Server Connection ID (0..160) + | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Server Port Number (16) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Family (8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Server IP Address (32/128) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Byte 1 (8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + [Version (32)] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + QUIC Payload (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Unvalidated QUIC Proxy Datagram Unvalidated QUIC Proxy DATAGRAM frames contain the following fields: Flow Identifier: The flow identifier represents the compression context used by this frame. Unvalidated compression contexts use the "new_quic_proxy_compression_context_flow_id" value received during negotiation. New Compression Context ID: The new Compression Context ID that this frame uses. The connection IDs and server IP address family, address, and port are associated with this context. CCIDL: Length of the Client Connection ID field. Client Connection ID: The client connection ID associated with this compression context. SCIDL: Length of the Server Connection ID field. Schinazi Expires 13 September 2021 [Page 7] Internet-Draft MASQUE March 2021 Server Connection ID: The server connection ID associated with this compression context. Server Port Number: The UDP port number used by the server. Family: The IP address family of the Server IP Address field. Can be either 4 or 6. Server IP Address: The IP address of the server. This field is 32 bits long if Family is 4 and 128 bits long if Family is 6. Byte 1: The first byte of the QUIC packet being transferred. Version: The QUIC version in the long header of the QUIC packet being transferred. This field is present if and only if the first bit of the Byte 1 field is set. QUIC Payload: The contents of the QUIC packet being transmitted, starting after the last byte of last connection ID field. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow Identifier (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Byte 1 (8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + [Version (32)] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + QUIC Payload (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Validated QUIC Proxy Datagram Validated QUIC Proxy DATAGRAM frames contain the following fields: Flow Identifier: The flow identifier represents the compression context used by this frame. Validated compression contexts MUST NOT use the "new_quic_proxy_compression_context_flow_id" value received during negotiation. Byte 1: The first byte of the QUIC packet being transferred. Version: The QUIC version in the long header of the QUIC packet being transferred. This field is present if and only if the first bit of the Byte 1 field is set. QUIC Payload: The contents of the QUIC packet being transmitted, Schinazi Expires 13 September 2021 [Page 8] Internet-Draft MASQUE March 2021 starting after the last byte of last connection ID field. 3.3.4. QUIC Proxy Routing A MASQUE server keeps a mapping from client connection IDs to MASQUE clients, so that it can correctly route return packets. When a MASQUE server receives a QUIC Proxy DATAGRAM frame, it forwards it to the IP address and UDP port from the corresponding compression context. Additionally, the MASQUE server will ensure that the client connection ID from that compression context maps to that MASQUE client. TODO: garbage collect this mapping from client connection ID to MASQUE client. 3.4. UDP Proxying In order to support WebRTC to further servers, clients need a way to relay UDP onwards to a remote server. In practice for most widely deployed protocols other than DNS, this involves many datagrams over the same ports. Therefore this mechanism can compress the server's IP address and UDP port to reduce overhead. 3.4.1. UDP Proxy Compression UDP Proxy leverages compression similarly to QUIC proxying, except that it only compresses the IP address and port, not QUIC connection IDs. 3.4.2. UDP Proxy Negotiation Use of the UDP Proxying MASQUE application is negotiated by sending the "udp_proxying" (type 0x03) type-length-value during MASQUE negotiation. The value contains a single variable-length integer, called "new_udp_proxy_compression_context_flow_id", that represents the DATAGRAM flow ID used to negotiate compression contexts. 3.4.3. UDP Proxy Encoding Once negotiated, the UDP Proxying MASQUE Application only uses DATAGRAM frames, whose content is shown in Figure 5 and Figure 6. Schinazi Expires 13 September 2021 [Page 9] Internet-Draft MASQUE March 2021 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow Identifier (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New Compression Context ID (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Server Port Number (16) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Family (8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Server IP Address (32/128) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + UDP Payload (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Unvalidated UDP Proxy Datagram Unvalidated UDP Proxy DATAGRAM frames contain the following fields: Flow Identifier: The flow identifier represents the compression context used by this frame. Unvalidated compression contexts use the "new_udp_proxy_compression_context_flow_id" value received during negotiation. New Compression Context ID: The new Compression Context ID that this frame uses. The server IP address family, address, and port are associated with this context. Server Port Number: The UDP port number used by the server. Family: The IP address family of the Server IP Address field. Can be either 4 or 6. Server IP Address: The IP address of the server. This field is 32 bits long if Family is 4 and 128 bits long if Family is 6. UDP Payload: The contents of the UDP packet being transmitted, starting after the last byte of the UDP checksum field. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow Identifier (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + UDP Payload (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Schinazi Expires 13 September 2021 [Page 10] Internet-Draft MASQUE March 2021 Figure 6: Validated UDP Proxy Datagram Validated UDP Proxy DATAGRAM frames contain the following fields: Flow Identifier: The flow identifier represents the compression context used by this frame. Validated compression contexts MUST NOT use the "new_udp_proxy_compression_context_flow_id" value received during negotiation. UDP Payload: The contents of the UDP packet being transmitted, starting after the last byte of the UDP checksum field. 3.5. IP Proxying For the rare cases where the previous mechanisms are not sufficient, proxying can be performed at the IP layer. This would use a different DATAGRAM_ID and IP datagrams would be encoded inside it without framing. 3.5.1. IP Proxy Negotiation Use of the IP Proxying MASQUE application is negotiated by sending the "ip_proxying" (type 0x04) type-length-value during MASQUE negotiation. The value contains a single variable-length integer, called "ip_proxy_flow_id", that represents the DATAGRAM flow ID used by IP Proxying DATAGRAM frames. 3.5.2. IP Proxy Encoding Once negotiated, the IP Proxying MASQUE Application only uses DATAGRAM frames, whose content is shown in Figure 7. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow Identifier (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + IP Packet (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: IP Proxy Datagram IP Proxy DATAGRAM frames contain the following fields: Flow Identifier: The flow identifier MUST be set to the "ip_proxy_flow_id" value received during negotiation. Schinazi Expires 13 September 2021 [Page 11] Internet-Draft MASQUE March 2021 IP Packet: The full IP packet, starting from the IP Version field. 3.6. Service Registration MASQUE can be used to make a home server accessible on the wide area. The home server authenticates to the MASQUE server and registers a domain name it wishes to serve. The MASQUE server can then forward any traffic it receives for that domain name (by inspecting the TLS Server Name Indication (SNI) extension) to the home server. This received traffic is not authenticated and it allows non-modified clients to communicate with the home server without knowing it is not colocated with the MASQUE server. To help obfuscate the home server, deployments can use Encrypted Server Name Indication [ESNI]. That will require the MASQUE server sending the cleartext SNI to the home server. TODO: define the wire format for Service Registration. 4. Security Considerations Here be dragons. TODO: slay the dragons. 5. IANA Considerations 5.1. MASQUE Well-Known URI This document will request IANA to register the "/.well-known/ masque/" URI (expert review) https://www.iana.org/assignments/well- known-uris/well-known-uris.xhtml (https://www.iana.org/assignments/ well-known-uris/well-known-uris.xhtml). 5.2. MASQUE Applications Registry This document will request IANA to create a new MASQUE Applications registry which governs a 62-bit space of MASQUE application types. This registry follows the same registration policy as the QUIC Transport Parameter Registry; see the IANA Considerations section of [QUIC]. The initial contents of this registry are shown in Table 1: Schinazi Expires 13 September 2021 [Page 12] Internet-Draft MASQUE March 2021 +=======+================+===============+ | Value | Parameter Name | Specification | +=======+================+===============+ | 0x00 | http_proxying | Section 3.1 | +-------+----------------+---------------+ | 0x01 | dns_over_https | Section 3.2 | +-------+----------------+---------------+ | 0x02 | quic_proxying | Section 3.3 | +-------+----------------+---------------+ | 0x03 | udp_proxying | Section 3.4 | +-------+----------------+---------------+ | 0x04 | ip_proxying | Section 3.5 | +-------+----------------+---------------+ Table 1: Initial MASQUE Applications Entries 6. References 6.1. Normative References [DGRAM] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable Datagram Extension to QUIC", Work in Progress, Internet- Draft, draft-ietf-quic-datagram-02, 16 February 2021, . [DOH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . [H3DGRAM] Schinazi, D., "Using QUIC Datagrams with HTTP/3", Work in Progress, Internet-Draft, draft-schinazi-quic-h3-datagram- 05, 12 October 2020, . [HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- quic-http-34, 2 February 2021, . [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", Work in Progress, Internet-Draft, draft-ietf-quic-transport-34, 14 January 2021, . Schinazi Expires 13 September 2021 [Page 13] Internet-Draft MASQUE March 2021 [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, . 6.2. Informative References [ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS Encrypted Client Hello", Work in Progress, Internet-Draft, draft-ietf-tls-esni-10, 8 March 2021, . Acknowledgments This proposal was inspired directly or indirectly by prior work from many people. The author would like to thank Nick Harper, Christian Huitema, Marcus Ihlar, Eric Kinnear, Mirja Kuehlewind, Brendan Moran, Lucas Pardue, Tommy Pauly, Zaheduzzaman Sarker, Ben Schwartz, and Christopher A. Wood for their input. Author's Address David Schinazi Google LLC 1600 Amphitheatre Parkway Mountain View, California 94043, United States of America Email: dschinazi.ietf@gmail.com Schinazi Expires 13 September 2021 [Page 14]