draft-ietf-rtcweb-return-01.txt		draft-ietf-rtcweb-return-02.txt
	Network Working Group B. Schwartz		Network Working Group B. Schwartz
	Internet-Draft J. Uberti		Internet-Draft J. Uberti
	Intended status: Standards Track Google		Intended status: Standards Track Google
	Expires: July 29, 2016 January 26, 2016		Expires: September 28, 2017 March 27, 2017
	Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in		Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in
	WebRTC		WebRTC
	draft-ietf-rtcweb-return-01		draft-ietf-rtcweb-return-02
	Abstract		Abstract
	In the context of WebRTC, the concept of a local TURN proxy has been		In the context of WebRTC, the concept of a local TURN proxy has been
	suggested, but not reviewed in detail. WebRTC applications are		suggested, but not reviewed in detail. WebRTC applications are
	already using TURN to enhance connectivity and privacy. This		already using TURN to enhance connectivity and privacy. This
	document explains how local TURN proxies and WebRTC applications can		document explains how local TURN proxies and WebRTC applications can
	work together.		work together.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 July 29, 2016.		This Internet-Draft will expire on September 28, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Visual Overview of RETURN . . . . . . . . . . . . . . . . . . 4		2. Visual Overview of RETURN . . . . . . . . . . . . . . . . . . 3
	3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8		3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . 8		3.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . 8
	3.2. Independent Path Control . . . . . . . . . . . . . . . . 9		3.2. Independent Path Control . . . . . . . . . . . . . . . . 9
	4. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 9		4. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.1. Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . 9		4.1. Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.2. Virtual interface . . . . . . . . . . . . . . . . . . . . 10		4.2. Virtual interface . . . . . . . . . . . . . . . . . . . . 10
	4.3. Proxy configuration leakiness . . . . . . . . . . . . . . 10		4.3. Proxy configuration leakiness . . . . . . . . . . . . . . 10
	4.4. Sealed proxy rank . . . . . . . . . . . . . . . . . . . . 10		4.4. Sealed proxy rank . . . . . . . . . . . . . . . . . . . . 10
	5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11		5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.1. ICE candidates produced in the presence of a proxy . . . 11		5.1. ICE candidates produced in the presence of a proxy . . . 11
	skipping to change at page 3, line 30 ¶		skipping to change at page 3, line 30 ¶
	network operators may operate a TURN server for their network, which		network operators may operate a TURN server for their network, which
	can be discovered by clients using TURN Auto-Discovery		can be discovered by clients using TURN Auto-Discovery
	[I-D.ietf-tram-turn-server-discovery], or through a proprietary		[I-D.ietf-tram-turn-server-discovery], or through a proprietary
	mechanism. This TURN server may be placed inside the network, with a		mechanism. This TURN server may be placed inside the network, with a
	firewall configuration allowing it to communicate with the public		firewall configuration allowing it to communicate with the public
	internet, or it may be operated by a third party outside the network,		internet, or it may be operated by a third party outside the network,
	with a firewall configuration that allows hosts inside the network to		with a firewall configuration that allows hosts inside the network to
	communicate with it. Use of the specified TURN server may be the		communicate with it. Use of the specified TURN server may be the
	only way for clients on the network to achieve a high quality WebRTC		only way for clients on the network to achieve a high quality WebRTC
	experience. This scenario is required to be supported by the WebRTC		experience. This scenario is required to be supported by the WebRTC
	requirements document [I-D.ietf-rtcweb-use-cases-and-requirements]		requirements document [RFC7478] Section 2.3.5.1.
	Section 3.3.5.1.
	When the application intends to use a TURN server for identity		When the application intends to use a TURN server for identity
	cloaking, and the enterprise network administrator intends to use a		cloaking, and the enterprise network administrator intends to use a
	TURN server for connectivity, there is a conflict. In current WebRTC		TURN server for connectivity, there is a conflict. In current WebRTC
	implementations, TURN can only be used on a single-hop basis in each		implementations, TURN can only be used on a single-hop basis in each
	candidate, but using only the enterprise's TURN server reveals		candidate, but using only the enterprise's TURN server reveals
	information about the user (e.g. organizational affiliation), and		information about the user (e.g. organizational affiliation), and
	using only the application's TURN server may be blocked by the		using only the application's TURN server may be blocked by the
	network administrator, or may require using TURN-TCP or TURN-TLS,		network administrator, or may require using TURN-TCP or TURN-TLS,
	resulting in a significant sacrifice in latency.		resulting in a significant sacrifice in latency.
	skipping to change at page 4, line 37 ¶		skipping to change at page 4, line 34 ¶
	..... Non encapsulated		..... Non encapsulated
	- - - TURN encapsulated		- - - TURN encapsulated
	|| Network edge		|| Network edge
	Figure 1: Basic WebRTC ICE Candidates with TURN Server		Figure 1: Basic WebRTC ICE Candidates with TURN Server
	Figure 1 shows a browser located inside a home or enterprise network		Figure 1 shows a browser located inside a home or enterprise network
	which connects to the Internet through a Network Address Translator		which connects to the Internet through a Network Address Translator
	and Firewall (NAT/FW). A TURN server in the Internet cloud is also		and Firewall (NAT/FW). A TURN server in the Internet cloud is also
	shown, which is provided by the WebRTC application via the JavaScript		shown, which is provided by the WebRTC application via the JavaScript
	IceServers object.		RTCIceServers object.
	A WebRTC application can use a TURN server to provide NAT traversal,		A WebRTC application can use a TURN server to provide NAT traversal,
	but also to provide privacy, routing optimizations, logging, or		but also to provide privacy, routing optimizations, logging, or
	possibly other functionality. The application can accomplish this by		possibly other functionality. The application can accomplish this by
	forcing all traffic to flow through the TURN server using the		forcing all traffic to flow through the TURN server using the
	JavaScript RTCIceTransportPolicy object [I-D.ietf-rtcweb-jsep].		JavaScript RTCIceTransportPolicy object [I-D.ietf-rtcweb-jsep].
	Since this TURN server is injected by the application, we will refer		Since this TURN server is injected by the application, we will refer
	to it as an Application TURN server.		to it as an Application TURN server.
	____________ inside network || outside network		____________ inside network || outside network
	skipping to change at page 8, line 47 ¶		skipping to change at page 8, line 47 ¶
	Figure 5: Similarity between HTTP/HTTPS Proxy and TURN Proxy		Figure 5: Similarity between HTTP/HTTPS Proxy and TURN Proxy
	3. Goals		3. Goals
	These goals are requirements on this document (not on implementations		These goals are requirements on this document (not on implementations
	of the specification).		of the specification).
	3.1. Connectivity		3.1. Connectivity
	As noted in [I-D.ietf-rtcweb-use-cases-and-requirements]		As noted in [RFC7478] Section 2.3.5.1 and requirement F20, a WebRTC
	Section 3.3.5.1 and requirement F20, a WebRTC browser endpoint MUST		browser endpoint MUST be able to direct UDP connections through a
	be able to direct UDP connections through a designated TURN server		designated TURN server configured by enterprise policy (a "proxy").
	configured by enterprise policy (a "proxy").
	It MUST be possible to configure a WebRTC endpoint that supports		It MUST be possible to configure a WebRTC endpoint that supports
	proxies to achieve connectivity no worse than if the endpoint were		proxies to achieve connectivity no worse than if the endpoint were
	operating at the proxy's address.		operating at the proxy's address.
	For efficiency, network administrators SHOULD be able to prevent		For efficiency, network administrators SHOULD be able to prevent
	browsers from attempting to send traffic through routes that are		browsers from attempting to send traffic through routes that are
	already known to be blocked.		already known to be blocked.
	3.2. Independent Path Control		3.2. Independent Path Control
	skipping to change at page 9, line 31 ¶		skipping to change at page 9, line 31 ¶
	o monitoring the usage of UDP services,		o monitoring the usage of UDP services,
	o troubleshooting and debugging problematic services,		o troubleshooting and debugging problematic services,
	o logging connection metadata for legal or auditing reasons,		o logging connection metadata for legal or auditing reasons,
	o recording the entire contents of all connections, or		o recording the entire contents of all connections, or
	o providing partial IP address anonymization (as described in		o providing partial IP address anonymization (as described in
	[I-D.ietf-rtcweb-security] Section 4.2.4).		[I-D.ietf-rtcweb-security] Section 4.2.4 and
			[I-D.ietf-rtcweb-security-arch] Section 5.4).
	4. Concepts		4. Concepts
	To achieve our goals, we introduce the following new concepts:		To achieve our goals, we introduce the following new concepts:
	4.1. Proxy		4.1. Proxy
	In this document a "proxy" is any TURN server that was provided by		In this document a "proxy" is any TURN server that was provided by
	any mechanism other than through the standard WebRTC-application ICE		any mechanism other than through the standard WebRTC-application ICE
	candidate provisioning API [I-D.ietf-rtcweb-jsep]. We call it a		candidate provisioning API [I-D.ietf-rtcweb-jsep]. We call it a
	"proxy" by analogy with SOCKS proxies and similar network services,		"proxy" by analogy with SOCKS proxies and similar network services,
	because it performs a similar function and can be configured in a		because it performs a similar function and can be configured in a
	similar fashion.		similar fashion.
	If a proxy is to be used, it will be the destination of traffic		If a proxy is to be used, it will be the destination of traffic
	generated by the client. (There is no analogue to the transparent/		generated by the client. (There is no analogue to the transparent/
	intercepting HTTP proxy configuration, which modifies traffic at the		intercepting HTTP proxy configuration, which modifies traffic at the
	network layer.) Mechanisms to configure a proxy include Auto-		network layer.) Mechanisms to configure a proxy include Auto-
	Discovery [I-D.ietf-tram-turn-server-discovery] and local policy		Discovery [I-D.ietf-tram-turn-server-discovery] and local policy
	([I-D.ietf-rtcweb-jsep], "ICE candidate policy").		([I-D.ietf-rtcweb-jsep] Section 3.5.3, "ICE candidate policy").
	In an application context, a proxy may be "active" (producing		In an application context, a proxy may be "active" (producing
	candidates) or "inactive" (not in use, having no effect on the		candidates) or "inactive" (not in use, having no effect on the
	context).		context).
	4.2. Virtual interface		4.2. Virtual interface
	A typical WebRTC browser endpoint may have multiple network		A typical WebRTC browser endpoint may have multiple network
	interfaces available, such as wired ethernet, wireless ethernet, and		interfaces available, such as wired ethernet, wireless ethernet, and
	WAN. In this document, a "virtual interface" is a procedure for		WAN. In this document, a "virtual interface" is a procedure for
	skipping to change at page 12, line 15 ¶		skipping to change at page 12, line 15 ¶
	5.5. Multiple physical interfaces		5.5. Multiple physical interfaces
	Some operating systems allow the browser to use multiple interfaces		Some operating systems allow the browser to use multiple interfaces
	to contact a single remote IP address. To avoid producing an		to contact a single remote IP address. To avoid producing an
	excessive number of candidates, WebRTC endpoints MUST NOT use		excessive number of candidates, WebRTC endpoints MUST NOT use
	multiple physical interfaces to connect to a single proxy		multiple physical interfaces to connect to a single proxy
	simultaneously. (If this were violated, it could produce a number of		simultaneously. (If this were violated, it could produce a number of
	virtual interfaces equal to the product of the number of physical		virtual interfaces equal to the product of the number of physical
	interfaces and the number of active proxies.)		interfaces and the number of active proxies.)
	For strategies to choose the best interface for communication with a		Mechanisms for configuring a RETURN proxy SHOULD allow configuring a
	proxy, see [I-D.reddy-mmusic-ice-best-interface-pcp]. Similar		proxy that only applies to connections made from a single physical
	considerations apply when connecting to an application-specified TURN		interface. This is useful to optimize efficiency in modes 2 and 3 of
	server in the presence of physical and virtual interfaces.		[I-D.ietf-rtcweb-ip-handling].
	5.6. IPv4 and IPv6		5.6. IPv4 and IPv6
	A proxy MAY have both an IPv4 and an IPv6 address (e.g. if the proxy		A proxy MAY have both an IPv4 and an IPv6 address (e.g. if the proxy
	is specified by DNS and has both A and AAAA records). The client MAY		is specified by DNS and has both A and AAAA records). The client MAY
	try both of these addresses, but MUST select one, preferring IPv6,		try both of these addresses, but MUST select one, preferring IPv6,
	before allocating any remote addresses. This corresponds to the the		before allocating any remote addresses. This corresponds to the the
	Happy Eyeballs [RFC6555] procedure for dual-stack clients.		Happy Eyeballs [RFC6555] procedure for dual-stack clients.
	A proxy MAY provide both IPv4 and IPv6 remote addresses to clients		A proxy MAY provide both IPv4 and IPv6 remote addresses to clients
	skipping to change at page 16, line 36 ¶		skipping to change at page 16, line 36 ¶
	endpoint does not reply with a positive indication of ICE consent,		endpoint does not reply with a positive indication of ICE consent,
	but no such restriction applies to other applications that access the		but no such restriction applies to other applications that access the
	TURN server. Administrators should take care to provide TURN access		TURN server. Administrators should take care to provide TURN access
	credentials only to the users who are authorized to have global UDP		credentials only to the users who are authorized to have global UDP
	network access.		network access.
	TURN proxies and application TURN servers can provide some privacy		TURN proxies and application TURN servers can provide some privacy
	protection by obscuring the identity of one peer from the other.		protection by obscuring the identity of one peer from the other.
	However, unencrypted TURN provides no additional privacy from an		However, unencrypted TURN provides no additional privacy from an
	observer who can monitor the link between the TURN client and server,		observer who can monitor the link between the TURN client and server,
	and even encrypted TURN ([I-D.ietf-tram-stun-dtls] Section 4.6) does		and even encrypted TURN ([RFC7350] Section 4.6) does not provide
	not provide significant privacy from an observer who sniff traffic on		significant privacy from an observer who sniff traffic on both legs
	both legs of the TURN connection, due to packet timing correlations.		of the TURN connection, due to packet timing correlations.
	8. IANA Considerations		8. IANA Considerations
	This document requires no actions from IANA.		This document requires no actions from IANA.
	9. Acknowledgements		9. Acknowledgements
	Thanks to Harald Alvestrand, Philipp Hancke, Tirumaleswar Reddy, Alan		Thanks to Harald Alvestrand, Philipp Hancke, Tirumaleswar Reddy, Alan
	Johnston, John Yoakum, and Cullen Jennings for suggestions to improve		Johnston, John Yoakum, and Cullen Jennings for suggestions to improve
	the content and presentation. Special thanks to Alan Johnston for		the content and presentation. Special thanks to Alan Johnston for
	contributing the visual overview in Section 2.		contributing the visual overview in Section 2.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[I-D.ietf-rtcweb-jsep]		[I-D.ietf-rtcweb-jsep]
	Uberti, J. and C. Jennings, "Javascript Session		Uberti, J., Jennings, C., and E. Rescorla, "Javascript
	Establishment Protocol", draft-ietf-rtcweb-jsep-06 (work		Session Establishment Protocol", draft-ietf-rtcweb-jsep-19
	in progress), February 2014.		(work in progress), March 2017.
			[I-D.ietf-tram-turn-server-discovery]
			Patil, P., Reddy, T., and D. Wing, "TURN Server Auto
			Discovery", draft-ietf-tram-turn-server-discovery-12 (work
			in progress), January 2017.
	[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and		[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
	L. Jones, "SOCKS Protocol Version 5", RFC 5766, March		L. Jones, "SOCKS Protocol Version 5", RFC 1928,
	1996.		DOI 10.17487/RFC1928, March 1996,
			<http://www.rfc-editor.org/info/rfc1928>.
	[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment		[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
	(ICE): A Protocol for Network Address Translator (NAT)		(ICE): A Protocol for Network Address Translator (NAT)
	Traversal for Offer/Answer Protocols", RFC 5245, April		Traversal for Offer/Answer Protocols", RFC 5245,
	2010.		DOI 10.17487/RFC5245, April 2010,
			<http://www.rfc-editor.org/info/rfc5245>.
	[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using		[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
	Relays around NAT (TURN): Relay Extensions to Session		Relays around NAT (TURN): Relay Extensions to Session
	Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.		Traversal Utilities for NAT (STUN)", RFC 5766,
			DOI 10.17487/RFC5766, April 2010,
			<http://www.rfc-editor.org/info/rfc5766>.
	[RFC6156] Camarillo, G., Novo, O., and S. Perreault, "Traversal		[RFC6156] Camarillo, G., Novo, O., and S. Perreault, Ed., "Traversal
	Using Relays around NAT (TURN) Extension for IPv6", RFC		Using Relays around NAT (TURN) Extension for IPv6",
	6156, April 2011.		RFC 6156, DOI 10.17487/RFC6156, April 2011,
			<http://www.rfc-editor.org/info/rfc6156>.
	[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with		[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
	Dual-Stack Hosts", RFC 6555, April 2012.		Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
			2012, <http://www.rfc-editor.org/info/rfc6555>.
	10.2. Informative References		10.2. Informative References
			[I-D.ietf-rtcweb-ip-handling]
			Uberti, J. and G. Shieh, "WebRTC IP Address Handling
			Requirements", draft-ietf-rtcweb-ip-handling-03 (work in
			progress), January 2017.
	[I-D.ietf-rtcweb-security]		[I-D.ietf-rtcweb-security]
	Rescorla, E., "Security Considerations for WebRTC", ietf-		Rescorla, E., "Security Considerations for WebRTC", draft-
	rtcweb-security-07 (work in progress), July 2014.		ietf-rtcweb-security-08 (work in progress), February 2015.
	[I-D.ietf-rtcweb-use-cases-and-requirements]		[I-D.ietf-rtcweb-security-arch]
	Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-		Rescorla, E., "WebRTC Security Architecture", draft-ietf-
	Time Communication Use-cases and Requirements", ietf-		rtcweb-security-arch-12 (work in progress), June 2016.
	rtcweb-use-cases-and-requirements-14 (work in progress),
	February 2014.
	[I-D.ietf-tram-stun-dtls]		[RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport
	Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport
	Layer Security (DTLS) as Transport for Session Traversal		Layer Security (DTLS) as Transport for Session Traversal
	Utilities for NAT (STUN)", ietf-rtcweb-use-cases-and-		Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350,
	requirements-14 (work in progress), June 2014.		August 2014, <http://www.rfc-editor.org/info/rfc7350>.
	[I-D.ietf-tram-turn-server-discovery]
	Patil, P., Reddy, T., and D. Wing, "TURN Server Auto
	Discovery", draft-ietf-tram-turn-server-discovery-00 (work
	in progress), July 2014.
	[I-D.reddy-mmusic-ice-best-interface-pcp]		[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
	Reddy, T., Wing, D., VerSteeg, B., Penno, R., and V.		Time Communication Use Cases and Requirements", RFC 7478,
	Singh, "Improving ICE Interface Selection Using Port		DOI 10.17487/RFC7478, March 2015,
	Control Protocol (PCP) Flow Extension", draft-ietf-tram-		<http://www.rfc-editor.org/info/rfc7478>.
	turn-server-discovery-00 (work in progress), October 2013.
	Authors' Addresses		Authors' Addresses
	Benjamin M. Schwartz		Benjamin M. Schwartz
	Google, Inc.		Google, Inc.
	111 8th Ave		111 8th Ave
	New York, NY 10011		New York, NY 10011
	USA		USA
	Email: bemasc@webrtc.org		Email: bemasc@webrtc.org
End of changes. 24 change blocks.
	54 lines changed or deleted		60 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/