rfc9484v4.txt		rfc9484.txt
	Internet Engineering Task Force (IETF) T. Pauly, Ed.		Internet Engineering Task Force (IETF) T. Pauly, Ed.
	Request for Comments: 9484 Apple Inc.		Request for Comments: 9484 Apple Inc.
	Updates: 9298 D. Schinazi		Updates: 9298 D. Schinazi
	Category: Standards Track A. Chernyakhovsky		Category: Standards Track A. Chernyakhovsky
	ISSN: 2070-1721 Google LLC		ISSN: 2070-1721 Google LLC
	M. Kuehlewind		M. Kühlewind
	M. Westerlund		M. Westerlund
	Ericsson		Ericsson
	September 2023		October 2023
	Proxying IP in HTTP		Proxying IP in HTTP
	Abstract		Abstract
	This document describes how to proxy IP packets in HTTP. This		This document describes how to proxy IP packets in HTTP. This
	protocol is similar to UDP proxying in HTTP but allows transmitting		protocol is similar to UDP proxying in HTTP but allows transmitting
	arbitrary IP packets. More specifically, this document defines a		arbitrary IP packets. More specifically, this document defines a
	protocol that allows an HTTP client to create an IP tunnel through an		protocol that allows an HTTP client to create an IP tunnel through an
	HTTP server that acts as an IP proxy. This document updates RFC		HTTP server that acts as an IP proxy. This document updates RFC
	skipping to change at line 242 ¶		skipping to change at line 242 ¶
	carry any message content.		carry any message content.
	IP proxying over HTTP MUST be operated over TLS or QUIC encryption,		IP proxying over HTTP MUST be operated over TLS or QUIC encryption,
	or another equivalent encryption protocol, to provide		or another equivalent encryption protocol, to provide
	confidentiality, integrity, and authentication.		confidentiality, integrity, and authentication.
	4.1. IP Proxy Handling		4.1. IP Proxy Handling
	Upon receiving an IP proxying request:		Upon receiving an IP proxying request:
	* If the recipient is configured to use another HTTP proxy, it will		* If the recipient is configured to use another HTTP server, it will
	act as an intermediary by forwarding the request to another HTTP		act as an intermediary by forwarding the request to the other HTTP
	server. Note that such intermediaries may need to re-encode the		server. Note that such intermediaries may need to re-encode the
	request if they forward it using a version of HTTP that is		request if they forward it using a version of HTTP that is
	different from the one used to receive it, as the request encoding		different from the one used to receive it, as the request encoding
	differs by version (see below).		differs by version (see below).
	* Otherwise, the recipient will act as an IP proxy. The IP proxy		* Otherwise, the recipient will act as an IP proxy. The IP proxy
	can choose to reject the IP proxying request. Otherwise, it		can choose to reject the IP proxying request. Otherwise, it
	extracts the optional "target" and "ipproto" variables from the		extracts the optional "target" and "ipproto" variables from the
	URI it has reconstructed from the request headers, decodes their		URI it has reconstructed from the request headers, decodes their
	percent-encoding, and establishes an IP tunnel.		percent-encoding, and establishes an IP tunnel.
	skipping to change at line 274 ¶		skipping to change at line 274 ¶
	example, if DNS resolution returns an error, the proxy can use the		example, if DNS resolution returns an error, the proxy can use the
	dns_error proxy error type from Section 2.3.2 of [PROXY-STATUS].		dns_error proxy error type from Section 2.3.2 of [PROXY-STATUS].
	The lifetime of the IP forwarding tunnel is tied to the IP proxying		The lifetime of the IP forwarding tunnel is tied to the IP proxying
	request stream. The IP proxy MUST maintain all IP address and route		request stream. The IP proxy MUST maintain all IP address and route
	assignments associated with the IP forwarding tunnel while the		assignments associated with the IP forwarding tunnel while the
	request stream is open. IP proxies MAY choose to tear down the		request stream is open. IP proxies MAY choose to tear down the
	tunnel due to a period of inactivity, but they MUST close the request		tunnel due to a period of inactivity, but they MUST close the request
	stream when doing so.		stream when doing so.
	A successful response (as defined in Sections 4.3 and 4.5) indicates		A successful IP proxying response (as defined in Sections 4.3 and
	that the IP proxy has established an IP tunnel and is willing to		4.5) indicates that the IP proxy has established an IP tunnel and is
	proxy IP payloads. Any response other than a successful response		willing to proxy IP payloads. Any response other than a successful
	indicates that the request has failed; thus, the client MUST abort		IP proxying response indicates that the request has failed; thus, the
	the request.		client MUST abort the request.
	Along with a successful response, the IP proxy can send capsules to		Along with a successful IP proxying response, the IP proxy can send
	assign addresses and advertise routes to the client (Section 4.7).		capsules to assign addresses and advertise routes to the client
	The client can also assign addresses and advertise routes to the IP		(Section 4.7). The client can also assign addresses and advertise
	proxy for network-to-network routing.		routes to the IP proxy for network-to-network routing.
	4.2. HTTP/1.1 Request		4.2. HTTP/1.1 Request
	When using HTTP/1.1 [HTTP/1.1], an IP proxying request will meet the		When using HTTP/1.1 [HTTP/1.1], an IP proxying request will meet the
	following requirements:		following requirements:
	* The method SHALL be "GET".		* The method SHALL be "GET".
	* The request SHALL include a single Host header field containing		* The request SHALL include a single Host header field containing
	the host and optional port of the IP proxy.		the host and optional port of the IP proxy.
	skipping to change at line 321 ¶		skipping to change at line 321 ¶
	GET https://example.org/.well-known/masque/ip/*/*/ HTTP/1.1		GET https://example.org/.well-known/masque/ip/*/*/ HTTP/1.1
	Host: example.org		Host: example.org
	Connection: Upgrade		Connection: Upgrade
	Upgrade: connect-ip		Upgrade: connect-ip
	Capsule-Protocol: ?1		Capsule-Protocol: ?1
	Figure 2: Example HTTP/1.1 Request		Figure 2: Example HTTP/1.1 Request
	4.3. HTTP/1.1 Response		4.3. HTTP/1.1 Response
	The server indicates a successful response by replying with the		The server indicates a successful IP proxying response by replying
	following requirements:		with the following requirements:
	* The HTTP status code on the response SHALL be 101 (Switching		* The HTTP status code on the response SHALL be 101 (Switching
	Protocols).		Protocols).
	* The response SHALL include a Connection header field with value		* The response SHALL include a Connection header field with value
	"Upgrade" (note that this requirement is case-insensitive, as per		"Upgrade" (note that this requirement is case-insensitive, as per
	Section 7.6.1 of [HTTP]).		Section 7.6.1 of [HTTP]).
	* The response SHALL include a single Upgrade header field with		* The response SHALL include a single Upgrade header field with
	value "connect-ip".		value "connect-ip".
	skipping to change at line 392 ¶		skipping to change at line 392 ¶
	:protocol = connect-ip		:protocol = connect-ip
	:scheme = https		:scheme = https
	:path = /.well-known/masque/ip/*/*/		:path = /.well-known/masque/ip/*/*/
	:authority = example.org		:authority = example.org
	capsule-protocol = ?1		capsule-protocol = ?1
	Figure 4: Example HTTP/2 or HTTP/3 Request		Figure 4: Example HTTP/2 or HTTP/3 Request
	4.5. HTTP/2 and HTTP/3 Responses		4.5. HTTP/2 and HTTP/3 Responses
	The server indicates a successful response by replying with the		The server indicates a successful IP proxying response by replying
	following requirements:		with the following requirements:
	* The HTTP status code on the response SHALL be in the 2xx		* The HTTP status code on the response SHALL be in the 2xx
	(Successful) range.		(Successful) range.
	* The response SHALL meet the requirements of HTTP responses that		* The response SHALL meet the requirements of HTTP responses that
	start the Capsule Protocol; see Section 3.2 of [HTTP-DGRAM].		start the Capsule Protocol; see Section 3.2 of [HTTP-DGRAM].
	If any of these requirements are not met, the client MUST treat this		If any of these requirements are not met, the client MUST treat this
	proxying attempt as failed and abort the request. As an example, any		proxying attempt as failed and abort the request. As an example, any
	status code in the 3xx range will be treated as a failure and cause		status code in the 3xx range will be treated as a failure and cause
	skipping to change at line 494 ¶		skipping to change at line 494 ¶
	target = IPv6prefix / IPv4prefix / reg-name / "*"		target = IPv6prefix / IPv4prefix / reg-name / "*"
	IPv6prefix = IPv6address ["%2F" 1*3DIGIT]		IPv6prefix = IPv6address ["%2F" 1*3DIGIT]
	IPv4prefix = IPv4address ["%2F" 1*2DIGIT]		IPv4prefix = IPv4address ["%2F" 1*2DIGIT]
	ipproto = 1*3DIGIT / "*"		ipproto = 1*3DIGIT / "*"
	Figure 6: URI Template Variable Format		Figure 6: URI Template Variable Format
	IP proxies MAY perform access control using the scoping information		IP proxies MAY perform access control using the scoping information
	provided by the client, i.e., if the client is not authorized to		provided by the client, i.e., if the client is not authorized to
	access any of the destinations included in the scope, then the IP		access any of the destinations included in the scope, then the IP
	proxy can immediately fail the request.		proxy can immediately reject the request.
	4.7. Capsules		4.7. Capsules
	This document defines multiple new capsule types that allow endpoints		This document defines multiple new capsule types that allow endpoints
	to exchange IP configuration information. Both endpoints MAY send		to exchange IP configuration information. Both endpoints MAY send
	any number of these new capsules.		any number of these new capsules.
	4.7.1. ADDRESS_ASSIGN Capsule		4.7.1. ADDRESS_ASSIGN Capsule
	The ADDRESS_ASSIGN capsule (capsule type 0x01) allows an endpoint to		The ADDRESS_ASSIGN capsule (capsule type 0x01) allows an endpoint to
	skipping to change at line 876 ¶		skipping to change at line 876 ¶
	7.1. Link Operation		7.1. Link Operation
	The IP forwarding tunnels described in this document are not fully		The IP forwarding tunnels described in this document are not fully
	featured "interfaces" in the IPv6 addressing architecture sense		featured "interfaces" in the IPv6 addressing architecture sense
	[IPv6-ADDR]. In particular, they do not necessarily have IPv6 link-		[IPv6-ADDR]. In particular, they do not necessarily have IPv6 link-
	local addresses. Additionally, IPv6 stateless autoconfiguration or		local addresses. Additionally, IPv6 stateless autoconfiguration or
	router advertisement messages are not used in such interfaces, and		router advertisement messages are not used in such interfaces, and
	neither is neighbor discovery.		neither is neighbor discovery.
	Clients MAY optimistically start sending proxied IP packets before		When using HTTP/2 or HTTP/3, a client MAY optimistically start
	receiving the response to its IP proxying request, noting however		sending proxied IP packets before receiving the response to its IP
	that those may not be processed by the IP proxy if it responds to the		proxying request, noting however that those may not be processed by
	request with a failure or if the datagrams are received by the IP		the IP proxy if it responds to the request with a failure or if the
	proxy before the request. Since receiving addresses and routes is		datagrams are received by the IP proxy before the request. Since
	required in order to know that a packet can be sent through the		receiving addresses and routes is required in order to know that a
	tunnel, such optimistic packets might be dropped by the IP proxy if		packet can be sent through the tunnel, such optimistic packets might
	it chooses to provide different addressing or routing information		be dropped by the IP proxy if it chooses to provide different
	than what the client assumed.		addressing or routing information than what the client assumed.
	Note that it is possible for multiple proxied IP packets to be		Note that it is possible for multiple proxied IP packets to be
	encapsulated in the same outer packet, for example, because a QUIC		encapsulated in the same outer packet, for example, because a QUIC
	packet can carry two QUIC DATAGRAM frames. It is also possible for a		packet can carry more than one QUIC DATAGRAM frame. It is also
	proxied IP packet to span multiple outer packets, because a DATAGRAM		possible for a proxied IP packet to span multiple outer packets,
	capsule can be split across multiple QUIC or TCP packets.		because a DATAGRAM capsule can be split across multiple QUIC or TCP
			packets.
	7.2. Routing Operation		7.2. Routing Operation
	The requirements in this section are a repetition of requirements		The requirements in this section are a repetition of requirements
	that apply to IP routers in general and might not apply to		that apply to IP routers in general and might not apply to
	implementations of IP proxying that rely on external software for		implementations of IP proxying that rely on external software for
	routing.		routing.
	When an endpoint receives an HTTP Datagram containing an IP packet,		When an endpoint receives an HTTP Datagram containing an IP packet,
	it will parse the packet's IP header, perform any local policy checks		it will parse the packet's IP header, perform any local policy checks
	skipping to change at line 1535 ¶		skipping to change at line 1536 ¶
	[TUNNEL-SECURITY]. Since there are known risks with some IPv6		[TUNNEL-SECURITY]. Since there are known risks with some IPv6
	extension headers (e.g., [ROUTING-HDR]), implementers need to follow		extension headers (e.g., [ROUTING-HDR]), implementers need to follow
	the latest guidance regarding handling of IPv6 extension headers.		the latest guidance regarding handling of IPv6 extension headers.
	Transferring DSCP markings from inner to outer packets (see		Transferring DSCP markings from inner to outer packets (see
	Section 10.3) exposes end-to-end flow level information to an on-path		Section 10.3) exposes end-to-end flow level information to an on-path
	observer between the IP proxying endpoints. This can potentially		observer between the IP proxying endpoints. This can potentially
	expose a single end-to-end flow. Because of this, such use of DSCPs		expose a single end-to-end flow. Because of this, such use of DSCPs
	in privacy-sensitive contexts is NOT RECOMMENDED.		in privacy-sensitive contexts is NOT RECOMMENDED.
			Opportunistic sending of IP packets (see Section 7.1) is not allowed
			in HTTP/1.x because a server could reject the HTTP Upgrade and
			attempt to parse the IP packets as a subsequent HTTP request,
			allowing request smuggling attacks; see [OPTIMISTIC]. In particular,
			an intermediary that re-encodes a request from HTTP/2 or 3 to
			HTTP/1.1 MUST NOT forward any received capsules until it has parsed a
			successful IP proxying response.
	12. IANA Considerations		12. IANA Considerations
	12.1. HTTP Upgrade Token Registration		12.1. HTTP Upgrade Token Registration
	IANA has registered "connect-ip" in the "HTTP Upgrade Tokens"		IANA has registered "connect-ip" in the "HTTP Upgrade Tokens"
	registry maintained at <https://www.iana.org/assignments/http-		registry maintained at <https://www.iana.org/assignments/http-
	upgrade-tokens>.		upgrade-tokens>.
	Value: connect-ip		Value: connect-ip
	Description: Proxying of IP Payloads		Description: Proxying of IP Payloads
	skipping to change at line 1774 ¶		skipping to change at line 1783 ¶
	[IPSEC] Kent, S. and K. Seo, "Security Architecture for the		[IPSEC] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,		Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
	December 2005, <https://www.rfc-editor.org/info/rfc4301>.		December 2005, <https://www.rfc-editor.org/info/rfc4301>.
	[IPv6-ADDR]		[IPv6-ADDR]
	Hinden, R. and S. Deering, "IP Version 6 Addressing		Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 4291, DOI 10.17487/RFC4291, February		Architecture", RFC 4291, DOI 10.17487/RFC4291, February
	2006, <https://www.rfc-editor.org/info/rfc4291>.		2006, <https://www.rfc-editor.org/info/rfc4291>.
			[OPTIMISTIC]
			Schwartz, B. M., "Security Considerations for Optimistic
			Use of HTTP Upgrade", Work in Progress, Internet-Draft,
			draft-schwartz-httpbis-optimistic-upgrade-00, 21 August
			2023, <https://datatracker.ietf.org/doc/html/draft-
			schwartz-httpbis-optimistic-upgrade-00>.
	[PROXY-REQS]		[PROXY-REQS]
	Chernyakhovsky, A., McCall, D., and D. Schinazi,		Chernyakhovsky, A., McCall, D., and D. Schinazi,
	"Requirements for a MASQUE Protocol to Proxy IP Traffic",		"Requirements for a MASQUE Protocol to Proxy IP Traffic",
	Work in Progress, Internet-Draft, draft-ietf-masque-ip-		Work in Progress, Internet-Draft, draft-ietf-masque-ip-
	proxy-reqs-03, 27 August 2021,		proxy-reqs-03, 27 August 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-masque-		<https://datatracker.ietf.org/doc/html/draft-ietf-masque-
	ip-proxy-reqs-03>.		ip-proxy-reqs-03>.
	[ROUTING-HDR]		[ROUTING-HDR]
	Abley, J., Savola, P., and G. Neville-Neil, "Deprecation		Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
	skipping to change at line 1827 ¶		skipping to change at line 1843 ¶
	Google LLC		Google LLC
	1600 Amphitheatre Parkway		1600 Amphitheatre Parkway
	Mountain View, CA 94043		Mountain View, CA 94043
	United States of America		United States of America
	Email: dschinazi.ietf@gmail.com		Email: dschinazi.ietf@gmail.com
	Alex Chernyakhovsky		Alex Chernyakhovsky
	Google LLC		Google LLC
	Email: achernya@google.com		Email: achernya@google.com
	Mirja Kuehlewind		Mirja Kühlewind
	Ericsson		Ericsson
	Email: mirja.kuehlewind@ericsson.com		Email: mirja.kuehlewind@ericsson.com
	Magnus Westerlund		Magnus Westerlund
	Ericsson		Ericsson
	Email: magnus.westerlund@ericsson.com		Email: magnus.westerlund@ericsson.com
End of changes. 13 change blocks.
	31 lines changed or deleted		47 lines changed or added
This html diff was produced by rfcdiff 1.48.