draft-ietf-rtcweb-ip-handling-09.txt   draft-ietf-rtcweb-ip-handling-10.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 October 12, 2018
Expires: December 15, 2018 Facebook Expires: April 15, 2019
June 13, 2018
WebRTC IP Address Handling Requirements WebRTC IP Address Handling Requirements
draft-ietf-rtcweb-ip-handling-09 draft-ietf-rtcweb-ip-handling-10
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 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 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 December 15, 2018. This Internet-Draft will expire on April 15, 2019.
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 14 skipping to change at page 2, line 14
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 . . . . . . . . . . . . . . . . . . . 7
6.1. Ensuring Normal Routing . . . . . . . . . . . . . . . . . 6 6.1. Ensuring Normal Routing . . . . . . . . . . . . . . . . . 7
6.2. Determining Host Candidates . . . . . . . . . . . . . . . 7 6.2. Determining Host Candidates . . . . . . . . . . . . . . . 7
7. Application Guidance . . . . . . . . . . . . . . . . . . . . 7 7. Application Guidance . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 8 11.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 9 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
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
Protocol (HTTP) [RFC7230]. This may be problematic in certain cases. Protocol (HTTP) [RFC7230]. This may be problematic in certain cases.
This document summarizes the concerns, and makes recommendations on This document summarizes the concerns, and makes recommendations on
skipping to change at page 3, line 45 skipping to change at page 3, line 45
above, direct Internet access is permitted. However, when the above, direct Internet access is permitted. However, when the
term "proxy" is used in this document, it is always in reference term "proxy" is used in this document, it is always in reference
to an [RFC1919] proxy server. to an [RFC1919] proxy server.
Of these three concerns, #1 is the most significant, because for some Of these three concerns, #1 is the most significant, because for some
users, the purpose of using a VPN is for anonymity. However, users, the purpose of using a VPN is for anonymity. However,
different VPN users will have different needs, and some VPN users different VPN users will have different needs, and some VPN users
(e.g., corporate VPN users) may in fact prefer WebRTC to send media (e.g., corporate VPN users) may in fact prefer WebRTC to send media
traffic directly, i.e., not through the VPN. traffic directly, i.e., not through the VPN.
#2 is considered to be a less significant concern, given that the #2 is a less significant but valid concern. While the [RFC4941] IPv6
local address values often contain minimal information (e.g., addresses recommended by [I-D.ietf-rtcweb-transports] are fairly
192.168.0.2), or have built-in privacy protection (e.g., the benign due to their intentionally short lifetimes, IPv4 addresses
[RFC4941] IPv6 addresses recommended by present some challenges. Although they typically contain minimal
[I-D.ietf-rtcweb-transports]). entropy (e.g., 192.168.0.2, a fairly common address), in the worst
case, they can contain 24 bits of entropy with an indefinite
lifetime. As such, they can be a fairly significant fingerprinting
surface. In addition, intranet web sites can be attacked more easily
when their IPv4 address range is externally known.
Private local IP addresses can also act as an identifier that allows
web applications running in isolated browsing contexts (e.g., normal
and private browsing) to learn that they are running on the same
device. This could allow the application sessions to be correlated,
defeating some of the privacy protections provided by isolation. It
should be noted that local addresses are just one potential mechanism
for this correlation and this is an area for further study.
#3 is the least common concern, as proxy administrators can already #3 is the least common concern, as proxy administrators can already
control this behavior through organizational firewall policy, and control this behavior through organizational firewall policy, and
generally, forcing WebRTC traffic through a proxy server will have generally, forcing WebRTC traffic through a proxy server will have
negative effects on both the proxy and on media quality. negative effects on both the proxy and on media quality.
Note also that these concerns predate WebRTC; Adobe Flash Player has Note also that these concerns predate WebRTC; Adobe Flash Player has
provided similar functionality since the introduction of RTMFP provided similar functionality since the introduction of RTMFP
[RFC7016] in 2008. [RFC7016] in 2008.
skipping to change at page 4, line 50 skipping to change at page 5, line 12
1. By default, WebRTC traffic should follow typical IP routing, 1. By default, WebRTC traffic should follow typical IP routing,
i.e., WebRTC should use the same interface used for HTTP traffic, i.e., WebRTC should use the same interface used for HTTP traffic,
and only the system's 'typical' public addresses (or those of an and only the system's 'typical' public addresses (or those of an
enterprise TURN server, if present) should be visible to the enterprise TURN server, if present) should be visible to the
application. However, in the interest of optimal media quality, application. However, in the interest of optimal media quality,
it should be possible to enable WebRTC to make use of all network it should be possible to enable WebRTC to make use of all network
interfaces to determine the ideal route. interfaces to determine the ideal route.
2. By default, WebRTC should be able to negotiate direct peer-to- 2. By default, WebRTC should be able to negotiate direct peer-to-
peer connections between endpoints (i.e., without traversing a peer connections between endpoints (i.e., without traversing a
NAT or relay server), by providing a minimal set of local IP NAT or relay server). This ensures that applications that need
addresses to the application for use in the ICE process. This true peer-to-peer routing for bandwidth or latency reasons can
ensures that applications that need true peer-to-peer routing for operate successfully.
bandwidth or latency reasons can operate successfully. However,
it should be possible to suppress these addresses (with the
resultant impact on direct connections) if desired.
3. By default, WebRTC traffic should not be sent through proxy 3. It should be possible to configure WebRTC to not disclose private
local IP addresses, to avoid the issues associated with web
applications learning such addresses. This document does not
require this to be the default state, as there is no currently
defined mechanism that can satisfy this requirement as well as
the aforementioned requirement to allow direct peer-to-peer
connections.
4. By default, WebRTC traffic should not be sent through proxy
servers, due to the media quality problems associated with servers, due to the media quality problems associated with
sending WebRTC traffic over TCP, which is almost always used when sending WebRTC traffic over TCP, which is almost always used when
communicating with such proxies, as well as proxy performance communicating with such proxies, as well as proxy performance
issues that may result from proxying WebRTC's long-lived, high- issues that may result from proxying WebRTC's long-lived, high-
bandwidth connections. However, it should be possible to force bandwidth connections. However, it should be possible to force
WebRTC to send its traffic through a configured proxy if desired. WebRTC to send its traffic through a configured proxy if desired.
5.2. Modes and Recommendations 5.2. Modes and Recommendations
Based on these ideas, we define four specific modes of WebRTC Based on these ideas, we define four specific modes of WebRTC
skipping to change at page 6, line 26 skipping to change at page 6, line 43
used. used.
These defaults provide a reasonable tradeoff that permits trusted These defaults provide a reasonable tradeoff that permits trusted
WebRTC applications to achieve optimal network performance, but gives WebRTC applications to achieve optimal network performance, but gives
applications without consent (e.g., 1-way streaming or data channel applications without consent (e.g., 1-way streaming or data channel
applications) only the minimum information needed to achieve direct applications) only the minimum information needed to achieve direct
connections, as defined in Mode 2. However, implementations MAY connections, as defined in Mode 2. However, implementations MAY
choose stricter modes if desired, e.g., if a user indicates they want choose stricter modes if desired, e.g., if a user indicates they want
all WebRTC traffic to follow the default route. all WebRTC traffic to follow the default route.
Future versions of this document may define additional modes and/or
update the recommended default modes.
Note that the suggested defaults can still be used even for Note that the suggested defaults can still be used even for
organizations that want all external WebRTC traffic to traverse a organizations that want all external WebRTC traffic to traverse a
proxy or enterprise TURN server, simply by setting an organizational proxy or enterprise TURN server, simply by setting an organizational
firewall policy that allows WebRTC traffic to only leave through the firewall policy that allows WebRTC traffic to only leave through the
proxy or TURN server. This provides a way to ensure the proxy or proxy or TURN server. This provides a way to ensure the proxy or
TURN server is used for any external traffic, but still allows direct TURN server is used for any external traffic, but still allows direct
connections (and, in the proxy case, avoids the performance issues connections (and, in the proxy case, avoids the performance issues
associated with forcing media through said proxy) for intra- associated with forcing media through said proxy) for intra-
organization traffic. organization traffic.
skipping to change at page 8, line 12 skipping to change at page 8, line 32
This document is entirely devoted to security considerations. This document is entirely devoted to security considerations.
9. IANA Considerations 9. IANA Considerations
This document requires no actions from IANA. This document requires no actions from IANA.
10. Acknowledgements 10. Acknowledgements
Several people provided input into this document, including Bernard Several people provided input into this document, including Bernard
Aboba, Harald Alvestrand, Ted Hardie, Matthew Kaufmann, Eric Aboba, Harald Alvestrand, Youenn Fablet, Ted Hardie, Matthew
Rescorla, Adam Roach, and Martin Thomson. Kaufmann, Eric Rescorla, Adam Roach, and Martin Thomson.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 9, line 42 skipping to change at page 10, line 21
Time Communication Use Cases and Requirements", RFC 7478, Time Communication Use Cases and Requirements", RFC 7478,
DOI 10.17487/RFC7478, March 2015, DOI 10.17487/RFC7478, March 2015,
<https://www.rfc-editor.org/info/rfc7478>. <https://www.rfc-editor.org/info/rfc7478>.
[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 -10:
o Incorporate feedback from IETF 102 on the problem space.
o Note that future versions of the document may define new modes.
Changes in draft -09: Changes in draft -09:
o Fixed confusing text regarding enterprise TURN servers. o Fixed confusing text regarding enterprise TURN servers.
Changes in draft -08: Changes in draft -08:
o Discuss how enterprise TURN servers should be handled. o Discuss how enterprise TURN servers should be handled.
Changes in draft -07: Changes in draft -07:
skipping to change at page 11, line 15 skipping to change at page 11, line 47
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:
o Published as WG draft. o Published as WG draft.
Authors' Addresses Author's Address
Justin Uberti Justin Uberti
Google Google
747 6th St S 747 6th St S
Kirkland, WA 98033 Kirkland, WA 98033
USA USA
Email: justin@uberti.name Email: justin@uberti.name
Guo-wei Shieh
Facebook
1101 Dexter Ave
Seattle, WA 98109
USA
Email: guoweis@facebook.com
 End of changes. 14 change blocks. 
27 lines changed or deleted 51 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/