idnits 2.17.1 draft-ietf-masque-connect-udp-08.txt: -(623): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 6 characters in excess of 72. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (21 March 2022) is 759 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. 'H1' -- Possible downref: Normative reference to a draft: ref. 'HTTP' == Outdated reference: A later version (-11) exists of draft-ietf-masque-h3-datagram-07 ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MASQUE D. Schinazi 3 Internet-Draft Google LLC 4 Intended status: Standards Track 21 March 2022 5 Expires: 22 September 2022 7 UDP Proxying Support for HTTP 8 draft-ietf-masque-connect-udp-08 10 Abstract 12 This document describes how to proxy UDP over HTTP. Similar to how 13 the CONNECT method allows proxying TCP over HTTP, this document 14 defines a new mechanism to proxy UDP. It is built using HTTP 15 Extended CONNECT. 17 Discussion Venues 19 This note is to be removed before publishing as an RFC. 21 Discussion of this document takes place on the MASQUE WG mailing list 22 (masque@ietf.org), which is archived at 23 https://mailarchive.ietf.org/arch/browse/masque/. 25 Source for this draft and an issue tracker can be found at 26 https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 22 September 2022. 45 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 63 2. Configuration of Clients . . . . . . . . . . . . . . . . . . 3 64 3. HTTP Exchanges . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. Proxy Handling . . . . . . . . . . . . . . . . . . . . . 4 66 3.2. HTTP Request over HTTP/1.1 . . . . . . . . . . . . . . . 5 67 3.3. HTTP Response over HTTP/1.1 . . . . . . . . . . . . . . . 6 68 3.4. HTTP Request over HTTP/2 and HTTP/3 . . . . . . . . . . . 7 69 3.5. HTTP Response over HTTP/2 and HTTP/3 . . . . . . . . . . 7 70 3.6. Note About Draft Versions . . . . . . . . . . . . . . . . 8 71 4. Context Identifiers . . . . . . . . . . . . . . . . . . . . . 8 72 5. HTTP Datagram Payload Format . . . . . . . . . . . . . . . . 9 73 6. Performance Considerations . . . . . . . . . . . . . . . . . 10 74 6.1. MTU Considerations . . . . . . . . . . . . . . . . . . . 10 75 6.2. Tunneling of ECN Marks . . . . . . . . . . . . . . . . . 11 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 8.1. HTTP Upgrade Token . . . . . . . . . . . . . . . . . . . 11 79 8.2. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 12 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 82 9.2. Informative References . . . . . . . . . . . . . . . . . 14 83 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 86 1. Introduction 88 This document describes how to proxy UDP over HTTP. Similar to how 89 the CONNECT method (see Section 9.3.6 of [HTTP]) allows proxying TCP 90 [TCP] over HTTP, this document defines a new mechanism to proxy UDP 91 [UDP]. 93 UDP Proxying supports all versions of HTTP and uses HTTP Datagrams 94 [HTTP-DGRAM]. When using HTTP/2 or HTTP/3, UDP proxying uses HTTP 95 Extended CONNECT as described in [EXT-CONNECT2] and [EXT-CONNECT3]. 96 When using HTTP/1.x, UDP proxying uses HTTP Upgrade as defined in 97 Section 7.8 of [HTTP]. 99 1.1. Conventions and Definitions 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in 104 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. 107 In this document, we use the term "proxy" to refer to the HTTP server 108 that opens the UDP socket and responds to the UDP proxying request. 109 If there are HTTP intermediaries (as defined in Section 3.7 of 110 [HTTP]) between the client and the proxy, those are referred to as 111 "intermediaries" in this document. 113 Note that, when the HTTP version in use does not support multiplexing 114 streams (such as HTTP/1.1), any reference to "stream" in this 115 document represents the entire connection. 117 2. Configuration of Clients 119 Clients are configured to use UDP Proxying over HTTP via an URI 120 Template [TEMPLATE] with the variables "target_host" and 121 "target_port". Examples are shown below: 123 https://masque.example.org/.well-known/masque/udp/{target_host}/{target_port}/ 124 https://proxy.example.org:4443/masque?h={target_host}&p={target_port} 125 https://proxy.example.org:4443/masque{?target_host,target_port} 127 Figure 1: URI Template Examples 129 The URI template MUST be a level 3 template or lower. The URI 130 template MUST be in absolute form, and MUST include non-empty scheme, 131 authority and path components. The path component of the URI 132 template MUST start with a slash "/". All template variables MUST be 133 within the path component of the URI. The URI template MUST contain 134 the two variables "target_host" and "target_port" and MAY contain 135 other variables. The URI template MUST NOT contain any non-ASCII 136 unicode characters and MUST only contain ASCII characters in the 137 range 0x21-0x7E inclusive (note that percent-encoding is allowed). 138 The URI template MUST NOT use Reserved Expansion ("+" operator), 139 Fragment Expansion ("#" operator), Label Expansion with Dot-Prefix, 140 Path Segment Expansion with Slash-Prefix, nor Path-Style Parameter 141 Expansion with Semicolon-Prefix. If any of the requirements above 142 are not met by a URI template, the client MUST reject its 143 configuration and fail the request without sending it to the proxy. 145 Since the original HTTP CONNECT method allowed conveying the target 146 host and port but not the scheme, proxy authority, path, nor query, 147 there exist proxy configuration interfaces that only allow the user 148 to configure the proxy host and the proxy port. Client 149 implementations of this specification that are constrained by such 150 limitations MUST use the default template which is defined as: 151 "https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/ 152 udp/{target_host}/{target_port}/" where $PROXY_HOST and $PROXY_PORT 153 are the configured host and port of the proxy respectively. Proxy 154 deployments SHOULD use the default template to facilitate 155 interoperability with such clients. 157 3. HTTP Exchanges 159 This document defines the "connect-udp" HTTP Upgrade Token. "connect- 160 udp" uses the Capsule Protocol as defined in [HTTP-DGRAM]. 162 A "connect-udp" request requests that the recipient proxy establish a 163 tunnel over a single HTTP stream to the destination target identified 164 by the "target_host" and "target_port" variables of the URI template 165 (see Section 2). If the request is successful, the proxy commits to 166 converting received HTTP Datagrams into UDP packets and vice versa 167 until the tunnel is closed. Tunnels are commonly used to create an 168 end-to-end virtual connection, which can then be secured using QUIC 169 [QUIC] or another protocol running over UDP. 171 When sending its UDP proxying request, the client SHALL perform URI 172 template expansion to determine the path and query of its request. 173 target_host supports using DNS names, IPv6 literals and IPv4 174 literals. Note that this URI template expansion requires using pct- 175 encoding, so for example if the target_host is "2001:db8::42", it 176 will be encoded in the URI as "2001%3Adb8%3A%3A42". 178 A payload within a UDP proxying request message has no defined 179 semantics; a UDP proxying request with a non-empty payload is 180 malformed. 182 Responses to UDP proxying requests are not cacheable. 184 3.1. Proxy Handling 186 Upon receiving a UDP proxying request, the recipient proxy extracts 187 the "target_host" and "target_port" variables from the URI it has 188 reconstructed from the request headers, and establishes a tunnel by 189 directly opening a UDP socket to the requested target. 191 Unlike TCP, UDP is connection-less. The proxy that opens the UDP 192 socket has no way of knowing whether the destination is reachable. 193 Therefore it needs to respond to the request without waiting for a 194 packet from the target. However, if the target_host is a DNS name, 195 the proxy MUST perform DNS resolution before replying to the HTTP 196 request. If DNS resolution fails, the proxy MUST fail the request 197 and SHOULD send details using the Proxy-Status header [PROXY-STATUS]. 199 Proxies can use connected UDP sockets if their operating system 200 supports them, as that allows the proxy to rely on the kernel to only 201 send it UDP packets that match the correct 5-tuple. If the proxy 202 uses a non-connected socket, it MUST validate the IP source address 203 and UDP source port on received packets to ensure they match the 204 client's request. Packets that do not match MUST be discarded by the 205 proxy. 207 The lifetime of the socket is tied to the request stream. The proxy 208 MUST keep the socket open while the request stream is open. If a 209 proxy is notified by its operating system that its socket is no 210 longer usable (for example, this can happen when an ICMP "Destination 211 Unreachable" message is received, see Section 3.1 of [ICMP6]), it 212 MUST close the request stream. Proxies MAY choose to close sockets 213 due to a period of inactivity, but they MUST close the request stream 214 when closing the socket. Proxies that close sockets after a period 215 of inactivity SHOULD NOT use a period lower than two minutes, see 216 Section 4.3 of [BEHAVE]. 218 A successful response (as defined in Section 3.3 and Section 3.5) 219 indicates that the proxy has opened a socket to the requested target 220 and is willing to proxy UDP payloads. Any response other than a 221 successful response indicates that the request has failed, and the 222 client MUST therefore abort the request. 224 Proxies MUST NOT introduce fragmentation at the IP layer when 225 forwarding HTTP Datagrams onto a UDP socket. In IPv4, the Don't 226 Fragment (DF) bit MUST be set if possible, to prevent fragmentation 227 on the path. Future extensions MAY remove these requirements. 229 3.2. HTTP Request over HTTP/1.1 231 When using HTTP/1.1, a UDP proxying request will meet the following 232 requirements: 234 * the method SHALL be "GET". 236 * the request-target SHALL use absolute-form (see Section 3.2.2 of 237 [H1]). 239 * the request SHALL include a single Host header containing the 240 origin of the proxy. 242 * the request SHALL include a single "Connection" header with value 243 "Upgrade". 245 * the request SHALL include a single "Upgrade" header with value 246 "connect-udp". 248 For example, if the client is configured with URI template 249 "https://proxy.example.org/.well-known/masque/ 250 udp/{target_host}/{target_port}/" and wishes to open a UDP proxying 251 tunnel to target 192.0.2.42:443, it could send the following request: 253 GET https://proxy.example.org/.well-known/masque/udp/192.0.2.42/443/ HTTP/1.1 254 Host: proxy.example.org 255 Connection: upgrade 256 Upgrade: connect-udp 258 Figure 2: Example HTTP Request over HTTP/1.1 260 3.3. HTTP Response over HTTP/1.1 262 The proxy SHALL indicate a successful response by replying with the 263 following requirements: 265 * the HTTP status code on the response SHALL be 101 (Switching 266 Protocols). 268 * the reponse SHALL include a single "Connection" header with value 269 "Upgrade". 271 * the response SHALL include a single "Upgrade" header with value 272 "connect-udp". 274 * the response SHALL NOT include any Transfer-Encoding or Content- 275 Length header fields. 277 If any of these requirements are not met, the client MUST treat this 278 proxying attempt as failed and abort the connection. 280 For example, the proxy could respond with: 282 HTTP/1.1 101 Switching Protocols 283 Connection: upgrade 284 Upgrade: connect-udp 286 Figure 3: Example HTTP Response over HTTP/1.1 288 3.4. HTTP Request over HTTP/2 and HTTP/3 290 When using HTTP/2 [H2] or HTTP/3 [H3], UDP proxying requests use HTTP 291 pseudo-headers with the following requirements: 293 * The ":method" pseudo-header field SHALL be "CONNECT". 295 * The ":protocol" pseudo-header field SHALL be "connect-udp". 297 * The ":authority" pseudo-header field SHALL contain the authority 298 of the proxy. 300 * The ":path" and ":scheme" pseudo-header fields SHALL NOT be empty. 301 Their values SHALL contain the scheme and path from the URI 302 template after the URI template expansion process has been 303 completed. 305 A UDP proxying request that does not conform to these restrictions is 306 malformed (see Section 8.1.1 of [H2]). 308 For example, if the client is configured with URI template 309 "https://proxy.example.org/{target_host}/{target_port}/" and wishes 310 to open a UDP proxying tunnel to target 192.0.2.42:443, it could send 311 the following request: 313 HEADERS 314 :method = CONNECT 315 :protocol = connect-udp 316 :scheme = https 317 :path = /.well-known/masque/udp/192.0.2.42/443/ 318 :authority = proxy.example.org 320 Figure 4: Example HTTP Request over HTTP/2 322 3.5. HTTP Response over HTTP/2 and HTTP/3 324 The proxy SHALL indicate a successful response by replying with any 325 2xx (Successful) HTTP status code, without any Transfer-Encoding or 326 Content-Length header fields. 328 If any of these requirements are not met, the client MUST treat this 329 proxying attempt as failed and abort the request. 331 For example, the proxy could respond with: 333 HEADERS 334 :status = 200 335 Figure 5: Example HTTP Response over HTTP/2 337 3.6. Note About Draft Versions 339 [[RFC editor: please remove this section before publication.]] 341 In order to allow implementations to support multiple draft versions 342 of this specification during its development, we introduce the 343 "connect-udp-version" header. When sent by the client, it contains a 344 list of draft numbers supported by the client (e.g., "connect-udp- 345 version: 0, 2"). When sent by the proxy, it contains a single draft 346 number selected by the proxy from the list provided by the client 347 (e.g., "connect-udp-version: 2"). Sending this header is RECOMMENDED 348 but not required. Its ABNF is: 350 connect-udp-version = sf-list 352 4. Context Identifiers 354 This protocol allows future extensions to exchange HTTP Datagrams 355 which carry different semantics from UDP payloads. Some of these 356 extensions can augment UDP payloads with additional data, while 357 others can exchange data that is completely separate from UDP 358 payloads. In order to accomplish this, all HTTP Datagrams associated 359 with UDP Proxying request streams start with a context ID, see 360 Section 5. 362 Context IDs are 62-bit integers (0 to 2^62-1). Context IDs are 363 encoded as variable-length integers, see Section 16 of [QUIC]. The 364 context ID value of 0 is reserved for UDP payloads, while non-zero 365 values are dynamically allocated: non-zero even-numbered context IDs 366 are client-allocated, and odd-numbered context IDs are proxy- 367 allocated. The context ID namespace is tied to a given HTTP request: 368 it is possible for a context ID with the same numeric value to be 369 simultaneously assigned different semantics in distinct requests, 370 potentially with different semantics. Context IDs MUST NOT be re- 371 allocated within a given HTTP namespace but MAY be allocated in any 372 order. Once allocated, any context ID can be used by both client and 373 proxy - only allocation carries separate namespaces to avoid 374 requiring synchronization. 376 Registration is the action by which an endpoint informs its peer of 377 the semantics and format of a given context ID. This document does 378 not define how registration occurs. Future extensions MAY use HTTP 379 headers or capsules to register contexts. Depending on the method 380 being used, it is possible for datagrams to be received with Context 381 IDs which have not yet been registered, for instance due to 382 reordering of the datagram and the registration packets during 383 transmission. 385 5. HTTP Datagram Payload Format 387 When associated with UDP proxying request streams, the HTTP Datagram 388 Payload field of HTTP Datagrams (see [HTTP-DGRAM]) has the format 389 defined in Figure 6. Note that when HTTP Datagrams are encoded using 390 QUIC DATAGRAM frames, the Context ID field defined below directly 391 follows the Quarter Stream ID field which is at the start of the QUIC 392 DATAGRAM frame payload: 394 UDP Proxying HTTP Datagram Payload { 395 Context ID (i), 396 Payload (..), 397 } 399 Figure 6: UDP Proxying HTTP Datagram Format 401 Context ID: A variable-length integer that contains the value of the 402 Context ID. If an HTTP/3 datagram which carries an unknown 403 Context ID is received, the receiver SHALL either drop that 404 datagram silently or buffer it temporarily (on the order of a 405 round trip) while awaiting the registration of the corresponding 406 Context ID. 408 Payload: The payload of the datagram, whose semantics depend on 409 value of the previous field. Note that this field can be empty. 411 UDP packets are encoded using HTTP Datagrams with the Context ID set 412 to zero. When the Context ID is set to zero, the Payload field 413 contains the unmodified payload of a UDP packet (referred to as "data 414 octets" in [UDP]). 416 Clients MAY optimistically start sending proxied UDP packets before 417 receiving the response to its UDP proxying request, noting however 418 that those may not be processed by the proxy if it responds to the 419 request with a failure, or if the datagrams are received by the proxy 420 before the request. 422 Endpoints MUST NOT send HTTP Datagrams with payloads longer than 423 65527 using Context ID zero. An endpoint that receives a DATAGRAM 424 capsule using Context ID zero whose payload is longer than 65527 MUST 425 abort the stream. If a proxy knows it can only send out UDP packets 426 of a certain length due to its underlying link MTU, it SHOULD discard 427 incoming DATAGRAM capsules using Context ID zero whose payload is 428 longer than that limit without buffering the capsule contents. 430 6. Performance Considerations 432 Proxies SHOULD strive to avoid increasing burstiness of UDP traffic: 433 they SHOULD NOT queue packets in order to increase batching. 435 When the protocol running over UDP that is being proxied uses 436 congestion control (e.g., [QUIC]), the proxied traffic will incur at 437 least two nested congestion controllers. This can reduce performance 438 but the underlying HTTP connection MUST NOT disable congestion 439 control unless it has an out-of-band way of knowing with absolute 440 certainty that the inner traffic is congestion-controlled. 442 If a client or proxy with a connection containing a UDP proxying 443 request stream disables congestion control, it MUST NOT signal ECN 444 support on that connection. That is, it MUST mark all IP headers 445 with the Not-ECT codepoint. It MAY continue to report ECN feedback 446 via ACK_ECN frames, as the peer may not have disabled congestion 447 control. 449 When the protocol running over UDP that is being proxied uses loss 450 recovery (e.g., [QUIC]), and the underlying HTTP connection runs over 451 TCP, the proxied traffic will incur at least two nested loss recovery 452 mechanisms. This can reduce performance as both can sometimes 453 independently retransmit the same data. To avoid this, UDP proxying 454 SHOULD be performed over HTTP/3 to allow leveraging the QUIC DATAGRAM 455 frame. 457 6.1. MTU Considerations 459 When using HTTP/3 with the QUIC Datagram extension [DGRAM], UDP 460 payloads are transmitted in QUIC DATAGRAM frames. Since those cannot 461 be fragmented, they can only carry payloads up to a given length 462 determined by the QUIC connection configuration and the path MTU. If 463 a proxy is using QUIC DATAGRAM frames and it receives a UDP payload 464 from the target that will not fit inside a QUIC DATAGRAM frame, the 465 proxy SHOULD NOT send the UDP payload in a DATAGRAM capsule, as that 466 defeats the end-to-end unreliability characteristic that methods such 467 as Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) depend 468 on [DPLPMTUD]. In this scenario, the proxy SHOULD drop the UDP 469 payload and send an ICMP "Packet Too Big" message to the target, see 470 Section 3.2 of [ICMP6]. 472 6.2. Tunneling of ECN Marks 474 UDP proxying does not create an IP-in-IP tunnel, so the guidance in 475 [ECN-TUNNEL] about transferring ECN marks between inner and outer IP 476 headers does not apply. There is no inner IP header in UDP proxying 477 tunnels. 479 Note that UDP proxying clients do not have the ability in this 480 specification to control the ECN codepoints on UDP packets the proxy 481 sends to the target, nor can proxies communicate the markings of each 482 UDP packet from target to proxy. 484 A UDP proxy MUST ignore ECN bits in the IP header of UDP packets 485 received from the target, and MUST set the ECN bits to Not-ECT on UDP 486 packets it sends to the target. These do not relate to the ECN 487 markings of packets sent between client and proxy in any way. 489 7. Security Considerations 491 There are significant risks in allowing arbitrary clients to 492 establish a tunnel to arbitrary targets, as that could allow bad 493 actors to send traffic and have it attributed to the proxy. Proxies 494 that support UDP proxying SHOULD restrict its use to authenticated 495 users. 497 Because the CONNECT method creates a TCP connection to the target, 498 the target has to indicate its willingness to accept TCP connections 499 by responding with a TCP SYN-ACK before the proxy can send it 500 application data. UDP doesn't have this property, so a UDP proxy 501 could send more data to an unwilling target than a CONNECT proxy. 502 However, in practice denial of service attacks target open TCP ports 503 so the TCP SYN-ACK does not offer much protection in real scenarios. 505 8. IANA Considerations 507 8.1. HTTP Upgrade Token 509 This document will request IANA to register "connect-udp" in the HTTP 510 Upgrade Token Registry maintained at 511 . 513 Value: connect-udp 515 Description: Proxying of UDP Payloads 517 Expected Version Tokens: None 518 Reference: This document 520 8.2. Well-Known URI 522 This document will request IANA to register "masque/udp" in the Well- 523 Known URIs Registry maintained at . 526 URI Suffix: masque/udp 528 Change Controller: IETF 530 Reference: This document 532 Status: permanent (if this document is approved) 534 Related Information: Includes all resources identified with the path 535 prefix "/.well-known/masque/udp/" 537 9. References 539 9.1. Normative References 541 [DGRAM] Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 542 Datagram Extension to QUIC", Work in Progress, Internet- 543 Draft, draft-ietf-quic-datagram-10, 4 February 2022, 544 . 547 [EXT-CONNECT2] 548 McManus, P., "Bootstrapping WebSockets with HTTP/2", 549 RFC 8441, DOI 10.17487/RFC8441, September 2018, 550 . 552 [EXT-CONNECT3] 553 Hamilton, R., "Bootstrapping WebSockets with HTTP/3", Work 554 in Progress, Internet-Draft, draft-ietf-httpbis-h3- 555 websockets-04, 8 February 2022, 556 . 559 [H1] Fielding, R. T., Nottingham, M., and J. Reschke, 560 "HTTP/1.1", Work in Progress, Internet-Draft, draft-ietf- 561 httpbis-messaging-19, 12 September 2021, 562 . 565 [H2] Thomson, M. and C. Benfield, "HTTP/2", Work in Progress, 566 Internet-Draft, draft-ietf-httpbis-http2bis-07, 24 January 567 2022, . 570 [H3] Bishop, M., "Hypertext Transfer Protocol Version 3 571 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 572 quic-http-34, 2 February 2021, 573 . 576 [HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 577 Semantics", Work in Progress, Internet-Draft, draft-ietf- 578 httpbis-semantics-19, 12 September 2021, 579 . 582 [HTTP-DGRAM] 583 Schinazi, D. and L. Pardue, "Using Datagrams with HTTP", 584 Work in Progress, Internet-Draft, draft-ietf-masque-h3- 585 datagram-07, 21 March 2022, 586 . 589 [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 590 Multiplexed and Secure Transport", RFC 9000, 591 DOI 10.17487/RFC9000, May 2021, 592 . 594 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 595 Requirement Levels", BCP 14, RFC 2119, 596 DOI 10.17487/RFC2119, March 1997, 597 . 599 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 600 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 601 May 2017, . 603 [TCP] Postel, J., "Transmission Control Protocol", STD 7, 604 RFC 793, DOI 10.17487/RFC0793, September 1981, 605 . 607 [TEMPLATE] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 608 and D. Orchard, "URI Template", RFC 6570, 609 DOI 10.17487/RFC6570, March 2012, 610 . 612 [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 613 DOI 10.17487/RFC0768, August 1980, 614 . 616 9.2. Informative References 618 [BEHAVE] Audet, F., Ed. and C. Jennings, "Network Address 619 Translation (NAT) Behavioral Requirements for Unicast 620 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 621 2007, . 623 [DPLPMTUD] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. 624 Völker, "Packetization Layer Path MTU Discovery for 625 Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, 626 September 2020, . 628 [ECN-TUNNEL] 629 Briscoe, B., "Tunnelling of Explicit Congestion 630 Notification", RFC 6040, DOI 10.17487/RFC6040, November 631 2010, . 633 [ICMP6] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 634 Control Message Protocol (ICMPv6) for the Internet 635 Protocol Version 6 (IPv6) Specification", STD 89, 636 RFC 4443, DOI 10.17487/RFC4443, March 2006, 637 . 639 [PROXY-STATUS] 640 Nottingham, M. and P. Sikora, "The Proxy-Status HTTP 641 Response Header Field", Work in Progress, Internet-Draft, 642 draft-ietf-httpbis-proxy-status-08, 13 October 2021, 643 . 646 Acknowledgments 648 This document is a product of the MASQUE Working Group, and the 649 author thanks all MASQUE enthusiasts for their contibutions. This 650 proposal was inspired directly or indirectly by prior work from many 651 people. In particular, the author would like to thank Eric Rescorla 652 for suggesting to use an HTTP method to proxy UDP. Thanks to Lucas 653 Pardue for their inputs on this document. The extensibility design 654 in this document came out of the HTTP Datagrams Design Team, whose 655 members were Alan Frindell, Alex Chernyakhovsky, Ben Schwartz, Eric 656 Rescorla, Lucas Pardue, Marcus Ihlar, Martin Thomson, Mike Bishop, 657 Tommy Pauly, Victor Vasiliev, and the author of this document. 659 Author's Address 661 David Schinazi 662 Google LLC 663 1600 Amphitheatre Parkway 664 Mountain View, California 94043, 665 United States of America 666 Email: dschinazi.ietf@gmail.com