--- 1/draft-ietf-masque-connect-udp-02.txt 2021-01-05 06:13:31.775689635 -0800 +++ 2/draft-ietf-masque-connect-udp-03.txt 2021-01-05 06:13:31.799690248 -0800 @@ -1,18 +1,18 @@ Network Working Group D. Schinazi Internet-Draft Google LLC -Intended status: Standards Track 30 December 2020 -Expires: 3 July 2021 +Intended status: Standards Track 5 January 2021 +Expires: 9 July 2021 The CONNECT-UDP HTTP Method - draft-ietf-masque-connect-udp-02 + draft-ietf-masque-connect-udp-03 Abstract This document describes the CONNECT-UDP HTTP method. CONNECT-UDP is similar to the HTTP CONNECT method, but it uses UDP instead of TCP. 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/ietf-wg-masque/draft-ietf- masque-connect-udp. @@ -32,56 +32,56 @@ 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 3 July 2021. + This Internet-Draft will expire on 9 July 2021. Copyright Notice - Copyright (c) 2020 IETF Trust and the persons identified as the + 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. 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 . . . . . . . . . . . . . . . 2 2. Supported HTTP Versions . . . . . . . . . . . . . . . . . . . 3 3. The CONNECT-UDP Method . . . . . . . . . . . . . . . . . . . 3 4. Datagram Encoding of Proxied UDP Packets . . . . . . . . . . 4 - 5. Stream Chunks . . . . . . . . . . . . . . . . . . . . . . . . 5 + 5. Stream Chunks . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Stream Encoding of Proxied UDP Packets . . . . . . . . . . . 6 - 7. Proxy Handling . . . . . . . . . . . . . . . . . . . . . . . 6 - 8. HTTP Intermediaries . . . . . . . . . . . . . . . . . . . . . 6 - 9. Performance Considerations . . . . . . . . . . . . . . . . . 7 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 + 7. Proxy Handling . . . . . . . . . . . . . . . . . . . . . . . 7 + 8. HTTP Intermediaries . . . . . . . . . . . . . . . . . . . . . 7 + 9. Performance Considerations . . . . . . . . . . . . . . . . . 8 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 - 11.1. HTTP Method . . . . . . . . . . . . . . . . . . . . . . 8 - 11.2. URI Scheme Registration . . . . . . . . . . . . . . . . 8 - 11.3. Stream Chunk Type Registration . . . . . . . . . . . . . 8 - 12. Normative References . . . . . . . . . . . . . . . . . . . . 9 - Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 + 11.1. HTTP Method . . . . . . . . . . . . . . . . . . . . . . 9 + 11.2. URI Scheme Registration . . . . . . . . . . . . . . . . 9 + 11.3. Stream Chunk Type Registration . . . . . . . . . . . . . 9 + 12. Normative References . . . . . . . . . . . . . . . . . . . . 10 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction This document describes the CONNECT-UDP HTTP method. CONNECT-UDP is similar to the HTTP CONNECT method (see section 4.3.6 of [RFC7231]), but it uses UDP [UDP] instead of TCP [TCP]. 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/ietf-wg-masque/draft-ietf- @@ -168,61 +168,65 @@ When the HTTP connection supports HTTP/3 datagrams [H3DGRAM], UDP packets can be encoded using QUIC DATAGRAM frames. This support is ascertained by checking the received value of the H3_DATAGRAM SETTINGS Parameter. If the client has both sent and received the H3_DATAGRAM SETTINGS Parameter with value 1 on this connection, it SHOULD attempt to use HTTP/3 datagrams. This is accomplished by requesting a datagram flow identifier from the flow identifier allocation service [H3DGRAM]. That service generates an even flow identifier, and the client sends - it to the proxy by using the "Datagram-Flow-Id" header; see - [H3DGRAM]. A CONNECT-UDP request with an odd flow identifier is - malformed. + it to the proxy by using the unnamed element in a "Datagram-Flow-Id" + header; see [H3DGRAM]. A CONNECT-UDP request with an odd flow + identifier is malformed. The proxy that is creating the UDP socket to the destination responds to the CONNECT-UDP request with a 2xx (Successful) response, and - indicates it supports datagram encoding by echoing the "Datagram- - Flow-Id" header. Once the client has received the "Datagram-Flow-Id" - header on the successful response, it knows that it can use the + indicates it supports datagram encoding by sending a "Datagram-Flow- + Id" header with the same unnamed element from the "Datagram-Flow-Id" + header it received. Once the client has received the "Datagram-Flow- + Id" header on the successful response, it knows that it can use the HTTP/3 datagram encoding to send proxied UDP packets for this particular request. It then encodes the payload of UDP datagrams - into the payload of HTTP/3 datagrams. Is the CONNECT-UDP response + into the payload of HTTP/3 datagrams. If the CONNECT-UDP response does not carry the "Datagram-Flow-Id" header, then the datagram encoding is not available for this request. A CONNECT-UDP response - that carries the "Datagram-Flow-Id" header but with a different flow - identifier than the one sent on the request is malformed. + that carries the "Datagram-Flow-Id" header but with a different + unnamed flow identifier than the one sent on the request is + malformed. When the proxy processes a new CONNECT-UDP request, it MUST ensure - that the datagram flow identifier is not equal to flow identifiers - from other requests: if it is, the proxy MUST reject the request with - a 4xx (Client Error) status code. Extensions MAY weaken or remove - this requirement. + that the unnamed datagram flow identifier is not equal to flow + identifiers from other requests: if it is, the proxy MUST reject the + request with a 4xx (Client Error) status code. Extensions MAY weaken + or remove this requirement. Clients MAY optimistically start sending proxied UDP packets before receiving the response to its CONNECT-UDP request, noting however that those may not be processed by the proxy if it responds to the CONNECT-UDP request with a failure or without echoing the "Datagram- Flow-Id" header, or if the datagrams arrive before the CONNECT-UDP request. Note that a proxy can send the H3_DATAGRAM SETTINGS Parameter with a value of 1 while disabling datagrams on a particular request by not echoing the "Datagram-Flow-Id" header. If the proxy does this, it MUST NOT treat receipt of datagrams as an error, because the client could have sent them optimistically before receiving the response. In this scenario, the proxy MUST discard those datagrams. - Extensions to CONNECT-UDP MAY leverage parameters on the "Datagram- - Flow-Id" header (parameters are defined in Section 3.1.2 of - [STRUCT-HDR]). Proxies MUST NOT echo parameters on the "Datagram- - Flow-Id" header if it does not understand their semantics. + Extensions to CONNECT-UDP MAY leverage named elements or parameters + in the "Datagram-Flow-Id" header (named elements are defined in + [H3DGRAM] and parameters are defined in Section 3.1.2 of + [STRUCT-HDR]). Proxies MUST NOT echo named elements or parameters on + the "Datagram-Flow-Id" header if they do not understand their + semantics. 5. Stream Chunks The bidirectional stream that the CONNECT-UDP request was sent on is a sequence of CONNECT-UDP Stream Chunks, which are defined as a sequence of type-length-value tuples using the following format (using the notation from the "Notational Conventions" section of [QUIC]): CONNECT-UDP Stream { @@ -285,33 +289,39 @@ 8. HTTP Intermediaries HTTP/3 DATAGRAM flow identifiers are specific to a given HTTP/3 connection. However, in some cases, an HTTP request may travel across multiple HTTP connections if there are HTTP intermediaries involved; see Section 2.3 of [RFC7230]. Intermediaries that support both CONNECT-UDP and HTTP/3 datagrams MUST negotiate flow identifiers separately on the client-facing and server-facing connections. This is accomplished by having the - intermediary parse the "Datagram-Flow-Id" header on all CONNECT-UDP - requests it receives, and sending the same value in the "Datagram- - Flow-Id" header on the response. The intermediary then ascertains - whether it can use datagrams on the server-facing connection. If - they are supported (as indicated by the H3_DATAGRAM SETTINGS - parameter), the intermediary uses its own flow identifier allocation - service to allocate a flow identifier for the server-facing - connection, and waits for the server's reply to see if the server - sent the "Datagram-Flow-Id" header on the response. The intermediary - then translates datagrams between the two connections by using the - flow identifier specific to that connection. An intermediary MAY - also choose to use datagrams on only one of the two connections, and - translate between datagrams and streams. + intermediary parse the unnamed element of the "Datagram-Flow-Id" + header on all CONNECT-UDP requests it receives, and sending the same + unnamed element in the "Datagram-Flow-Id" header on the response. + The intermediary then ascertains whether it can use datagrams on the + server-facing connection. If they are supported (as indicated by the + H3_DATAGRAM SETTINGS parameter), the intermediary uses its own flow + identifier allocation service to allocate a flow identifier for the + server-facing connection, and waits for the server's reply to see if + the server sent the "Datagram-Flow-Id" header on the response. The + intermediary then translates datagrams between the two connections by + using the flow identifier specific to that connection. An + intermediary MAY also choose to use datagrams on only one of the two + connections, and translate between datagrams and streams. + + Intermediaries MUST NOT echo nor forward named elements or parameters + on the "Datagram-Flow-Id" header if they do not understand their + semantics. Extensions to CONNECT-UDP that leverage named elements or + parameters in the "Datagram-Flow-Id" header MUST specify how they are + handled by intermediaries. 9. Performance Considerations Proxies SHOULD strive to avoid increasing burstiness of UDP traffic: they SHOULD NOT queue packets in order to increase batching. When the protocol running over UDP that is being proxied uses congestion control (e.g., [QUIC]), the proxied traffic will incur at least two nested congestion controllers. This can reduce performance but the underlying HTTP connection MUST NOT disable congestion