idnits 2.17.1 draft-ietf-rtcweb-ip-handling-01.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 (March 20, 2016) is 2930 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) == Outdated reference: A later version (-02) exists of draft-ietf-rtcweb-return-01 -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Uberti 3 Internet-Draft G. Shieh 4 Intended status: Standards Track Google 5 Expires: September 21, 2016 March 20, 2016 7 WebRTC IP Address Handling Recommendations 8 draft-ietf-rtcweb-ip-handling-01 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 September 21, 2016. 32 Copyright Notice 34 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . 6 54 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 55 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 56 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 57 9. Informative References . . . . . . . . . . . . . . . . . . . 7 58 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 8 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 61 1. Introduction 63 As a technology that supports peer-to-peer connections, WebRTC may 64 send data over different network paths than the path used for HTTP 65 traffic. This may allow a web application to learn additional 66 information about the user, which may be problematic in certain 67 cases. This document summarizes the concerns, and makes 68 recommendations on how best to handle the tradeoff between privacy 69 and media performance. 71 2. Problem Statement 73 WebRTC enables real-time peer-to-peer communications by enumerating 74 network interfaces and discovering the best route through the ICE 75 [RFC5245] protocol. During the ICE process, the peers involved in a 76 session gather and exchange all the IP addresses they can discover, 77 so that the connectivity of each IP pair can be checked, and the best 78 path chosen. The addresses that are gathered usually consist of an 79 endpoint's private physical/virtual addresses, and its public 80 Internet addresses. 82 These addresses are exposed upwards to the web application, so that 83 they can be communicated to the remote endpoint. This allows the 84 application to learn more about the local network configuration than 85 it would from a typical HTTP scenario, in which the web server would 86 only see a single public Internet address, i.e. the address from 87 which the HTTP request was sent. 89 The information revealed falls into three categories: 91 1. If the client is behind a NAT, the client's private IP addresses, 92 typically [RFC1918] addresses, can be learned. 94 2. If the client tries to hide its physical location through a VPN, 95 and the VPN and local OS support routing over multiple 96 interfaces, WebRTC will discover the public address for the VPN 97 as well as the ISP public address that the VPN runs over. 99 3. If the client is behind a proxy, but direct access to the 100 Internet is also supported, WebRTC's STUN [RFC5389] checks will 101 bypass the proxy and reveal the public address of the client. 103 Of these three concerns, #2 is the most significant concern, since 104 for some users, the purpose of using a VPN is for anonymity. 105 However, different VPN users will have different needs, and some VPN 106 users (e.g. corporate VPN users) may in fact prefer WebRTC to send 107 media traffic directly, i.e. not through the VPN. 109 #3 is a less common concern, as proxy administrators can control this 110 behavior through local firewall policy if desired, coupled with the 111 fact that forcing WebRTC traffic through a proxy will have negative 112 effects on both the proxy and on media quality. For situations where 113 this is an important consideration, use of a RETURN proxy, as 114 described below, can be an effective solution. 116 #1 is considered to be the least significant concern, given that the 117 local address values often contain minimal information (e.g. 118 192.168.0.2), or have built-in privacy protection (e.g. [RFC4941] 119 IPv6 addresses). 121 Note also that these concerns predate WebRTC; Adobe Flash Player has 122 provided similar functionality since the introduction of RTMFP 123 [RFC7016] in 2008. 125 3. Goals 127 Being peer-to-peer, WebRTC represents a privacy-enabling technology, 128 and therefore we want to avoid solutions that disable WebRTC or make 129 it harder to use. This means that WebRTC should be configured by 130 default to only reveal the minimum amount of information needed to 131 establish a performant WebRTC session, while providing options to 132 reveal additional information upon user consent, or further limit 133 this information if the user has specifically requested this. 134 Specifically, WebRTC should: 136 o Provide a privacy-friendly default behavior which strikes the 137 right balance between privacy and media performance for most users 138 and use cases. 140 o For users who care more about one versus the other, provide a 141 means to customize the experience. 143 4. Detailed Design 145 The main ideas for the design are the following: 147 1. By default, WebRTC should follow normal IP routing rules, to the 148 extent that this is easy to determine (i.e., not considering 149 proxies). This can be accomplished by binding local sockets to 150 the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which 151 allows the OS to route WebRTC traffic the same way as it would 152 HTTP traffic, and allows only the 'typical' public addresses to 153 be discovered. 155 2. By default, support for direct connections between hosts (i.e., 156 without traversing a NAT or relay server) should be maintained. 157 To accomplish this, the local IPv4 and IPv6 addresses of the 158 interface used for outgoing STUN traffic should still be surfaced 159 as candidates, even when binding to the wildcard addresses as 160 mentioned above. The appropriate addresses here can be 161 discovered by the common trick of binding sockets to the wildcard 162 addresses, connect()ing those sockets to some well-known public 163 IP address (one particular example being "8.8.8.8"), and then 164 reading the bound local addresses via getsockname(). This 165 approach requires no data exchange; it simply provides a 166 mechanism for applications to retrieve the desired information 167 from the kernel routing table. 169 3. When used with audio and video devices, WebRTC requires explicit 170 user permission to access those devices. We propose that this 171 permission grant be expanded to include consent to allow WebRTC 172 to access all IP addresses associated with the user agent, for 173 the purpose of finding the absolute best route for media traffic. 174 Combining these permission grants, rather than having the user 175 grant permission individually, is a considered balance; this 176 balance takes into account that the user has placed enough trust 177 into the application to allow it to access their devices, that 178 when doing so the user typically wants to engage in a 179 conversational session, which benefits most from an optimal 180 network path, and lastly, the fact that the underlying issue is 181 complex, and difficult to explain meaningfully to the user. 183 4. Determining whether a web proxy is in use is a complex process, 184 as the answer can depend on the exact site or address being 185 contacted. Furthermore, web proxies that support UDP are not 186 widely deployed today. As a result, when WebRTC is made to go 187 through a proxy, it typically must use TCP, either ICE-TCP 188 [RFC6544] or TURN-over-TCP [RFC5766]. Naturally, this has 189 attendant costs on media quality and also proxy performance. 191 5. RETURN [I-D.ietf-rtcweb-return] is a new proposal for explicit 192 proxying of WebRTC media traffic. When RETURN proxies are 193 deployed, media and STUN checks will go through the proxy, but 194 without the performance issues associated with sending through a 195 typical web proxy. 197 Based on these ideas, we define four modes of WebRTC behavior, 198 reflecting different privacy/media tradeoffs: 200 Mode 1: Enumerate all addresses: WebRTC will bind to all interfaces 201 individually and use them all to attempt communication with 202 STUN servers, TURN servers, or peers. This will converge on 203 the best media path, and is ideal when media performance is 204 the highest priority, but it discloses the most information. 205 As such, this should only be performed when the user has 206 explicitly given consent for local media access, as 207 indicated in design idea #3 above. 209 Mode 2: Default route + the single associated local address: By 210 binding solely to the wildcard address, media packets will 211 follow the kernel routing table rules, which will typically 212 result in the same route as the application's HTTP traffic. 213 In addition, the associated private address will be 214 discovered through getsockname, as mentioned above. This 215 ensures that direct connections can still be established 216 even when local media access is not granted, e.g., for data 217 channel applications. 219 Mode 3: Default route only: This is the the same as Mode 2, except 220 that the associated private address is not provided, which 221 may cause traffic to hairpin through a NAT, fall back to the 222 application TURN server, or fail altogether, with resulting 223 quality implications. 225 Mode 4: Force proxy: This forces all WebRTC media traffic through a 226 proxy, if one is configured. If the proxy does not support 227 UDP (as is the case for all HTTP and most SOCKS [RFC1928] 228 proxies), or the WebRTC implementation does not support UDP 229 proxying, the use of UDP will be disabled, and TCP will be 230 used to send and receive media through the proxy. Use of 231 TCP will result in reduced quality, in addition to any 232 performance considerations associated with sending all 233 WebRTC media through the proxy server. 235 We recommend Mode 1 as the default behavior only if cam/mic 236 permission has been granted, or Mode 2 if this is not the case. 238 Users who prefer Mode 3 or 4 should be able to select a preference or 239 install an extension to force their browser to operate in the 240 specified mode. 242 Note that when a RETURN proxy is configured for the interface 243 associated with the default route, Mode 2 and 3 will cause any 244 external media traffic to go through the RETURN proxy. This provides 245 a way to ensure the proxy is used for external traffic, but without 246 the performance issues of forcing all media through said proxy. 248 5. Application Guidance 250 The recommendations mentioned in this document may cause certain 251 WebRTC applications to malfunction. In order to be robust in all 252 scenarios, applications should follow the following guidelines: 254 o Applications should deploy a TURN server with support for both UDP 255 and TCP connections to the server. This ensures that connectivity 256 can still be established, even when Mode 3 or 4 are in use, 257 assuming the TURN server can be reached. 259 o Applications can detect when they don't have access to the full 260 set of ICE candidates by checking for the presence of host 261 candidates. If no host candidates are present, Mode 3 or 4 above 262 is in use. 264 o Future versions of browsers may present an indicator to signify 265 that the page is using WebRTC to set up a peer-to-peer connection. 266 Applications should be careful to only use WebRTC in a fashion 267 that is consistent with user expectations. 269 6. Security Considerations 271 This document is entirely devoted to security considerations. 273 7. IANA Considerations 275 This document requires no actions from IANA. 277 8. Acknowledgements 279 Several people provided input into this document, including Harald 280 Alvestrand, Ted Hardie, Matthew Kaufmann, Eric Rescorla, and Adam 281 Roach. 283 9. Informative References 285 [I-D.ietf-rtcweb-return] 286 Schwartz, B. and J. Uberti, "Recursively Encapsulated TURN 287 (RETURN) for Connectivity and Privacy in WebRTC", draft- 288 ietf-rtcweb-return-01 (work in progress), January 2016. 290 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 291 and E. Lear, "Address Allocation for Private Internets", 292 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 293 . 295 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 296 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 297 DOI 10.17487/RFC1928, March 1996, 298 . 300 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 301 Extensions for Stateless Address Autoconfiguration in 302 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 303 . 305 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 306 (ICE): A Protocol for Network Address Translator (NAT) 307 Traversal for Offer/Answer Protocols", RFC 5245, 308 DOI 10.17487/RFC5245, April 2010, 309 . 311 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 312 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 313 DOI 10.17487/RFC5389, October 2008, 314 . 316 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 317 Relays around NAT (TURN): Relay Extensions to Session 318 Traversal Utilities for NAT (STUN)", RFC 5766, 319 DOI 10.17487/RFC5766, April 2010, 320 . 322 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 323 "TCP Candidates with Interactive Connectivity 324 Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, 325 March 2012, . 327 [RFC7016] Thornburgh, M., "Adobe's Secure Real-Time Media Flow 328 Protocol", RFC 7016, DOI 10.17487/RFC7016, November 2013, 329 . 331 Appendix A. Change log 333 Changes in draft -01: 335 o Incorporated feedback from Adam Roach; changes to discussion of 336 cam/mic permission, as well as use of proxies, and various 337 editorial changes. 339 o Added several more references. 341 Changes in draft -00: 343 o Published as WG draft. 345 Authors' Addresses 347 Justin Uberti 348 Google 349 747 6th St S 350 Kirkland, WA 98033 351 USA 353 Email: justin@uberti.name 355 Guo-wei Shieh 356 Google 357 747 6th St S 358 Kirkland, WA 98033 359 USA 361 Email: guoweis@google.com