idnits 2.17.1 draft-ietf-rtcweb-ip-handling-04.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 non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == 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 (July 3, 2017) is 2489 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) -- 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) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 7 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: January 4, 2018 July 3, 2017 7 WebRTC IP Address Handling Requirements 8 draft-ietf-rtcweb-ip-handling-04 10 Abstract 12 This document provides information and requirements for how IP 13 addresses should be handled by WebRTC implementations. 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 January 4, 2018. 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 52 4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 5. Detailed Design . . . . . . . . . . . . . . . . . . . . . . . 4 54 6. Application Guidance . . . . . . . . . . . . . . . . . . . . 6 55 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 56 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 57 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 58 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 60 10.2. Informative References . . . . . . . . . . . . . . . . . 7 61 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 8 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 64 1. Introduction 66 One of WebRTC's key features is its support of peer-to-peer 67 connections. However, when establishing such a connection, which 68 involves connectivity tests using various IP addresses, WebRTC may 69 allow a web application to learn additional information about the 70 user compared to an application that only uses the Hypertext Transfer 71 Protocol (HTTP) [RFC7230]. This may be problematic in certain cases. 72 This document summarizes the concerns, and makes recommendations on 73 how WebRTC implementations should best handle the tradeoff between 74 privacy and media performance. 76 2. Terminology 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC2119]. 82 3. Problem Statement 84 In order to establish a peer-to-peer connection, WebRTC 85 implementations use Interactive Connectivity Establishment (ICE) 86 [RFC5245], which gathers and exchanges all the IP addresses it can 87 discover, using techniques like Session Traversal Utilities for NAT 88 (STUN) [RFC5389] and Traversal Using Relays around NAT (TURN) 89 [RFC5766], in order to check the connectivity of each local-address- 90 remote-address pair and select the best one. The addresses that are 91 gathered usually consist of an endpoint's private physical/virtual 92 addresses and its public Internet addresses. 94 These addresses are exposed upwards to the web application, so that 95 they can be communicated to the remote endpoint. This allows the 96 application to learn more about the local network configuration than 97 it would from a typical HTTP scenario, in which the web server would 98 only see a single public Internet address, i.e. the address from 99 which the HTTP request was sent. 101 The information revealed falls into three categories: 103 1. If the client is behind a Network Address Translator (NAT), the 104 client's private IP addresses, typically [RFC1918] addresses, can 105 be learned. 107 2. If the client tries to hide its physical location through a 108 Virtual Private Network (VPN), and the VPN and local OS support 109 routing over multiple interfaces (i.e., a "split-tunnel" VPN), 110 WebRTC will discover the public address for the VPN as well as 111 the ISP public address that the VPN runs over. 113 3. If the client is behind a proxy (a client-configured "classical 114 application proxy", as defined in [RFC1919], Section 3), but 115 direct access to the Internet is also supported, WebRTC's STUN 116 checks will bypass the proxy and reveal the public address of the 117 client. 119 Of these three concerns, #2 is the most significant concern, since 120 for some users, the purpose of using a VPN is for anonymity. 121 However, different VPN users will have different needs, and some VPN 122 users (e.g. corporate VPN users) may in fact prefer WebRTC to send 123 media traffic directly, i.e., not through the VPN. 125 #3 is a less common concern, as proxy administrators can control this 126 behavior through organization firewall policy if desired, coupled 127 with the fact that forcing WebRTC traffic through a proxy will have 128 negative effects on both the proxy and on media quality. For 129 situations where this is an important consideration, use of a RETURN 130 proxy, as described below, can be an effective solution. 132 #1 is considered to be the least significant concern, given that the 133 local address values often contain minimal information (e.g. 134 192.168.0.2), or have built-in privacy protection (e.g. [RFC4941] 135 IPv6 addresses). 137 Note also that these concerns predate WebRTC; Adobe Flash Player has 138 provided similar functionality since the introduction of RTMFP 139 [RFC7016] in 2008. 141 4. Goals 143 Being peer-to-peer, WebRTC represents a privacy-enabling technology, 144 and therefore we want to avoid solutions that disable WebRTC or make 145 it harder to use. This means that WebRTC should be configured by 146 default to only reveal the minimum amount of information needed to 147 establish a performant WebRTC session, while providing options to 148 reveal additional information upon user consent, or further limit 149 this information if the user has specifically requested this. 150 Specifically, WebRTC should: 152 o Provide a privacy-friendly default behavior which strikes the 153 right balance between privacy and media performance for most users 154 and use cases. 156 o For users who care more about one versus the other, provide a 157 means to customize the experience. 159 5. Detailed Design 161 The key principles for the design are listed below: 163 1. By default, WebRTC should follow normal IP routing rules, to the 164 extent that this is easy to determine (i.e., not considering 165 proxies). This can be accomplished by binding local sockets to 166 the wildcard addresses (0.0.0.0 for IPv4, :: for IPv6), which 167 allows the OS to route WebRTC traffic the same way as it would 168 HTTP traffic, and allows only the 'typical' public addresses to 169 be discovered. 171 2. By default, support for direct connections between hosts (i.e., 172 without traversing a NAT or relay server) should be maintained. 173 To accomplish this, the local IPv4 and IPv6 addresses of the 174 interface used for outgoing STUN traffic should still be surfaced 175 as candidates, even when binding to the wildcard addresses as 176 mentioned above. The appropriate addresses here can be 177 discovered by the common trick of binding sockets to the wildcard 178 addresses, connect()ing those sockets to some well-known public 179 IP address, and then reading the bound local addresses via 180 getsockname(). This approach requires no data exchange; it 181 simply provides a mechanism for applications to retrieve the 182 desired information from the kernel routing table. 184 3. Determining whether a web proxy is in use is a complex process, 185 as the answer can depend on the exact site or address being 186 contacted. Furthermore, web proxies that support UDP are not 187 widely deployed today. As a result, when WebRTC is made to go 188 through a proxy, it typically needs to use TCP, either ICE-TCP 190 [RFC6544] or TURN-over-TCP [RFC5766]. Naturally, this has 191 attendant costs on media quality as well as proxy performance, 192 and should be avoided where possible. 194 4. RETURN [I-D.ietf-rtcweb-return] is a proposal for explicit 195 proxying of WebRTC media traffic. When RETURN proxies are 196 deployed, media and STUN checks will go through the proxy, but 197 without the performance issues associated with sending through a 198 typical web proxy. 200 Based on these ideas, we define four specific modes of WebRTC 201 behavior, reflecting different media quality/privacy tradeoffs: 203 Mode 1: Enumerate all addresses: WebRTC MUST bind to all interfaces 204 individually and use them all to attempt communication with 205 STUN servers, TURN servers, or peers. This will converge on 206 the best media path, and is ideal when media performance is 207 the highest priority, but it discloses the most information. 209 Mode 2: Default route + associated local addresses: WebRTC MUST 210 follow the kernel routing table rules (e.g., by binding 211 solely to the wildcard address), which will typically cause 212 media packets to take the same route as the application's 213 HTTP traffic. In addition, any private IPv4 and IPv6 214 addresses associated with the kernel-chosen interface MUST 215 be discovered through getsockname, as mentioned above, and 216 provided to the application. This ensures that direct 217 connections can still be established in this mode. 219 Mode 3: Default route only: This is the the same as Mode 2, except 220 that the associated private address MUST NOT be provided. 221 This may cause traffic to hairpin through a NAT, fall back 222 to the application TURN server, or fail altogether, with 223 resulting 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 Mode 1 MUST only be used when user consent has been provided; this 236 thwarts the typical drive-by enumeration attacks. The details of 237 this consent are left to the implementation; one potential mechanism 238 is to tie this consent to getUserMedia consent. 240 In cases where user consent has not been obtained, Mode 2 SHOULD be 241 used. This allows applications to still achieve direct connections 242 in many cases, even without consent (e.g., data channel 243 applications). However, user agents MAY choose a stricter default 244 policy in certain circumstances. 246 Note that when a RETURN proxy is configured for the interface 247 associated with the default route, Mode 2 and 3 will cause any 248 external media traffic to go through the RETURN proxy. While the 249 RETURN approach gives the best performance, a similar result can be 250 achieved for non-RETURN proxies via an organization firewall policy 251 that only allows external WebRTC traffic to leave through the proxy 252 (typically, over TCP). This provides a way to ensure the proxy is 253 used for any external traffic, but avoids the performance issues of 254 Mode 4, where all media is forced through said proxy, for intra- 255 organization traffic. 257 6. Application Guidance 259 The recommendations mentioned in this document may cause certain 260 WebRTC applications to malfunction. In order to be robust in all 261 scenarios, the following guidelines are provided for applications: 263 o Applications SHOULD deploy a TURN server with support for both UDP 264 and TCP connections to the server. This ensures that connectivity 265 can still be established, even when Mode 3 or 4 are in use, 266 assuming the TURN server can be reached. 268 o Applications SHOULD detect when they don't have access to the full 269 set of ICE candidates by checking for the presence of host 270 candidates. If no host candidates are present, Mode 3 or 4 above 271 is in use; this knowledge can be useful for diagnostic purposes. 273 7. Security Considerations 275 This document is entirely devoted to security considerations. 277 8. IANA Considerations 279 This document requires no actions from IANA. 281 9. Acknowledgements 283 Several people provided input into this document, including Bernard 284 Aboba, Harald Alvestrand, Ted Hardie, Matthew Kaufmann, Eric 285 Rescorla, Adam Roach, and Martin Thomson. 287 10. References 289 10.1. Normative References 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, 293 DOI 10.17487/RFC2119, March 1997, 294 . 296 10.2. Informative References 298 [I-D.ietf-rtcweb-return] 299 Schwartz, B. and J. Uberti, "Recursively Encapsulated TURN 300 (RETURN) for Connectivity and Privacy in WebRTC", draft- 301 ietf-rtcweb-return-02 (work in progress), March 2017. 303 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 304 and E. Lear, "Address Allocation for Private Internets", 305 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 306 . 308 [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", 309 RFC 1919, DOI 10.17487/RFC1919, March 1996, 310 . 312 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 313 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 314 DOI 10.17487/RFC1928, March 1996, 315 . 317 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 318 Extensions for Stateless Address Autoconfiguration in 319 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 320 . 322 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 323 (ICE): A Protocol for Network Address Translator (NAT) 324 Traversal for Offer/Answer Protocols", RFC 5245, 325 DOI 10.17487/RFC5245, April 2010, 326 . 328 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 329 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 330 DOI 10.17487/RFC5389, October 2008, 331 . 333 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 334 Relays around NAT (TURN): Relay Extensions to Session 335 Traversal Utilities for NAT (STUN)", RFC 5766, 336 DOI 10.17487/RFC5766, April 2010, 337 . 339 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 340 "TCP Candidates with Interactive Connectivity 341 Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, 342 March 2012, . 344 [RFC7016] Thornburgh, M., "Adobe's Secure Real-Time Media Flow 345 Protocol", RFC 7016, DOI 10.17487/RFC7016, November 2013, 346 . 348 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 349 Protocol (HTTP/1.1): Message Syntax and Routing", 350 RFC 7230, DOI 10.17487/RFC7230, June 2014, 351 . 353 Appendix A. Change log 355 Changes in draft -04: 357 o Rewording and cleanup in abstract, intro, and problem statement. 359 o Added 2119 boilerplate. 361 o Fixed weird reference spacing. 363 o Expanded acronyms on first use. 365 o Removed 8.8.8.8 mention. 367 o Removed mention of future browser considerations. 369 Changes in draft -03: 371 o Clarified when to use which modes. 373 o Added 2119 qualifiers to make normative statements. 375 o Defined 'proxy'. 377 o Mentioned split tunnels in problem statement. 379 Changes in draft -02: 381 o Recommendations -> Requirements 383 o Updated text regarding consent. 385 Changes in draft -01: 387 o Incorporated feedback from Adam Roach; changes to discussion of 388 cam/mic permission, as well as use of proxies, and various 389 editorial changes. 391 o Added several more references. 393 Changes in draft -00: 395 o Published as WG draft. 397 Authors' Addresses 399 Justin Uberti 400 Google 401 747 6th St S 402 Kirkland, WA 98033 403 USA 405 Email: justin@uberti.name 407 Guo-wei Shieh 408 Google 409 747 6th St S 410 Kirkland, WA 98033 411 USA 413 Email: guoweis@google.com