draft-ietf-rtcweb-ip-handling-01.txt		draft-ietf-rtcweb-ip-handling-02.txt
	Network Working Group J. Uberti		Network Working Group J. Uberti
	Internet-Draft G. Shieh		Internet-Draft G. Shieh
	Intended status: Standards Track Google		Intended status: Standards Track Google
	Expires: September 21, 2016 March 20, 2016		Expires: May 4, 2017 October 31, 2016
	WebRTC IP Address Handling Recommendations		WebRTC IP Address Handling Requirements
	draft-ietf-rtcweb-ip-handling-01		draft-ietf-rtcweb-ip-handling-02
	Abstract		Abstract
	This document provides best practices for how IP addresses should be		This document provides best practices for how IP addresses should be
	handled by WebRTC applications.		handled by WebRTC applications.
	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 31 ¶		skipping to change at page 1, line 31 ¶
	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 September 21, 2016.		This Internet-Draft will expire on May 4, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2		2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2
	3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Detailed Design . . . . . . . . . . . . . . . . . . . . . . . 4		4. Detailed Design . . . . . . . . . . . . . . . . . . . . . . . 4
	5. Application Guidance . . . . . . . . . . . . . . . . . . . . 6		5. Application Guidance . . . . . . . . . . . . . . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	9. Informative References . . . . . . . . . . . . . . . . . . . 7		9. Informative References . . . . . . . . . . . . . . . . . . . 6
	Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 8		Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	As a technology that supports peer-to-peer connections, WebRTC may		As a technology that supports peer-to-peer connections, WebRTC may
	send data over different network paths than the path used for HTTP		send data over different network paths than the path used for HTTP
	traffic. This may allow a web application to learn additional		traffic. This may allow a web application to learn additional
	information about the user, which may be problematic in certain		information about the user, which may be problematic in certain
	cases. This document summarizes the concerns, and makes		cases. This document summarizes the concerns, and makes
	recommendations on how best to handle the tradeoff between privacy		recommendations on how best to handle the tradeoff between privacy
	skipping to change at page 4, line 31 ¶		skipping to change at page 4, line 31 ¶
	as candidates, even when binding to the wildcard addresses as		as candidates, even when binding to the wildcard addresses as
	mentioned above. The appropriate addresses here can be		mentioned above. The appropriate addresses here can be
	discovered by the common trick of binding sockets to the wildcard		discovered by the common trick of binding sockets to the wildcard
	addresses, connect()ing those sockets to some well-known public		addresses, connect()ing those sockets to some well-known public
	IP address (one particular example being "8.8.8.8"), and then		IP address (one particular example being "8.8.8.8"), and then
	reading the bound local addresses via getsockname(). This		reading the bound local addresses via getsockname(). This
	approach requires no data exchange; it simply provides a		approach requires no data exchange; it simply provides a
	mechanism for applications to retrieve the desired information		mechanism for applications to retrieve the desired information
	from the kernel routing table.		from the kernel routing table.
	3. When used with audio and video devices, WebRTC requires explicit		3. Gathering all possible candidates SHOULD only be performed when
	user permission to access those devices. We propose that this		some form of user consent has been provided; this thwarts the
	permission grant be expanded to include consent to allow WebRTC		typical drive-by enumeration attacks. The details of this
	to access all IP addresses associated with the user agent, for		consent are left to the implementation; one potential mechanism
	the purpose of finding the absolute best route for media traffic.		is to key this off getUserMedia consent. The getUserMedia
	Combining these permission grants, rather than having the user		suggestion takes into account that the user has provided some
	grant permission individually, is a considered balance; this		consent to the application already; that when doing so the user
	balance takes into account that the user has placed enough trust		typically wants to engage in a conversational session, which
	into the application to allow it to access their devices, that		benefits most from an optimal network path, and lastly, the fact
	when doing so the user typically wants to engage in a		that the underlying issue is complex and difficult to explain,
	conversational session, which benefits most from an optimal		making explicit consent for enumeration troublesome.
	network path, and lastly, the fact that the underlying issue is
	complex, and difficult to explain meaningfully to the user.
	4. Determining whether a web proxy is in use is a complex process,		4. Determining whether a web proxy is in use is a complex process,
	as the answer can depend on the exact site or address being		as the answer can depend on the exact site or address being
	contacted. Furthermore, web proxies that support UDP are not		contacted. Furthermore, web proxies that support UDP are not
	widely deployed today. As a result, when WebRTC is made to go		widely deployed today. As a result, when WebRTC is made to go
	through a proxy, it typically must use TCP, either ICE-TCP		through a proxy, it typically must use TCP, either ICE-TCP
	[RFC6544] or TURN-over-TCP [RFC5766]. Naturally, this has		[RFC6544] or TURN-over-TCP [RFC5766]. Naturally, this has
	attendant costs on media quality and also proxy performance.		attendant costs on media quality and also proxy performance.
	5. RETURN [I-D.ietf-rtcweb-return] is a new proposal for explicit		5. RETURN [I-D.ietf-rtcweb-return] is a new proposal for explicit
	skipping to change at page 5, line 49 ¶		skipping to change at page 5, line 46 ¶
	Mode 4: Force proxy: This forces all WebRTC media traffic through a		Mode 4: Force proxy: This forces all WebRTC media traffic through a
	proxy, if one is configured. If the proxy does not support		proxy, if one is configured. If the proxy does not support
	UDP (as is the case for all HTTP and most SOCKS [RFC1928]		UDP (as is the case for all HTTP and most SOCKS [RFC1928]
	proxies), or the WebRTC implementation does not support UDP		proxies), or the WebRTC implementation does not support UDP
	proxying, the use of UDP will be disabled, and TCP will be		proxying, the use of UDP will be disabled, and TCP will be
	used to send and receive media through the proxy. Use of		used to send and receive media through the proxy. Use of
	TCP will result in reduced quality, in addition to any		TCP will result in reduced quality, in addition to any
	performance considerations associated with sending all		performance considerations associated with sending all
	WebRTC media through the proxy server.		WebRTC media through the proxy server.
	We recommend Mode 1 as the default behavior only if cam/mic		We recommend Mode 1 as the default behavior only if the user has
	permission has been granted, or Mode 2 if this is not the case.		provided some form of consent, as discussed above, or Mode 2 if not.
	Users who prefer Mode 3 or 4 should be able to select a preference or		Users who prefer Mode 3 or 4 should be able to select a preference or
	install an extension to force their browser to operate in the		install an extension to force their browser to operate in the
	specified mode.		specified mode.
	Note that when a RETURN proxy is configured for the interface		Note that when a RETURN proxy is configured for the interface
	associated with the default route, Mode 2 and 3 will cause any		associated with the default route, Mode 2 and 3 will cause any
	external media traffic to go through the RETURN proxy. This provides		external media traffic to go through the RETURN proxy. This provides
	a way to ensure the proxy is used for external traffic, but without		a way to ensure the proxy is used for external traffic, but without
	the performance issues of forcing all media through said proxy.		the performance issues of forcing all media through said proxy.
	skipping to change at page 8, line 7 ¶		skipping to change at page 7, line 48 ¶
	"TCP Candidates with Interactive Connectivity		"TCP Candidates with Interactive Connectivity
	Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544,		Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544,
	March 2012, <http://www.rfc-editor.org/info/rfc6544>.		March 2012, <http://www.rfc-editor.org/info/rfc6544>.
	[RFC7016] Thornburgh, M., "Adobe's Secure Real-Time Media Flow		[RFC7016] Thornburgh, M., "Adobe's Secure Real-Time Media Flow
	Protocol", RFC 7016, DOI 10.17487/RFC7016, November 2013,		Protocol", RFC 7016, DOI 10.17487/RFC7016, November 2013,
	<http://www.rfc-editor.org/info/rfc7016>.		<http://www.rfc-editor.org/info/rfc7016>.
	Appendix A. Change log		Appendix A. Change log
			Changes in draft -02:
			o Recommendations -> Requirements
			o Updated text regarding consent.
	Changes in draft -01:		Changes in draft -01:
	o Incorporated feedback from Adam Roach; changes to discussion of		o Incorporated feedback from Adam Roach; changes to discussion of
	cam/mic permission, as well as use of proxies, and various		cam/mic permission, as well as use of proxies, and various
	editorial changes.		editorial changes.
	o Added several more references.		o Added several more references.
	Changes in draft -00:		Changes in draft -00:
End of changes. 7 change blocks.
	21 lines changed or deleted		25 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/