draft-ietf-masque-connect-udp-02.txt   draft-ietf-masque-connect-udp-03.txt 
Network Working Group D. Schinazi Network Working Group D. Schinazi
Internet-Draft Google LLC Internet-Draft Google LLC
Intended status: Standards Track 30 December 2020 Intended status: Standards Track 5 January 2021
Expires: 3 July 2021 Expires: 9 July 2021
The CONNECT-UDP HTTP Method The CONNECT-UDP HTTP Method
draft-ietf-masque-connect-udp-02 draft-ietf-masque-connect-udp-03
Abstract Abstract
This document describes the CONNECT-UDP HTTP method. CONNECT-UDP is This document describes the CONNECT-UDP HTTP method. CONNECT-UDP is
similar to the HTTP CONNECT method, but it uses UDP instead of TCP. 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 Discussion of this work is encouraged to happen on the MASQUE IETF
mailing list masque@ietf.org or on the GitHub repository which mailing list masque@ietf.org or on the GitHub repository which
contains the draft: https://github.com/ietf-wg-masque/draft-ietf- contains the draft: https://github.com/ietf-wg-masque/draft-ietf-
masque-connect-udp. masque-connect-udp.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 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. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Definitions . . . . . . . . . . . . . . . 2 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 2
2. Supported HTTP Versions . . . . . . . . . . . . . . . . . . . 3 2. Supported HTTP Versions . . . . . . . . . . . . . . . . . . . 3
3. The CONNECT-UDP Method . . . . . . . . . . . . . . . . . . . 3 3. The CONNECT-UDP Method . . . . . . . . . . . . . . . . . . . 3
4. Datagram Encoding of Proxied UDP Packets . . . . . . . . . . 4 4. Datagram Encoding of Proxied UDP Packets . . . . . . . . . . 4
5. Stream Chunks . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Stream Chunks . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Stream Encoding of Proxied UDP Packets . . . . . . . . . . . 6 6. Stream Encoding of Proxied UDP Packets . . . . . . . . . . . 6
7. Proxy Handling . . . . . . . . . . . . . . . . . . . . . . . 6 7. Proxy Handling . . . . . . . . . . . . . . . . . . . . . . . 7
8. HTTP Intermediaries . . . . . . . . . . . . . . . . . . . . . 6 8. HTTP Intermediaries . . . . . . . . . . . . . . . . . . . . . 7
9. Performance Considerations . . . . . . . . . . . . . . . . . 7 9. Performance Considerations . . . . . . . . . . . . . . . . . 8
10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
11.1. HTTP Method . . . . . . . . . . . . . . . . . . . . . . 8 11.1. HTTP Method . . . . . . . . . . . . . . . . . . . . . . 9
11.2. URI Scheme Registration . . . . . . . . . . . . . . . . 8 11.2. URI Scheme Registration . . . . . . . . . . . . . . . . 9
11.3. Stream Chunk Type Registration . . . . . . . . . . . . . 8 11.3. Stream Chunk Type Registration . . . . . . . . . . . . . 9
12. Normative References . . . . . . . . . . . . . . . . . . . . 9 12. Normative References . . . . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
This document describes the CONNECT-UDP HTTP method. CONNECT-UDP is This document describes the CONNECT-UDP HTTP method. CONNECT-UDP is
similar to the HTTP CONNECT method (see section 4.3.6 of [RFC7231]), similar to the HTTP CONNECT method (see section 4.3.6 of [RFC7231]),
but it uses UDP [UDP] instead of TCP [TCP]. but it uses UDP [UDP] instead of TCP [TCP].
Discussion of this work is encouraged to happen on the MASQUE IETF Discussion of this work is encouraged to happen on the MASQUE IETF
mailing list masque@ietf.org or on the GitHub repository which mailing list masque@ietf.org or on the GitHub repository which
contains the draft: https://github.com/ietf-wg-masque/draft-ietf- contains the draft: https://github.com/ietf-wg-masque/draft-ietf-
skipping to change at page 4, line 37 skipping to change at page 4, line 37
When the HTTP connection supports HTTP/3 datagrams [H3DGRAM], UDP When the HTTP connection supports HTTP/3 datagrams [H3DGRAM], UDP
packets can be encoded using QUIC DATAGRAM frames. This support is packets can be encoded using QUIC DATAGRAM frames. This support is
ascertained by checking the received value of the H3_DATAGRAM ascertained by checking the received value of the H3_DATAGRAM
SETTINGS Parameter. SETTINGS Parameter.
If the client has both sent and received the H3_DATAGRAM SETTINGS If the client has both sent and received the H3_DATAGRAM SETTINGS
Parameter with value 1 on this connection, it SHOULD attempt to use Parameter with value 1 on this connection, it SHOULD attempt to use
HTTP/3 datagrams. This is accomplished by requesting a datagram flow HTTP/3 datagrams. This is accomplished by requesting a datagram flow
identifier from the flow identifier allocation service [H3DGRAM]. identifier from the flow identifier allocation service [H3DGRAM].
That service generates an even flow identifier, and the client sends That service generates an even flow identifier, and the client sends
it to the proxy by using the "Datagram-Flow-Id" header; see it to the proxy by using the unnamed element in a "Datagram-Flow-Id"
[H3DGRAM]. A CONNECT-UDP request with an odd flow identifier is header; see [H3DGRAM]. A CONNECT-UDP request with an odd flow
malformed. identifier is malformed.
The proxy that is creating the UDP socket to the destination responds The proxy that is creating the UDP socket to the destination responds
to the CONNECT-UDP request with a 2xx (Successful) response, and to the CONNECT-UDP request with a 2xx (Successful) response, and
indicates it supports datagram encoding by echoing the "Datagram- indicates it supports datagram encoding by sending a "Datagram-Flow-
Flow-Id" header. Once the client has received the "Datagram-Flow-Id" Id" header with the same unnamed element from the "Datagram-Flow-Id"
header on the successful response, it knows that it can use the 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 HTTP/3 datagram encoding to send proxied UDP packets for this
particular request. It then encodes the payload of UDP datagrams 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 does not carry the "Datagram-Flow-Id" header, then the datagram
encoding is not available for this request. A CONNECT-UDP response encoding is not available for this request. A CONNECT-UDP response
that carries the "Datagram-Flow-Id" header but with a different flow that carries the "Datagram-Flow-Id" header but with a different
identifier than the one sent on the request is malformed. unnamed flow identifier than the one sent on the request is
malformed.
When the proxy processes a new CONNECT-UDP request, it MUST ensure When the proxy processes a new CONNECT-UDP request, it MUST ensure
that the datagram flow identifier is not equal to flow identifiers that the unnamed datagram flow identifier is not equal to flow
from other requests: if it is, the proxy MUST reject the request with identifiers from other requests: if it is, the proxy MUST reject the
a 4xx (Client Error) status code. Extensions MAY weaken or remove request with a 4xx (Client Error) status code. Extensions MAY weaken
this requirement. or remove this requirement.
Clients MAY optimistically start sending proxied UDP packets before Clients MAY optimistically start sending proxied UDP packets before
receiving the response to its CONNECT-UDP request, noting however receiving the response to its CONNECT-UDP request, noting however
that those may not be processed by the proxy if it responds to the 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- CONNECT-UDP request with a failure or without echoing the "Datagram-
Flow-Id" header, or if the datagrams arrive before the CONNECT-UDP Flow-Id" header, or if the datagrams arrive before the CONNECT-UDP
request. request.
Note that a proxy can send the H3_DATAGRAM SETTINGS Parameter with a 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 value of 1 while disabling datagrams on a particular request by not
echoing the "Datagram-Flow-Id" header. If the proxy does this, it echoing the "Datagram-Flow-Id" header. If the proxy does this, it
MUST NOT treat receipt of datagrams as an error, because the client MUST NOT treat receipt of datagrams as an error, because the client
could have sent them optimistically before receiving the response. could have sent them optimistically before receiving the response.
In this scenario, the proxy MUST discard those datagrams. In this scenario, the proxy MUST discard those datagrams.
Extensions to CONNECT-UDP MAY leverage parameters on the "Datagram- Extensions to CONNECT-UDP MAY leverage named elements or parameters
Flow-Id" header (parameters are defined in Section 3.1.2 of in the "Datagram-Flow-Id" header (named elements are defined in
[STRUCT-HDR]). Proxies MUST NOT echo parameters on the "Datagram- [H3DGRAM] and parameters are defined in Section 3.1.2 of
Flow-Id" header if it does not understand their semantics. [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 5. Stream Chunks
The bidirectional stream that the CONNECT-UDP request was sent on is The bidirectional stream that the CONNECT-UDP request was sent on is
a sequence of CONNECT-UDP Stream Chunks, which are defined as a a sequence of CONNECT-UDP Stream Chunks, which are defined as a
sequence of type-length-value tuples using the following format sequence of type-length-value tuples using the following format
(using the notation from the "Notational Conventions" section of (using the notation from the "Notational Conventions" section of
[QUIC]): [QUIC]):
CONNECT-UDP Stream { CONNECT-UDP Stream {
skipping to change at page 7, line 8 skipping to change at page 7, line 35
8. HTTP Intermediaries 8. HTTP Intermediaries
HTTP/3 DATAGRAM flow identifiers are specific to a given HTTP/3 HTTP/3 DATAGRAM flow identifiers are specific to a given HTTP/3
connection. However, in some cases, an HTTP request may travel connection. However, in some cases, an HTTP request may travel
across multiple HTTP connections if there are HTTP intermediaries across multiple HTTP connections if there are HTTP intermediaries
involved; see Section 2.3 of [RFC7230]. involved; see Section 2.3 of [RFC7230].
Intermediaries that support both CONNECT-UDP and HTTP/3 datagrams Intermediaries that support both CONNECT-UDP and HTTP/3 datagrams
MUST negotiate flow identifiers separately on the client-facing and MUST negotiate flow identifiers separately on the client-facing and
server-facing connections. This is accomplished by having the server-facing connections. This is accomplished by having the
intermediary parse the "Datagram-Flow-Id" header on all CONNECT-UDP intermediary parse the unnamed element of the "Datagram-Flow-Id"
requests it receives, and sending the same value in the "Datagram- header on all CONNECT-UDP requests it receives, and sending the same
Flow-Id" header on the response. The intermediary then ascertains unnamed element in the "Datagram-Flow-Id" header on the response.
whether it can use datagrams on the server-facing connection. If The intermediary then ascertains whether it can use datagrams on the
they are supported (as indicated by the H3_DATAGRAM SETTINGS server-facing connection. If they are supported (as indicated by the
parameter), the intermediary uses its own flow identifier allocation H3_DATAGRAM SETTINGS parameter), the intermediary uses its own flow
service to allocate a flow identifier for the server-facing identifier allocation service to allocate a flow identifier for the
connection, and waits for the server's reply to see if the server server-facing connection, and waits for the server's reply to see if
sent the "Datagram-Flow-Id" header on the response. The intermediary the server sent the "Datagram-Flow-Id" header on the response. The
then translates datagrams between the two connections by using the intermediary then translates datagrams between the two connections by
flow identifier specific to that connection. An intermediary MAY using the flow identifier specific to that connection. An
also choose to use datagrams on only one of the two connections, and intermediary MAY also choose to use datagrams on only one of the two
translate between datagrams and streams. 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 9. Performance Considerations
Proxies SHOULD strive to avoid increasing burstiness of UDP traffic: Proxies SHOULD strive to avoid increasing burstiness of UDP traffic:
they SHOULD NOT queue packets in order to increase batching. they SHOULD NOT queue packets in order to increase batching.
When the protocol running over UDP that is being proxied uses When the protocol running over UDP that is being proxied uses
congestion control (e.g., [QUIC]), the proxied traffic will incur at congestion control (e.g., [QUIC]), the proxied traffic will incur at
least two nested congestion controllers. This can reduce performance least two nested congestion controllers. This can reduce performance
but the underlying HTTP connection MUST NOT disable congestion but the underlying HTTP connection MUST NOT disable congestion
 End of changes. 14 change blocks. 
46 lines changed or deleted 56 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/