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/