draft-ietf-masque-connect-udp-11.txt		draft-ietf-masque-connect-udp-12.txt
	MASQUE D. Schinazi		MASQUE D. Schinazi
	Internet-Draft Google LLC		Internet-Draft Google LLC
	Intended status: Standards Track 2 May 2022		Intended status: Standards Track 3 May 2022
	Expires: 3 November 2022		Expires: 4 November 2022
	Proxying UDP in HTTP		Proxying UDP in HTTP
	draft-ietf-masque-connect-udp-11		draft-ietf-masque-connect-udp-12
	Abstract		Abstract
	This document describes how to proxy UDP in HTTP, similar to how the		This document describes how to proxy UDP in HTTP, similar to how the
	HTTP CONNECT method allows proxying TCP in HTTP. More specifically,		HTTP CONNECT method allows proxying TCP in HTTP. More specifically,
	this document defines a protocol that allows HTTP clients to create a		this document defines a protocol that allows HTTP clients to create a
	tunnel for UDP communications through an HTTP server that acts as a		tunnel for UDP communications through an HTTP server that acts as a
	proxy.		proxy.
	About This Document		About This Document
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	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 November 2022.		This Internet-Draft will expire on 4 November 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 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
	skipping to change at page 5, line 46 ¶		skipping to change at page 5, line 46 ¶
	* otherwise, the recipient will act as a UDP proxy: it extracts the		* otherwise, the recipient will act as a UDP proxy: it extracts the
	"target_host" and "target_port" variables from the URI it has		"target_host" and "target_port" variables from the URI it has
	reconstructed from the request headers, and establishes a tunnel		reconstructed from the request headers, and establishes a tunnel
	by directly opening a UDP socket to the requested target.		by directly opening a UDP socket to the requested target.
	Unlike TCP, UDP is connection-less. The UDP proxy that opens the UDP		Unlike TCP, UDP is connection-less. The UDP proxy that opens the UDP
	socket has no way of knowing whether the destination is reachable.		socket has no way of knowing whether the destination is reachable.
	Therefore it needs to respond to the request without waiting for a		Therefore it needs to respond to the request without waiting for a
	packet from the target. However, if the target_host is a DNS name,		packet from the target. However, if the target_host is a DNS name,
	the UDP proxy MUST perform DNS resolution before replying to the HTTP		the UDP proxy MUST perform DNS resolution before replying to the HTTP
	request. If errors occur during this process (for example, a DNS		request. If errors occur during this process, the UDP proxy MUST
	resolution failure), the UDP proxy MUST fail the request and SHOULD		fail the request and SHOULD send details using an appropriate "Proxy-
	send details using an appropriate "Proxy-Status" header field		Status" header field [PROXY-STATUS] (for example, if DNS resolution
	[PROXY-STATUS].		returns an error, the proxy can use the dns_error Proxy Error Type
			from Section 2.3.2 of [PROXY-STATUS]).
	UDP proxies can use connected UDP sockets if their operating system		UDP proxies can use connected UDP sockets if their operating system
	supports them, as that allows the UDP proxy to rely on the kernel to		supports them, as that allows the UDP proxy to rely on the kernel to
	only send it UDP packets that match the correct 5-tuple. If the UDP		only send it UDP packets that match the correct 5-tuple. If the UDP
	proxy uses a non-connected socket, it MUST validate the IP source		proxy uses a non-connected socket, it MUST validate the IP source
	address and UDP source port on received packets to ensure they match		address and UDP source port on received packets to ensure they match
	the client's request. Packets that do not match MUST be discarded by		the client's request. Packets that do not match MUST be discarded by
	the UDP proxy.		the UDP proxy.
	The lifetime of the socket is tied to the request stream. The UDP		The lifetime of the socket is tied to the request stream. The UDP
End of changes. 4 change blocks.
	8 lines changed or deleted		9 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/