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