idnits 2.17.1 draft-ietf-rtcweb-ip-handling-03.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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 190: '...ddresses: WebRTC MUST bind to all inte...' RFC 2119 keyword, line 196: '...ssociated local addresses: WebRTC MUST...' RFC 2119 keyword, line 201: '... with the kernel-chosen interface MUST...' RFC 2119 keyword, line 207: '... private address MUST NOT be provided....' RFC 2119 keyword, line 222: '... Mode 1 MUST only be used when user ...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 14, 2017) is 2649 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) == Unused Reference: 'I-D.ietf-rtcweb-return' is defined on line 281, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 286, but no explicit reference was found in the text == Unused Reference: 'RFC1928' is defined on line 295, but no explicit reference was found in the text == Unused Reference: 'RFC4941' is defined on line 300, but no explicit reference was found in the text == Unused Reference: 'RFC5245' is defined on line 305, but no explicit reference was found in the text == Unused Reference: 'RFC5389' is defined on line 311, but no explicit reference was found in the text == Unused Reference: 'RFC7016' is defined on line 327, but no explicit reference was found in the text == 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: 1 error (**), 0 flaws (~~), 10 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: July 18, 2017 January 14, 2017 7 WebRTC IP Address Handling Requirements 8 draft-ietf-rtcweb-ip-handling-03 10 Abstract 12 This document provides information and requirements for how IP 13 addresses should be 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 July 18, 2017. 32 Copyright Notice 34 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . 6 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 interfaces 96 (i.e., a "split-tunnel" VPN), WebRTC will discover the public 97 address for the VPN as well as the ISP public address that the 98 VPN runs over. 100 3. If the client is behind a proxy (a client-configured "classical 101 application proxy", as defined in [RFC1919], Section 3), but 102 direct access to the Internet is also supported, WebRTC's STUN 103 [RFC5389]checks will bypass the proxy and reveal the public 104 address of the client. 106 Of these three concerns, #2 is the most significant concern, since 107 for some users, the purpose of using a VPN is for anonymity. 108 However, different VPN users will have different needs, and some VPN 109 users (e.g. corporate VPN users) may in fact prefer WebRTC to send 110 media traffic directly, i.e., not through the VPN. 112 #3 is a less common concern, as proxy administrators can control this 113 behavior through organization firewall policy if desired, coupled 114 with the fact that forcing WebRTC traffic through a proxy will have 115 negative effects on both the proxy and on media quality. For 116 situations where this is an important consideration, use of a RETURN 117 proxy, as described below, can be an effective solution. 119 #1 is considered to be the least significant concern, given that the 120 local address values often contain minimal information (e.g. 121 192.168.0.2), or have built-in privacy protection (e.g. 122 [RFC4941]IPv6 addresses). 124 Note also that these concerns predate WebRTC; Adobe Flash Player has 125 provided similar functionality since the introduction of RTMFP 126 [RFC7016]in 2008. 128 3. Goals 130 Being peer-to-peer, WebRTC represents a privacy-enabling technology, 131 and therefore we want to avoid solutions that disable WebRTC or make 132 it harder to use. This means that WebRTC should be configured by 133 default to only reveal the minimum amount of information needed to 134 establish a performant WebRTC session, while providing options to 135 reveal additional information upon user consent, or further limit 136 this information if the user has specifically requested this. 137 Specifically, WebRTC should: 139 o Provide a privacy-friendly default behavior which strikes the 140 right balance between privacy and media performance for most users 141 and use cases. 143 o For users who care more about one versus the other, provide a 144 means to customize the experience. 146 4. Detailed Design 148 The key principles for the design are listed below: 150 1. By default, WebRTC should follow normal IP routing rules, to the 151 extent that this is easy to determine (i.e., not considering 152 proxies). This can be accomplished by binding local sockets to 153 the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which 154 allows the OS to route WebRTC traffic the same way as it would 155 HTTP traffic, and allows only the 'typical' public addresses to 156 be discovered. 158 2. By default, support for direct connections between hosts (i.e., 159 without traversing a NAT or relay server) should be maintained. 160 To accomplish this, the local IPv4 and IPv6 addresses of the 161 interface used for outgoing STUN traffic should still be surfaced 162 as candidates, even when binding to the wildcard addresses as 163 mentioned above. The appropriate addresses here can be 164 discovered by the common trick of binding sockets to the wildcard 165 addresses, connect()ing those sockets to some well-known public 166 IP address (one particular example being "8.8.8.8"), and then 167 reading the bound local addresses via getsockname(). This 168 approach requires no data exchange; it simply provides a 169 mechanism for applications to retrieve the desired information 170 from the kernel routing table. 172 3. Determining whether a web proxy is in use is a complex process, 173 as the answer can depend on the exact site or address being 174 contacted. Furthermore, web proxies that support UDP are not 175 widely deployed today. As a result, when WebRTC is made to go 176 through a proxy, it typically needs to use TCP, either ICE-TCP 177 [RFC6544]or TURN-over-TCP [RFC5766]. Naturally, this has 178 attendant costs on media quality as well as proxy performance, 179 and should be avoided where possible. 181 4. RETURN [I-D.ietf-rtcweb-return]is a proposal for explicit 182 proxying of WebRTC media traffic. When RETURN proxies are 183 deployed, media and STUN checks will go through the proxy, but 184 without the performance issues associated with sending through a 185 typical web proxy. 187 Based on these ideas, we define four specific modes of WebRTC 188 behavior, reflecting different media quality/privacy tradeoffs: 190 Mode 1: Enumerate all addresses: WebRTC MUST bind to all interfaces 191 individually and use them all to attempt communication with 192 STUN servers, TURN servers, or peers. This will converge on 193 the best media path, and is ideal when media performance is 194 the highest priority, but it discloses the most information. 196 Mode 2: Default route + associated local addresses: WebRTC MUST 197 follow the kernel routing table rules (e.g., by binding 198 solely to the wildcard address), which will typically cause 199 media packets to take the same route as the application's 200 HTTP traffic. In addition, any private IPv4 and IPv6 201 addresses associated with the kernel-chosen interface MUST 202 be discovered through getsockname, as mentioned above, and 203 provided to the application. This ensures that direct 204 connections can still be established in this mode. 206 Mode 3: Default route only: This is the the same as Mode 2, except 207 that the associated private address MUST NOT be provided. 208 This may cause traffic to hairpin through a NAT, fall back 209 to the application TURN server, or fail altogether, with 210 resulting quality implications. 212 Mode 4: Force proxy: This forces all WebRTC media traffic through a 213 proxy, if one is configured. If the proxy does not support 214 UDP (as is the case for all HTTP and most SOCKS 215 [RFC1928]proxies), or the WebRTC implementation does not 216 support UDP proxying, the use of UDP will be disabled, and 217 TCP will be used to send and receive media through the 218 proxy. Use of TCP will result in reduced quality, in 219 addition to any performance considerations associated with 220 sending all WebRTC media through the proxy server. 222 Mode 1 MUST only be used when user consent has been provided; this 223 thwarts the typical drive-by enumeration attacks. The details of 224 this consent are left to the implementation; one potential mechanism 225 is to tie this consent to getUserMedia consent. 227 In cases where user consent has not been obtained, Mode 2 SHOULD be 228 used. This allows applications to still achieve direct connections 229 in many cases, even without consent (e.g., data channel 230 applications). However, user agents MAY choose a stricter default 231 policy in certain circumstances. 233 Note that when a RETURN proxy is configured for the interface 234 associated with the default route, Mode 2 and 3 will cause any 235 external media traffic to go through the RETURN proxy. While the 236 RETURN approach gives the best performance, a similar result can be 237 achieved for non-RETURN proxies via an organization firewall policy 238 that only allows external WebRTC traffic to leave through the proxy 239 (typically, over TCP). This provides a way to ensure the proxy is 240 used for any external traffic, but avoids the performance issues of 241 Mode 4, where all media is forced through said proxy, for intra- 242 organization traffic. 244 5. Application Guidance 246 The recommendations mentioned in this document may cause certain 247 WebRTC applications to malfunction. In order to be robust in all 248 scenarios, the following guidelines are provided for applications: 250 o Applications SHOULD deploy a TURN server with support for both UDP 251 and TCP connections to the server. This ensures that connectivity 252 can still be established, even when Mode 3 or 4 are in use, 253 assuming the TURN server can be reached. 255 o Applications SHOULD detect when they don't have access to the full 256 set of ICE candidates by checking for the presence of host 257 candidates. If no host candidates are present, Mode 3 or 4 above 258 is in use; this knowledge can be useful for diagnostic purposes. 260 o Future versions of browsers may present an indicator to signify 261 that the page is using WebRTC to set up a peer-to-peer connection. 262 Applications MUST only use WebRTC in a fashion that is consistent 263 with user expectations. 265 6. Security Considerations 267 This document is entirely devoted to security considerations. 269 7. IANA Considerations 271 This document requires no actions from IANA. 273 8. Acknowledgements 275 Several people provided input into this document, including Harald 276 Alvestrand, Ted Hardie, Matthew Kaufmann, Eric Rescorla, Adam Roach, 277 and Martin Thomson. 279 9. Informative References 281 [I-D.ietf-rtcweb-return] 282 Schwartz, B. and J. Uberti, "Recursively Encapsulated TURN 283 (RETURN) for Connectivity and Privacy in WebRTC", draft- 284 ietf-rtcweb-return-01 (work in progress), January 2016. 286 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 287 and E. Lear, "Address Allocation for Private Internets", 288 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 289 . 291 [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", 292 RFC 1919, DOI 10.17487/RFC1919, March 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 -03: 335 o Clarified when to use which modes. 337 o Use 2119 qualifiers to make normative statements. 339 o Defined 'proxy'. 341 o Mentioned split tunnels in problem statement. 343 Changes in draft -02: 345 o Recommendations -> Requirements 347 o Updated text regarding consent. 349 Changes in draft -01: 351 o Incorporated feedback from Adam Roach; changes to discussion of 352 cam/mic permission, as well as use of proxies, and various 353 editorial changes. 355 o Added several more references. 357 Changes in draft -00: 359 o Published as WG draft. 361 Authors' Addresses 363 Justin Uberti 364 Google 365 747 6th St S 366 Kirkland, WA 98033 367 USA 369 Email: justin@uberti.name 371 Guo-wei Shieh 372 Google 373 747 6th St S 374 Kirkland, WA 98033 375 USA 377 Email: guoweis@google.com