idnits 2.17.1 draft-schinazi-masque-protocol-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (12 March 2021) is 1134 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-quic-datagram-02 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-10 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Schinazi 3 Internet-Draft Google LLC 4 Intended status: Experimental 12 March 2021 5 Expires: 13 September 2021 7 The MASQUE Protocol 8 draft-schinazi-masque-protocol-03 10 Abstract 12 This document describes MASQUE (Multiplexed Application Substrate 13 over QUIC Encryption). MASQUE is a framework that allows 14 concurrently running multiple networking applications inside an 15 HTTP/3 connection. For example, MASQUE can allow a QUIC client to 16 negotiate proxying capability with an HTTP/3 server, and subsequently 17 make use of this functionality while concurrently processing HTTP/3 18 requests and responses. 20 Discussion of this work is encouraged to happen on the MASQUE IETF 21 mailing list masque@ietf.org or on the GitHub repository which 22 contains the draft: https://github.com/DavidSchinazi/masque-drafts. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 13 September 2021. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 59 2. MASQUE Negotiation . . . . . . . . . . . . . . . . . . . . . 3 60 3. MASQUE Applications . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. HTTP Proxy . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1.1. HTTP Proxy Negotiation . . . . . . . . . . . . . . . 4 63 3.2. DNS over HTTPS . . . . . . . . . . . . . . . . . . . . . 4 64 3.2.1. DNS over HTTPS Negotiation . . . . . . . . . . . . . 5 65 3.3. QUIC Proxying . . . . . . . . . . . . . . . . . . . . . . 5 66 3.3.1. QUIC Proxy Compression . . . . . . . . . . . . . . . 5 67 3.3.2. QUIC Proxy Negotiation . . . . . . . . . . . . . . . 6 68 3.3.3. QUIC Proxy Encoding . . . . . . . . . . . . . . . . . 6 69 3.3.4. QUIC Proxy Routing . . . . . . . . . . . . . . . . . 9 70 3.4. UDP Proxying . . . . . . . . . . . . . . . . . . . . . . 9 71 3.4.1. UDP Proxy Compression . . . . . . . . . . . . . . . . 9 72 3.4.2. UDP Proxy Negotiation . . . . . . . . . . . . . . . . 9 73 3.4.3. UDP Proxy Encoding . . . . . . . . . . . . . . . . . 9 74 3.5. IP Proxying . . . . . . . . . . . . . . . . . . . . . . . 11 75 3.5.1. IP Proxy Negotiation . . . . . . . . . . . . . . . . 11 76 3.5.2. IP Proxy Encoding . . . . . . . . . . . . . . . . . . 11 77 3.6. Service Registration . . . . . . . . . . . . . . . . . . 12 78 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 5.1. MASQUE Well-Known URI . . . . . . . . . . . . . . . . . . 12 81 5.2. MASQUE Applications Registry . . . . . . . . . . . . . . 12 82 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 6.1. Normative References . . . . . . . . . . . . . . . . . . 13 84 6.2. Informative References . . . . . . . . . . . . . . . . . 14 85 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 88 1. Introduction 90 This document describes MASQUE (Multiplexed Application Substrate 91 over QUIC Encryption). MASQUE is a framework that allows 92 concurrently running multiple networking applications inside an 93 HTTP/3 connection (see [HTTP3]). For example, MASQUE can allow a 94 QUIC client to negotiate proxying capability with an HTTP/3 server, 95 and subsequently make use of this functionality while concurrently 96 processing HTTP/3 requests and responses. 98 MASQUE Negotiation is performed using HTTP mechanisms, but MASQUE 99 applications can subsequently leverage QUIC [QUIC] features without 100 using HTTP. 102 Discussion of this work is encouraged to happen on the MASQUE IETF 103 mailing list masque@ietf.org or on the GitHub repository which 104 contains the draft: https://github.com/DavidSchinazi/masque-drafts. 106 1.1. Conventions and Definitions 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 2. MASQUE Negotiation 116 In order to negotiate the use of the MASQUE protocol, the client 117 starts by sending a MASQUE request in the HTTP data of an HTTP POST 118 request to "/.well-known/masque/initial". The client can use this to 119 request specific MASQUE applications and advertise support for MASQUE 120 extensions. The MASQUE server indicates support for MASQUE by 121 sending an HTTP status code 200 response, and can use the data to 122 inform the client of which MASQUE applications are now in use, and 123 various configuration parameters. 125 Both the MASQUE negotiation initial request and its response carry a 126 sequence of MASQUE applications, as shown in Figure 1: 128 0 1 2 3 129 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 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | MASQUE Application 1 (*) ... 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | MASQUE Application 2 (*) ... 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 ... 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | MASQUE Application N (*) ... 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 Figure 1: Sequence of MASQUE Applications 142 Each MASQUE Application is encoded as an (identifier, length, value) 143 tuple, as shown in Figure 2: 145 0 1 2 3 146 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 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | MASQUE Application ID (i) ... 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | MASQUE Application Length (i) ... 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | MASQUE Application Value (*) ... 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 Figure 2: MASQUE Application Encoding 157 The MASQUE Application Length field contains the length of the MASQUE 158 Application Value field. The contents of the MASQUE Application 159 Value field are defined by its corresponding MASQUE application. 160 When parsing, endpoints MUST ignore unknown MASQUE applications. A 161 given MASQUE application ID MUST NOT appear twice in a given sequence 162 of MASQUE applications. 164 3. MASQUE Applications 166 When the MASQUE server accepts the client's MASQUE initial request, 167 it advertises support for MASQUE Applications, which will be 168 multiplexed over this HTTP/3 connection. 170 3.1. HTTP Proxy 172 The client can make proxied HTTP requests through the server to other 173 servers. In practice this will mean using the HTTP CONNECT method to 174 establish a stream over which to run TLS to a different remote 175 destination. The proxy applies back-pressure to streams in both 176 directions. 178 3.1.1. HTTP Proxy Negotiation 180 Use of the HTTP Proxying MASQUE application is negotiated by sending 181 the "http_proxying" (type 0x00) type-length-value during MASQUE 182 negotiation. The length MUST be zero. 184 3.2. DNS over HTTPS 186 The client can send DNS queries using DNS over HTTPS [DOH] to the 187 MASQUE server. 189 3.2.1. DNS over HTTPS Negotiation 191 Use of the DNS over HTTPS MASQUE application is negotiated by sending 192 the "dns_over_https" (type 0x01) type-length-value during MASQUE 193 negotiation. When sent by the client, the length MUST be zero. When 194 sent by the server, the value contains the DoH URI Template encoded 195 as a non-null-terminated UTF-8 string. 197 3.3. QUIC Proxying 199 By leveraging QUIC client connection IDs, a MASQUE server can act as 200 a QUIC proxy while only using one UDP port. To allow this, the 201 MASQUE server informs the client of a required client connection ID 202 length during negotiation. The client is then able to send proxied 203 packets to the MASQUE server who will forward them on to the desired 204 IP address and UDP port. Return packets are similarly forwarded in 205 the opposite direction. 207 Compared to UDP proxying, this mode has the advantage of only 208 requiring one UDP port to be open on the MASQUE server, and can lower 209 the overhead on the link between client and MASQUE server by 210 compressing connection IDs. 212 3.3.1. QUIC Proxy Compression 214 To reduce the overhead of proxying, QUIC Proxying leverages 215 compression to elide the connection IDs on the link between the 216 client and MASQUE server. This uses the concept of a compression 217 context. Compression contexts are indexed using a datagram flow 218 identifiers [H3DGRAM], and contain the tuple (client connection ID, 219 server connection ID, server IP address, server port). 221 Any time and endpoint wants to send a proxied packet to its peer, it 222 searches its list of compression contexts looking for one that 223 matches the address, port and connection IDs from the proxied packet. 224 If there was no match, the endpoint creates a new compression context 225 and adds it to the list. 227 Compression contexts also carry a boolean value representing whether 228 the context has been validated, which means that this endpoint is 229 confident that its peer is aware if the given compression context. 230 Compression contexts that were created by the peer start off 231 validated, whereas locally-created ones are not validated until the 232 endpoint receives a packet using that compression context, or an 233 acknowledgement for a sent packet that uses the context. 235 The DATAGRAM frame [DGRAM] format below allows both endpoints to 236 immediately start sending proxied QUIC packets using unvalidated 237 compression contexts. Once contexts are vaidated, the server IP 238 address, server port and the connection IDs can be ommited. 240 TODO: garbage collect obsolete compression contexts. 242 3.3.2. QUIC Proxy Negotiation 244 Use of the QUIC Proxying MASQUE application is negotiated by sending 245 the "quic_proxying" (type 0x02) type-length-value during MASQUE 246 negotiation. 248 When sent by the client, the value contains a single variable-length 249 integer, called "new_quic_proxy_compression_context_flow_id", that 250 represents the DATAGRAM flow ID used to negotiate compression 251 contexts. 253 When sent by the server, the value contains two variable-length 254 integers, the DATAGRAM flow ID used to negotiate compression contexts 255 (called "new_quic_proxy_compression_context_flow_id"), followed by 256 the required connection ID length. 258 3.3.3. QUIC Proxy Encoding 260 Once negotiated, the QUIC Proxying MASQUE Application only uses 261 DATAGRAM frames, whose content is shown in Figure 3 and Figure 4. 263 0 1 2 3 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Flow Identifier (i) ... 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | New Compression Context ID (i) ... 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | CCIDL (8) | | 271 +-+-+-+-+-+-+-+-+ Client Connection ID (0..160) + 272 | ... 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | SCIDL (8) | | 275 +-+-+-+-+-+-+-+-+ Server Connection ID (0..160) + 276 | ... 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Server Port Number (16) | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Family (8) | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 + Server IP Address (32/128) ... 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Byte 1 (8) | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 + [Version (32)] | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 + QUIC Payload (*) ... 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Figure 3: Unvalidated QUIC Proxy Datagram 293 Unvalidated QUIC Proxy DATAGRAM frames contain the following fields: 295 Flow Identifier: The flow identifier represents the compression 296 context used by this frame. Unvalidated compression contexts use 297 the "new_quic_proxy_compression_context_flow_id" value received 298 during negotiation. 300 New Compression Context ID: The new Compression Context ID that this 301 frame uses. The connection IDs and server IP address family, 302 address, and port are associated with this context. 304 CCIDL: Length of the Client Connection ID field. 306 Client Connection ID: The client connection ID associated with this 307 compression context. 309 SCIDL: Length of the Server Connection ID field. 311 Server Connection ID: The server connection ID associated with this 312 compression context. 314 Server Port Number: The UDP port number used by the server. 316 Family: The IP address family of the Server IP Address field. Can 317 be either 4 or 6. 319 Server IP Address: The IP address of the server. This field is 32 320 bits long if Family is 4 and 128 bits long if Family is 6. 322 Byte 1: The first byte of the QUIC packet being transferred. 324 Version: The QUIC version in the long header of the QUIC packet 325 being transferred. This field is present if and only if the first 326 bit of the Byte 1 field is set. 328 QUIC Payload: The contents of the QUIC packet being transmitted, 329 starting after the last byte of last connection ID field. 331 0 1 2 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Flow Identifier (i) ... 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Byte 1 (8) | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 + [Version (32)] | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 + QUIC Payload (*) ... 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Figure 4: Validated QUIC Proxy Datagram 345 Validated QUIC Proxy DATAGRAM frames contain the following fields: 347 Flow Identifier: The flow identifier represents the compression 348 context used by this frame. Validated compression contexts MUST 349 NOT use the "new_quic_proxy_compression_context_flow_id" value 350 received during negotiation. 352 Byte 1: The first byte of the QUIC packet being transferred. 354 Version: The QUIC version in the long header of the QUIC packet 355 being transferred. This field is present if and only if the first 356 bit of the Byte 1 field is set. 358 QUIC Payload: The contents of the QUIC packet being transmitted, 359 starting after the last byte of last connection ID field. 361 3.3.4. QUIC Proxy Routing 363 A MASQUE server keeps a mapping from client connection IDs to MASQUE 364 clients, so that it can correctly route return packets. When a 365 MASQUE server receives a QUIC Proxy DATAGRAM frame, it forwards it to 366 the IP address and UDP port from the corresponding compression 367 context. Additionally, the MASQUE server will ensure that the client 368 connection ID from that compression context maps to that MASQUE 369 client. 371 TODO: garbage collect this mapping from client connection ID to 372 MASQUE client. 374 3.4. UDP Proxying 376 In order to support WebRTC to further servers, clients need a way to 377 relay UDP onwards to a remote server. In practice for most widely 378 deployed protocols other than DNS, this involves many datagrams over 379 the same ports. Therefore this mechanism can compress the server's 380 IP address and UDP port to reduce overhead. 382 3.4.1. UDP Proxy Compression 384 UDP Proxy leverages compression similarly to QUIC proxying, except 385 that it only compresses the IP address and port, not QUIC connection 386 IDs. 388 3.4.2. UDP Proxy Negotiation 390 Use of the UDP Proxying MASQUE application is negotiated by sending 391 the "udp_proxying" (type 0x03) type-length-value during MASQUE 392 negotiation. 394 The value contains a single variable-length integer, called 395 "new_udp_proxy_compression_context_flow_id", that represents the 396 DATAGRAM flow ID used to negotiate compression contexts. 398 3.4.3. UDP Proxy Encoding 400 Once negotiated, the UDP Proxying MASQUE Application only uses 401 DATAGRAM frames, whose content is shown in Figure 5 and Figure 6. 403 0 1 2 3 404 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 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Flow Identifier (i) ... 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | New Compression Context ID (i) ... 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Server Port Number (16) | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Family (8) | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 + Server IP Address (32/128) ... 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 + UDP Payload (*) ... 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 Figure 5: Unvalidated UDP Proxy Datagram 421 Unvalidated UDP Proxy DATAGRAM frames contain the following fields: 423 Flow Identifier: The flow identifier represents the compression 424 context used by this frame. Unvalidated compression contexts use 425 the "new_udp_proxy_compression_context_flow_id" value received 426 during negotiation. 428 New Compression Context ID: The new Compression Context ID that this 429 frame uses. The server IP address family, address, and port are 430 associated with this context. 432 Server Port Number: The UDP port number used by the server. 434 Family: The IP address family of the Server IP Address field. Can 435 be either 4 or 6. 437 Server IP Address: The IP address of the server. This field is 32 438 bits long if Family is 4 and 128 bits long if Family is 6. 440 UDP Payload: The contents of the UDP packet being transmitted, 441 starting after the last byte of the UDP checksum field. 443 0 1 2 3 444 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 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Flow Identifier (i) ... 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 + UDP Payload (*) ... 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 Figure 6: Validated UDP Proxy Datagram 452 Validated UDP Proxy DATAGRAM frames contain the following fields: 454 Flow Identifier: The flow identifier represents the compression 455 context used by this frame. Validated compression contexts MUST 456 NOT use the "new_udp_proxy_compression_context_flow_id" value 457 received during negotiation. 459 UDP Payload: The contents of the UDP packet being transmitted, 460 starting after the last byte of the UDP checksum field. 462 3.5. IP Proxying 464 For the rare cases where the previous mechanisms are not sufficient, 465 proxying can be performed at the IP layer. This would use a 466 different DATAGRAM_ID and IP datagrams would be encoded inside it 467 without framing. 469 3.5.1. IP Proxy Negotiation 471 Use of the IP Proxying MASQUE application is negotiated by sending 472 the "ip_proxying" (type 0x04) type-length-value during MASQUE 473 negotiation. 475 The value contains a single variable-length integer, called 476 "ip_proxy_flow_id", that represents the DATAGRAM flow ID used by IP 477 Proxying DATAGRAM frames. 479 3.5.2. IP Proxy Encoding 481 Once negotiated, the IP Proxying MASQUE Application only uses 482 DATAGRAM frames, whose content is shown in Figure 7. 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Flow Identifier (i) ... 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 + IP Packet (*) ... 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 Figure 7: IP Proxy Datagram 494 IP Proxy DATAGRAM frames contain the following fields: 496 Flow Identifier: The flow identifier MUST be set to the 497 "ip_proxy_flow_id" value received during negotiation. 499 IP Packet: The full IP packet, starting from the IP Version field. 501 3.6. Service Registration 503 MASQUE can be used to make a home server accessible on the wide area. 504 The home server authenticates to the MASQUE server and registers a 505 domain name it wishes to serve. The MASQUE server can then forward 506 any traffic it receives for that domain name (by inspecting the TLS 507 Server Name Indication (SNI) extension) to the home server. This 508 received traffic is not authenticated and it allows non-modified 509 clients to communicate with the home server without knowing it is not 510 colocated with the MASQUE server. 512 To help obfuscate the home server, deployments can use Encrypted 513 Server Name Indication [ESNI]. That will require the MASQUE server 514 sending the cleartext SNI to the home server. 516 TODO: define the wire format for Service Registration. 518 4. Security Considerations 520 Here be dragons. TODO: slay the dragons. 522 5. IANA Considerations 524 5.1. MASQUE Well-Known URI 526 This document will request IANA to register the "/.well-known/ 527 masque/" URI (expert review) https://www.iana.org/assignments/well- 528 known-uris/well-known-uris.xhtml (https://www.iana.org/assignments/ 529 well-known-uris/well-known-uris.xhtml). 531 5.2. MASQUE Applications Registry 533 This document will request IANA to create a new MASQUE Applications 534 registry which governs a 62-bit space of MASQUE application types. 535 This registry follows the same registration policy as the QUIC 536 Transport Parameter Registry; see the IANA Considerations section of 537 [QUIC]. 539 The initial contents of this registry are shown in Table 1: 541 +=======+================+===============+ 542 | Value | Parameter Name | Specification | 543 +=======+================+===============+ 544 | 0x00 | http_proxying | Section 3.1 | 545 +-------+----------------+---------------+ 546 | 0x01 | dns_over_https | Section 3.2 | 547 +-------+----------------+---------------+ 548 | 0x02 | quic_proxying | Section 3.3 | 549 +-------+----------------+---------------+ 550 | 0x03 | udp_proxying | Section 3.4 | 551 +-------+----------------+---------------+ 552 | 0x04 | ip_proxying | Section 3.5 | 553 +-------+----------------+---------------+ 555 Table 1: Initial MASQUE Applications 556 Entries 558 6. References 560 6.1. Normative References 562 [DGRAM] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 563 Datagram Extension to QUIC", Work in Progress, Internet- 564 Draft, draft-ietf-quic-datagram-02, 16 February 2021, 565 . 567 [DOH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 568 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 569 . 571 [H3DGRAM] Schinazi, D., "Using QUIC Datagrams with HTTP/3", Work in 572 Progress, Internet-Draft, draft-schinazi-quic-h3-datagram- 573 05, 12 October 2020, . 576 [HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3 577 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 578 quic-http-34, 2 February 2021, 579 . 581 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 582 and Secure Transport", Work in Progress, Internet-Draft, 583 draft-ietf-quic-transport-34, 14 January 2021, 584 . 587 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 588 Requirement Levels", BCP 14, RFC 2119, 589 DOI 10.17487/RFC2119, March 1997, 590 . 592 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 593 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 594 May 2017, . 596 6.2. Informative References 598 [ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS 599 Encrypted Client Hello", Work in Progress, Internet-Draft, 600 draft-ietf-tls-esni-10, 8 March 2021, 601 . 603 Acknowledgments 605 This proposal was inspired directly or indirectly by prior work from 606 many people. The author would like to thank Nick Harper, Christian 607 Huitema, Marcus Ihlar, Eric Kinnear, Mirja Kuehlewind, Brendan Moran, 608 Lucas Pardue, Tommy Pauly, Zaheduzzaman Sarker, Ben Schwartz, and 609 Christopher A. Wood for their input. 611 Author's Address 613 David Schinazi 614 Google LLC 615 1600 Amphitheatre Parkway 616 Mountain View, California 94043, 617 United States of America 619 Email: dschinazi.ietf@gmail.com