idnits 2.17.1 draft-shieh-rtcweb-ip-handling-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2015) is 3111 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Shieh 3 Internet-Draft J. Uberti 4 Intended status: Standards Track Google 5 Expires: April 21, 2016 October 19, 2015 7 WebRTC IP Address Handling Recommendations 8 draft-shieh-rtcweb-ip-handling-00 10 Abstract 12 This document provides best practices for how IP addresses should be 13 handled by WebRTC applications. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on April 21, 2016. 32 Copyright Notice 34 Copyright (c) 2015 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 51 3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 4. Detailed Design . . . . . . . . . . . . . . . . . . . . . . . 4 53 5. Application Guidance . . . . . . . . . . . . . . . . . . . . 5 54 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 55 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 56 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 59 1. Introduction 61 As a technology that supports peer-to-peer connections, WebRTC may 62 send data over different network paths than the path used for HTTP 63 traffic. This may allow a web application to learn additional 64 information about the user, which may be problematic in certain 65 cases. This document summarizes the concerns, and makes 66 recommendations on how best to handle the tradeoff between privacy 67 and media performance. 69 2. Problem Statement 71 WebRTC enables real-time peer-to-peer communications by enumerating 72 network interfaces and discovering the best route through the ICE 73 protocol. During the ICE process, the peers involved in a session 74 gather and exchange all the IP addresses they can discover, so that 75 the connectivity of each IP pair can be checked, and the best path 76 chosen. The addresses that are gathered usually consist of an 77 endpoint's private physical/virtual addresses, and its public 78 Internet addresses. 80 These addresses are exposed upwards to the web application, so that 81 they can be communicated to the remote endpoint. This allows the 82 application to learn more about the local network configuration than 83 it would from a typical HTTP scenario, in which the web server would 84 only see a single public Internet address, i.e. the address from 85 which the HTTP request was sent. 87 The information revealed falls into three categories: 89 (1) If the client is behind a NAT, the client's private IP 90 addresses, typically RFC 1918 addresses, can be learned. 92 (2) If the client tries to hide its physical location through a VPN, 93 and the VPN and local OS supports routing over multiple 94 interfaces, WebRTC will discover the public address associated 95 with both the VPN as well as the ISP public address over that 96 the VPN runs over. 98 (3) If the client is behind a proxy, but direct access to the 99 Internet is also supported, WebRTC's STUN checks will bypass the 100 proxy and reveal the public address of the client. 102 Of these three concerns, #2 is the most significant concern, since 103 for some users, the purpose of using a VPN is for anonymity. 104 However, different VPN users will have different needs, and some VPN 105 users (e.g. corporate VPN users) may in fact prefer WebRTC to send 106 media traffic directly, i.e. not through the VPN. 108 #3 is a less common concern, as proxy administrators can control this 109 behavior through local firewall policy if desired, coupled with the 110 fact that forcing WebRTC traffic through a proxy will have negative 111 effects on both the proxy and on media quality. 113 #1 is considered to be the least significant concern, given that the 114 local address values often contain minimal information (e.g. 115 192.168.0.2), or have built-in privacy protection (e.g. RFC 4941 116 IPv6 addresses). 118 Note also that these concerns predate WebRTC; Adobe Flash Player has 119 provided similar functionality since the introduction of RTMFP in 120 2008. 122 3. Goals 124 Being peer-to-peer, WebRTC represents a privacy-enabling technology, 125 and therefore we want to avoid solutions that disable WebRTC or make 126 it harder to use. This means that WebRTC should be configured by 127 default to only reveal the minimum amount of information needed to 128 establish a performant WebRTC session, while providing options to 129 reveal additional information upon user consent, or further limit 130 this information if the user has specifically requested this. 131 Specifically, WebRTC should: 133 o Provide a privacy-friendly default behavior which strikes the 134 right balance between privacy and media performance for most users 135 and use cases. 137 o For users who care more about one versus the other, provide means 138 to customize the experience. 140 4. Detailed Design 142 The main ideas for the design are the following: 144 o By default, WebRTC should follow the route for HTTP traffic, when 145 this is easy to determine (i.e. not considering proxies). This is 146 accomplished by binding local sockets to the "any" addresses 147 (0.0.0.0 for IPv4, :: for IPv6), which allows the OS to route 148 WebRTC traffic the same way as normal HTTP traffic, and allows 149 only the 'typical' public addresses to be discovered. 151 o By default, support for host-host connections should be 152 maintained. Even when binding to "any" addresses, the local IPv4 153 and IPv6 addresses of the interface used for outgoing STUN traffic 154 should still be surfaced as candidates; this is necessary for 155 certain peer-to-peer data channel apps to function correctly. The 156 appropriate addresses here can be discovered by binding sockets to 157 the "any" addresses, connect()ing those sockets to a public 158 destination (e.g. "8.8.8.8"), and then reading the bound local 159 addresses via getsockname(). 161 o WebRTC incorporates an explicit permission grant for access to 162 local audio and video, which are typically much more sensitive 163 than the aforementioned IP address information. If the user has 164 consented to media access, this should also allow WebRTC to gather 165 all possible candidates and determine the absolute best route for 166 media traffic. 168 o Determining whether a proxy is in use is a complex process, as the 169 answer can depend on the exact site or address being contacted. 170 Furthermore, proxies that support UDP are not widely deployed 171 today. Therefore, the only way to ensure that WebRTC traffic 172 traverses a proxy is to force WebRTC to use ICE-TCP or TURN-over- 173 TCP, and always try to make the TCP connection through the proxy, 174 if one exists. Naturally, this will have attendant costs on media 175 quality and also proxy performance. 177 Based on these ideas, we define four modes of WebRTC behavior, 178 reflecting different privacy/media tradeoffs: 180 Mode 1 Enumerate all addresses: WebRTC will bind to all interfaces 181 individually and use them all to ping STUN servers or peers. 182 This will converge on the best media path, and is ideal when 183 media performance is the highest priority, but it discloses 184 the most information. As such, this should only be performed 185 when the user has explicitly given consent for local media 186 access, as indicated in design idea #3 above. 188 Mode 2 Default route + the single associated local address: By 189 binding solely to the "any" address, media packets will flow 190 through the same route as normal HTTP traffic. In addition, 191 the associated private address is discovered through 192 getsockname, as mentioned above. This ensures that direct 193 connections can still be established even when local media 194 access is not granted, e.g. for data channel applications. 196 Mode 3 Default route only: This is the the same as Mode 2, except 197 that the associated private address is not provided, which 198 may cause traffic to hairpin through NAT or fall back to the 199 application TURN server, with resulting quality implications. 201 Mode 4 Force TCP and proxy: This is disables any use of UDP and 202 forces use of TCP to connect to the TURN server or peer. If 203 a proxy server is configured, the TCP traffic will be sent 204 through the proxy, with resulting quality implications. 206 We recommend Mode 1 as the default behavior only if cam/mic 207 permission has been granted, or Mode 2 if this is not the case. 209 Users who prefer Mode 3 or 4 should be able to select a preference or 210 install an extension to force their browser to operate in the 211 specified mode. For example, Chrome users can install the WebRTC 212 Network Limiter extension for this configuration. 214 5. Application Guidance 216 The recommendations mentioned in this document may cause breakage to 217 certain WebRTC applications. In order to be robust in all scenarios, 218 applications should follow the following guidelines: 220 o Applications should deploy a TURN server with support for both UDP 221 and TCP connections to the server. This ensures that connectivity 222 can still be established, even when Mode 3 or Mode 4 are in use. 224 o Applications can detect when they don't have access to the full 225 set of ICE candidates by checking for the presence of host 226 candidates. If no host candidates are present, Mode 3 or 4 above 227 is in use. 229 o Future versions of browsers may present an indicator to signify 230 that the page is using WebRTC to set up a peer-to-peer connection. 231 Applications should be careful to only use WebRTC in a fashion 232 that is consistent with user expectations. 234 6. Security Considerations 236 This document is entirely devoted to security considerations. 238 7. IANA Considerations 240 This document requires no actions from IANA. 242 8. Acknowledgements 244 Several people provided input into this document, including Harald 245 Alvestrand, Ted Hardie, Matthew Kaufmann, and Eric Rescorla. 247 Authors' Addresses 249 Guo-wei Shieh 250 Google 251 747 6th Ave S 252 Kirkland, WA 98033 253 USA 255 Email: guoweis@google.com 257 Justin Uberti 258 Google 259 747 6th Ave S 260 Kirkland, WA 98033 261 USA 263 Email: justin@uberti.name