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/