draft-ietf-rtcweb-ip-handling-05.txt		draft-ietf-rtcweb-ip-handling-06.txt
	Network Working Group J. Uberti		Network Working Group J. Uberti
	Internet-Draft Google		Internet-Draft Google
	Intended status: Standards Track G. Shieh		Intended status: Standards Track G. Shieh
	Expires: August 15, 2018 Facebook		Expires: September 2, 2018 Facebook
	February 11, 2018		March 1, 2018
	WebRTC IP Address Handling Requirements		WebRTC IP Address Handling Requirements
	draft-ietf-rtcweb-ip-handling-05		draft-ietf-rtcweb-ip-handling-06
	Abstract		Abstract
	This document provides information and requirements for how IP		This document provides information and requirements for how IP
	addresses should be handled by WebRTC implementations.		addresses should be handled by WebRTC implementations.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 32 ¶		skipping to change at page 1, line 32 ¶
	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 August 15, 2018.		This Internet-Draft will expire on September 2, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 15 ¶		skipping to change at page 2, line 15 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
	3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2		3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2
	4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	5. Detailed Design . . . . . . . . . . . . . . . . . . . . . . . 4		5. Detailed Design . . . . . . . . . . . . . . . . . . . . . . . 4
	5.1. Principles . . . . . . . . . . . . . . . . . . . . . . . 4		5.1. Principles . . . . . . . . . . . . . . . . . . . . . . . 4
	5.2. Modes and Recommendations . . . . . . . . . . . . . . . . 5		5.2. Modes and Recommendations . . . . . . . . . . . . . . . . 5
	6. Implementation Guidance . . . . . . . . . . . . . . . . . . . 6		6. Implementation Guidance . . . . . . . . . . . . . . . . . . . 6
			6.1. Ensuring Normal Routing . . . . . . . . . . . . . . . . . 6
			6.2. Determining Host Candidates . . . . . . . . . . . . . . . 6
	7. Application Guidance . . . . . . . . . . . . . . . . . . . . 7		7. Application Guidance . . . . . . . . . . . . . . . . . . . . 7
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 7		8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	11.1. Normative References . . . . . . . . . . . . . . . . . . 7		11.1. Normative References . . . . . . . . . . . . . . . . . . 8
	11.2. Informative References . . . . . . . . . . . . . . . . . 7		11.2. Informative References . . . . . . . . . . . . . . . . . 8
	Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 9		Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	One of WebRTC's key features is its support of peer-to-peer		One of WebRTC's key features is its support of peer-to-peer
	connections. However, when establishing such a connection, which		connections. However, when establishing such a connection, which
	involves connection attempts from various IP addresses, WebRTC may		involves connection attempts from various IP addresses, WebRTC may
	allow a web application to learn additional information about the		allow a web application to learn additional information about the
	user compared to an application that only uses the Hypertext Transfer		user compared to an application that only uses the Hypertext Transfer
	skipping to change at page 5, line 31 ¶		skipping to change at page 5, line 31 ¶
	Mode 2: Default route + associated local addresses: WebRTC MUST		Mode 2: Default route + associated local addresses: WebRTC MUST
	follow the kernel routing table rules, which will typically		follow the kernel routing table rules, which will typically
	cause media packets to take the same route as the		cause media packets to take the same route as the
	application's HTTP traffic. In addition, the private IPv4		application's HTTP traffic. In addition, the private IPv4
	and IPv6 addresses associated with the kernel-chosen		and IPv6 addresses associated with the kernel-chosen
	interface MUST be discovered and provided to the		interface MUST be discovered and provided to the
	application. This ensures that direct connections can still		application. This ensures that direct connections can still
	be established in this mode.		be established in this mode.
	Mode 3: Default route only: This is the the same as Mode 2, except		Mode 3: Default route only: This is the the same as Mode 2, except
	that the associated private addressses MUST NOT be provided;		that the associated private addresses MUST NOT be provided;
	the only IP addresses gathered are those discovered via		the only IP addresses gathered are those discovered via
	mechanisms like STUN and TURN (on the default route). This		mechanisms like STUN and TURN (on the default route). This
	may cause traffic to hairpin through a NAT, fall back to an		may cause traffic to hairpin through a NAT, fall back to an
	application TURN server, or fail altogether, with resulting		application TURN server, or fail altogether, with resulting
	quality implications.		quality implications.
	Mode 4: Force proxy: This is the same as Mode 3, but all WebRTC		Mode 4: Force proxy: This is the same as Mode 3, but all WebRTC
	media traffic is forced through a proxy, if one is		media traffic is forced through a proxy, if one is
	configured. If the proxy does not support UDP (as is the		configured. If the proxy does not support UDP (as is the
	case for all HTTP and most SOCKS [RFC1928] proxies), or the		case for all HTTP and most SOCKS [RFC1928] proxies), or the
	WebRTC implementation does not support UDP proxying, the use		WebRTC implementation does not support UDP proxying, the use
	of UDP will be disabled, and TCP will be used to send and		of UDP will be disabled, and TCP will be used to send and
	receive media through the proxy. Use of TCP will result in		receive media through the proxy. Use of TCP will result in
	reduced media quality, in addition to any performance		reduced media quality, in addition to any performance
	considerations associated with sending all WebRTC media		considerations associated with sending all WebRTC media
	through the proxy server.		through the proxy server.
	The recommended defaults are as follows:		Mode 1 MUST only be used when user consent has been provided. The
			details of this consent are left to the implementation; one potential
	Mode 1 MUST only be used when user consent has been provided; this		mechanism is to tie this consent to getUserMedia consent.
	allows trusted WebRTC applications to achieve optimal network
	performance, but significanly limites the network information exposed
	to arbitrary web pages. The details of this consent are left to the
	implementation; one potential mechanism is to tie this consent to
	getUserMedia consent.
	In cases where user consent has not been obtained, Mode 2 SHOULD be		In cases where user consent has not been obtained, Mode 2 SHOULD be
	used. This allows applications to still achieve direct connections		used.
	in many cases, even without consent (e.g., streaming or data channel
	applications). However, implementations MAY choose a stricter
	default policy in certain circumstances.
	Note that these defaults can still be used even for organizations		These defaults provide a reasonable tradeoff that permits trusted
	that want all external WebRTC traffic to traverse a proxy, simply by		WebRTC applications to achieve optimal network performance, but gives
	setting an organizational firewall policy that allows WebRTC traffic		applications without consent (e.g., 1-way streaming or data channel
	to only leave through the proxy. This provides a way to ensure the		applications) only the minimum information needed to achieve direct
	proxy is used for any external traffic, but avoids the performance		connections, as defined in Mode 2. However, implementations MAY
	issues of Mode 4 (where all media is forced through said proxy) for		choose stricter modes if desired, e.g., if a user indicates they want
	intra-organization traffic.		all WebRTC traffic to follow the default route.
			Note that the suggested defaults can still be used even for
			organizations that want all external WebRTC traffic to traverse a
			proxy, simply by setting an organizational firewall policy that
			allows WebRTC traffic to only leave through the proxy. This provides
			a way to ensure the proxy is used for any external traffic, but
			avoids the performance issues associated with Mode 4 (where all media
			is forced through said proxy) for intra-organization traffic.
	6. Implementation Guidance		6. Implementation Guidance
	This section provides guidance to WebRTC implementations on how to		This section provides guidance to WebRTC implementations on how to
	implement the policies described above.		implement the policies described above.
			6.1. Ensuring Normal Routing
	When trying to follow typical IP routing, the simplest approach is to		When trying to follow typical IP routing, the simplest approach is to
	bind the sockets used for p2p connections to the wildcard addresses		bind the sockets used for peer-to-peer connections to the wildcard
	(0.0.0.0 for IPv4, :: for IPv6), which allows the OS to route WebRTC		addresses (0.0.0.0 for IPv4, :: for IPv6), which allows the OS to
	traffic the same way as it would HTTP traffic. STUN and TURN will		route WebRTC traffic the same way as it would HTTP traffic. STUN and
	work as usual, and host candidates can be determined as mentioned		TURN will work as usual, and host candidates can still be determined
	below.		as mentioned below.
	In order to discover the correct local IP addresses, implementations		6.2. Determining Host Candidates
	can use the common trick of binding sockets to the wildcard
	addresses, connect()ing those sockets to the IPv4/IPv6 addresses of
	the web application (obtained by resolving the host component of its
	URI [RFC3986]) and then reading the bound local addresses via
	getsockname(). This requires no data exchange; it simply provides a
	mechanism for applications to retrieve the desired information from
	the kernel routing table.
	Use of the web application IPs ensures the right local IPs are		When binding to a wildcard address, some extra work is needed to
	selected, regardless of where the application is hosted (e.g., on an		determine a suitable host candidate, which we define as the source
	intranet). If the client is behind a proxy and cannot resolve the		address that would be used for any packets sent to the web
	IPs via DNS, the IPv4/v6 addresses of the proxy can be used instead.		application host (assuming that UDP and TCP get the same routing).
	If the web application was loaded from a file:// URI [RFC8089], the		Use of the web application host as a destination ensures the right
	implementation can fall back to a well-known DNS name or IP address.		source address is selected, regardless of where the application
			resides (e.g., on an intranet).
			First, the appropriate remote IPv4/IPv6 address is obtained by
			resolving the host component of the web application URI [RFC3986].
			If the client is behind a proxy and cannot resolve these IPs via DNS,
			the address of the proxy can be used instead. Or, if the web
			application was loaded from a file:// URI [RFC8089], rather than over
			the network, the implementation can fall back to a well-known DNS
			name or IP address.
			Once a suitable remote IP has been determined, the implementation can
			create a UDP socket, bind it to the appropriate wildcard address, and
			tell it to connect to the remote IP. Generally, this results in the
			socket being assigned a local address based on the kernel routing
			table, without sending any packets over the network.
			Finally, the socket can be queried using getsockname() or the
			equivalent to determine the appropriate host candidate.
	7. Application Guidance		7. Application Guidance
	The recommendations mentioned in this document may cause certain		The recommendations mentioned in this document may cause certain
	WebRTC applications to malfunction. In order to be robust in all		WebRTC applications to malfunction. In order to be robust in all
	scenarios, the following guidelines are provided for applications:		scenarios, the following guidelines are provided for applications:
	o Applications SHOULD deploy a TURN server with support for both UDP		o Applications SHOULD deploy a TURN server with support for both UDP
	and TCP connections to the server. This ensures that connectivity		and TCP connections to the server. This ensures that connectivity
	can still be established, even when Mode 3 or 4 are in use,		can still be established, even when Mode 3 or 4 are in use,
	skipping to change at page 9, line 16 ¶		skipping to change at page 9, line 26 ¶
	Protocol (HTTP/1.1): Message Syntax and Routing",		Protocol (HTTP/1.1): Message Syntax and Routing",
	RFC 7230, DOI 10.17487/RFC7230, June 2014,		RFC 7230, DOI 10.17487/RFC7230, June 2014,
	<https://www.rfc-editor.org/info/rfc7230>.		<https://www.rfc-editor.org/info/rfc7230>.
	[RFC8089] Kerwin, M., "The "file" URI Scheme", RFC 8089,		[RFC8089] Kerwin, M., "The "file" URI Scheme", RFC 8089,
	DOI 10.17487/RFC8089, February 2017,		DOI 10.17487/RFC8089, February 2017,
	<https://www.rfc-editor.org/info/rfc8089>.		<https://www.rfc-editor.org/info/rfc8089>.
	Appendix A. Change log		Appendix A. Change log
			Changes in draft -06:
			o Clarify recommendations.
			o Split implementation guidance into two sections.
	Changes in draft -05:		Changes in draft -05:
	o Separated framework definition from implementation techniques.		o Separated framework definition from implementation techniques.
	o Removed RETURN references.		o Removed RETURN references.
	o Use origin when determining local IPs, rather than a well-known		o Use origin when determining local IPs, rather than a well-known
	IP.		IP.
	Changes in draft -04:		Changes in draft -04:
End of changes. 14 change blocks.
	45 lines changed or deleted		66 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/