idnits 2.17.1 draft-ietf-rtcweb-ip-handling-10.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 (October 12, 2018) is 1995 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 Google 4 Intended status: Standards Track October 12, 2018 5 Expires: April 15, 2019 7 WebRTC IP Address Handling Requirements 8 draft-ietf-rtcweb-ip-handling-10 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 https://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 15, 2019. 32 Copyright Notice 34 Copyright (c) 2018 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 (https://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 5.1. Principles . . . . . . . . . . . . . . . . . . . . . . . 4 55 5.2. Modes and Recommendations . . . . . . . . . . . . . . . . 5 56 6. Implementation Guidance . . . . . . . . . . . . . . . . . . . 7 57 6.1. Ensuring Normal Routing . . . . . . . . . . . . . . . . . 7 58 6.2. Determining Host Candidates . . . . . . . . . . . . . . . 7 59 7. Application Guidance . . . . . . . . . . . . . . . . . . . . 8 60 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 63 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 65 11.2. Informative References . . . . . . . . . . . . . . . . . 8 66 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 10 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 69 1. Introduction 71 One of WebRTC's key features is its support of peer-to-peer 72 connections. However, when establishing such a connection, which 73 involves connection attempts from various IP addresses, WebRTC may 74 allow a web application to learn additional information about the 75 user compared to an application that only uses the Hypertext Transfer 76 Protocol (HTTP) [RFC7230]. This may be problematic in certain cases. 77 This document summarizes the concerns, and makes recommendations on 78 how WebRTC implementations should best handle the tradeoff between 79 privacy and media performance. 81 2. Terminology 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 3. Problem Statement 89 In order to establish a peer-to-peer connection, WebRTC 90 implementations use Interactive Connectivity Establishment (ICE) 91 [RFC5245], which attempts to discover multiple IP addresses using 92 techniques such as Session Traversal Utilities for NAT (STUN) 93 [RFC5389] and Traversal Using Relays around NAT (TURN) [RFC5766], and 94 then checks the connectivity of each local-address-remote-address 95 pair in order to select the best one. The addresses that are 96 collected usually consist of an endpoint's private physical/virtual 97 addresses and its public Internet addresses. 99 These addresses are exposed upwards to the web application, so that 100 they can be communicated to the remote endpoint for its checks. This 101 allows the application to learn more about the local network 102 configuration than it would from a typical HTTP scenario, in which 103 the web server would only see a single public Internet address, i.e., 104 the address from which the HTTP request was sent. 106 The information revealed falls into three categories: 108 1. If the client is multihomed, additional public IP addresses for 109 the client can be learned. In particular, if the client tries to 110 hide its physical location through a Virtual Private Network 111 (VPN), and the VPN and local OS support routing over multiple 112 interfaces (a "split-tunnel" VPN), WebRTC will discover not only 113 the public address for the VPN, but also the ISP public address 114 over which the VPN is running. 116 2. If the client is behind a Network Address Translator (NAT), the 117 client's private IP addresses, often [RFC1918] addresses, can be 118 learned. 120 3. If the client is behind a proxy (a client-configured "classical 121 application proxy", as defined in [RFC1919], Section 3), but 122 direct access to the Internet is permitted, WebRTC's STUN checks 123 will bypass the proxy and reveal the public IP address of the 124 client. This concern also applies to the "enterprise TURN 125 server" scenario described in [RFC7478], Section 2.3.5.1, if, as 126 above, direct Internet access is permitted. However, when the 127 term "proxy" is used in this document, it is always in reference 128 to an [RFC1919] proxy server. 130 Of these three concerns, #1 is the most significant, because for some 131 users, the purpose of using a VPN is for anonymity. However, 132 different VPN users will have different needs, and some VPN users 133 (e.g., corporate VPN users) may in fact prefer WebRTC to send media 134 traffic directly, i.e., not through the VPN. 136 #2 is a less significant but valid concern. While the [RFC4941] IPv6 137 addresses recommended by [I-D.ietf-rtcweb-transports] are fairly 138 benign due to their intentionally short lifetimes, IPv4 addresses 139 present some challenges. Although they typically contain minimal 140 entropy (e.g., 192.168.0.2, a fairly common address), in the worst 141 case, they can contain 24 bits of entropy with an indefinite 142 lifetime. As such, they can be a fairly significant fingerprinting 143 surface. In addition, intranet web sites can be attacked more easily 144 when their IPv4 address range is externally known. 146 Private local IP addresses can also act as an identifier that allows 147 web applications running in isolated browsing contexts (e.g., normal 148 and private browsing) to learn that they are running on the same 149 device. This could allow the application sessions to be correlated, 150 defeating some of the privacy protections provided by isolation. It 151 should be noted that local addresses are just one potential mechanism 152 for this correlation and this is an area for further study. 154 #3 is the least common concern, as proxy administrators can already 155 control this behavior through organizational firewall policy, and 156 generally, forcing WebRTC traffic through a proxy server will have 157 negative effects on both the proxy and on media quality. 159 Note also that these concerns predate WebRTC; Adobe Flash Player has 160 provided similar functionality since the introduction of RTMFP 161 [RFC7016] in 2008. 163 4. Goals 165 WebRTC's support of secure peer-to-peer connections facilitates 166 deployment of decentralized systems, which can have privacy benefits. 167 As a result, we want to avoid blunt solutions that disable WebRTC or 168 make it significantly harder to use. This document takes a more 169 nuanced approach, with the following goals: 171 o Provide a framework for understanding the problem so that controls 172 might be provided to make different tradeoffs regarding 173 performance and privacy concerns with WebRTC. 175 o Using that framework, define settings that enable peer-to-peer 176 communications, each with a different balance between performance 177 and privacy. 179 o Finally, provide recommendations for default settings that provide 180 reasonable performance without also exposing addressing 181 information in a way that might violate user expectations. 183 5. Detailed Design 185 5.1. Principles 187 The key principles for our framework are stated below: 189 1. By default, WebRTC traffic should follow typical IP routing, 190 i.e., WebRTC should use the same interface used for HTTP traffic, 191 and only the system's 'typical' public addresses (or those of an 192 enterprise TURN server, if present) should be visible to the 193 application. However, in the interest of optimal media quality, 194 it should be possible to enable WebRTC to make use of all network 195 interfaces to determine the ideal route. 197 2. By default, WebRTC should be able to negotiate direct peer-to- 198 peer connections between endpoints (i.e., without traversing a 199 NAT or relay server). This ensures that applications that need 200 true peer-to-peer routing for bandwidth or latency reasons can 201 operate successfully. 203 3. It should be possible to configure WebRTC to not disclose private 204 local IP addresses, to avoid the issues associated with web 205 applications learning such addresses. This document does not 206 require this to be the default state, as there is no currently 207 defined mechanism that can satisfy this requirement as well as 208 the aforementioned requirement to allow direct peer-to-peer 209 connections. 211 4. By default, WebRTC traffic should not be sent through proxy 212 servers, due to the media quality problems associated with 213 sending WebRTC traffic over TCP, which is almost always used when 214 communicating with such proxies, as well as proxy performance 215 issues that may result from proxying WebRTC's long-lived, high- 216 bandwidth connections. However, it should be possible to force 217 WebRTC to send its traffic through a configured proxy if desired. 219 5.2. Modes and Recommendations 221 Based on these ideas, we define four specific modes of WebRTC 222 behavior, reflecting different media quality/privacy tradeoffs: 224 Mode 1: Enumerate all addresses: WebRTC MUST use all network 225 interfaces to attempt communication with STUN servers, TURN 226 servers, or peers. This will converge on the best media 227 path, and is ideal when media performance is the highest 228 priority, but it discloses the most information. 230 Mode 2: Default route + associated local addresses: WebRTC MUST 231 follow the kernel routing table rules, which will typically 232 cause media packets to take the same route as the 233 application's HTTP traffic. If an enterprise TURN server is 234 present, the preferred route MUST be through this TURN 235 server. Once an interface has been chosen, the private IPv4 236 and IPv6 addresses associated with this interface MUST be 237 discovered and provided to the application. This ensures 238 that direct connections can still be established in this 239 mode. 241 Mode 3: Default route only: This is the the same as Mode 2, except 242 that the associated private addresses MUST NOT be provided; 243 the only IP addresses gathered are those discovered via 244 mechanisms like STUN and TURN (on the default route). This 245 may cause traffic to hairpin through a NAT, fall back to an 246 application TURN server, or fail altogether, with resulting 247 quality implications. 249 Mode 4: Force proxy: This is the same as Mode 3, but when the 250 application's HTTP traffic is sent through a proxy, WebRTC 251 media traffic MUST also be proxied. If the proxy does not 252 support UDP (as is the case for all HTTP and most SOCKS 253 [RFC1928] proxies), or the WebRTC implementation does not 254 support UDP proxying, the use of UDP will be disabled, and 255 TCP will be used to send and receive media through the 256 proxy. Use of TCP will result in reduced media quality, in 257 addition to any performance considerations associated with 258 sending all WebRTC media through the proxy server. 260 Mode 1 MUST only be used when user consent has been provided. The 261 details of this consent are left to the implementation; one potential 262 mechanism is to tie this consent to getUserMedia consent. 263 Alternatively, implementations can provide a specific mechanism to 264 obtain user consent. 266 In cases where user consent has not been obtained, Mode 2 SHOULD be 267 used. 269 These defaults provide a reasonable tradeoff that permits trusted 270 WebRTC applications to achieve optimal network performance, but gives 271 applications without consent (e.g., 1-way streaming or data channel 272 applications) only the minimum information needed to achieve direct 273 connections, as defined in Mode 2. However, implementations MAY 274 choose stricter modes if desired, e.g., if a user indicates they want 275 all WebRTC traffic to follow the default route. 277 Future versions of this document may define additional modes and/or 278 update the recommended default modes. 280 Note that the suggested defaults can still be used even for 281 organizations that want all external WebRTC traffic to traverse a 282 proxy or enterprise TURN server, simply by setting an organizational 283 firewall policy that allows WebRTC traffic to only leave through the 284 proxy or TURN server. This provides a way to ensure the proxy or 285 TURN server is used for any external traffic, but still allows direct 286 connections (and, in the proxy case, avoids the performance issues 287 associated with forcing media through said proxy) for intra- 288 organization traffic. 290 6. Implementation Guidance 292 This section provides guidance to WebRTC implementations on how to 293 implement the policies described above. 295 6.1. Ensuring Normal Routing 297 When trying to follow typical IP routing, the simplest approach is to 298 bind the sockets used for peer-to-peer connections to the wildcard 299 addresses (0.0.0.0 for IPv4, :: for IPv6), which allows the OS to 300 route WebRTC traffic the same way as it would HTTP traffic. STUN and 301 TURN will work as usual, and host candidates can still be determined 302 as mentioned below. 304 6.2. Determining Host Candidates 306 When binding to a wildcard address, some extra work is needed to 307 determine a suitable host candidate, which we define as the source 308 address that would be used for any packets sent to the web 309 application host (assuming that UDP and TCP get the same routing). 310 Use of the web application host as a destination ensures the right 311 source address is selected, regardless of where the application 312 resides (e.g., on an intranet). 314 First, the appropriate remote IPv4/IPv6 address is obtained by 315 resolving the host component of the web application URI [RFC3986]. 316 If the client is behind a proxy and cannot resolve these IPs via DNS, 317 the address of the proxy can be used instead. Or, if the web 318 application was loaded from a file:// URI [RFC8089], rather than over 319 the network, the implementation can fall back to a well-known DNS 320 name or IP address. 322 Once a suitable remote IP has been determined, the implementation can 323 create a UDP socket, bind it to the appropriate wildcard address, and 324 tell it to connect to the remote IP. Generally, this results in the 325 socket being assigned a local address based on the kernel routing 326 table, without sending any packets over the network. 328 Finally, the socket can be queried using getsockname() or the 329 equivalent to determine the appropriate host candidate. 331 7. Application Guidance 333 The recommendations mentioned in this document may cause certain 334 WebRTC applications to malfunction. In order to be robust in all 335 scenarios, the following guidelines are provided for applications: 337 o Applications SHOULD deploy a TURN server with support for both UDP 338 and TCP connections to the server. This ensures that connectivity 339 can still be established, even when Mode 3 or 4 are in use, 340 assuming the TURN server can be reached. 342 o Applications SHOULD detect when they don't have access to the full 343 set of ICE candidates by checking for the presence of host 344 candidates. If no host candidates are present, Mode 3 or 4 above 345 is in use; this knowledge can be useful for diagnostic purposes. 347 8. Security Considerations 349 This document is entirely devoted to security considerations. 351 9. IANA Considerations 353 This document requires no actions from IANA. 355 10. Acknowledgements 357 Several people provided input into this document, including Bernard 358 Aboba, Harald Alvestrand, Youenn Fablet, Ted Hardie, Matthew 359 Kaufmann, Eric Rescorla, Adam Roach, and Martin Thomson. 361 11. References 363 11.1. Normative References 365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", BCP 14, RFC 2119, 367 DOI 10.17487/RFC2119, March 1997, 368 . 370 11.2. Informative References 372 [I-D.ietf-rtcweb-transports] 373 Alvestrand, H., "Transports for WebRTC", draft-ietf- 374 rtcweb-transports-17 (work in progress), October 2016. 376 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 377 and E. Lear, "Address Allocation for Private Internets", 378 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 379 . 381 [RFC1919] Chatel, M., "Classical versus Transparent IP Proxies", 382 RFC 1919, DOI 10.17487/RFC1919, March 1996, 383 . 385 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 386 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 387 DOI 10.17487/RFC1928, March 1996, 388 . 390 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 391 Resource Identifier (URI): Generic Syntax", STD 66, 392 RFC 3986, DOI 10.17487/RFC3986, January 2005, 393 . 395 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 396 Extensions for Stateless Address Autoconfiguration in 397 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 398 . 400 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 401 (ICE): A Protocol for Network Address Translator (NAT) 402 Traversal for Offer/Answer Protocols", RFC 5245, 403 DOI 10.17487/RFC5245, April 2010, 404 . 406 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 407 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 408 DOI 10.17487/RFC5389, October 2008, 409 . 411 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 412 Relays around NAT (TURN): Relay Extensions to Session 413 Traversal Utilities for NAT (STUN)", RFC 5766, 414 DOI 10.17487/RFC5766, April 2010, 415 . 417 [RFC7016] Thornburgh, M., "Adobe's Secure Real-Time Media Flow 418 Protocol", RFC 7016, DOI 10.17487/RFC7016, November 2013, 419 . 421 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 422 Protocol (HTTP/1.1): Message Syntax and Routing", 423 RFC 7230, DOI 10.17487/RFC7230, June 2014, 424 . 426 [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 427 Time Communication Use Cases and Requirements", RFC 7478, 428 DOI 10.17487/RFC7478, March 2015, 429 . 431 [RFC8089] Kerwin, M., "The "file" URI Scheme", RFC 8089, 432 DOI 10.17487/RFC8089, February 2017, 433 . 435 Appendix A. Change log 437 Changes in draft -10: 439 o Incorporate feedback from IETF 102 on the problem space. 441 o Note that future versions of the document may define new modes. 443 Changes in draft -09: 445 o Fixed confusing text regarding enterprise TURN servers. 447 Changes in draft -08: 449 o Discuss how enterprise TURN servers should be handled. 451 Changes in draft -07: 453 o Clarify consent guidance. 455 Changes in draft -06: 457 o Clarify recommendations. 459 o Split implementation guidance into two sections. 461 Changes in draft -05: 463 o Separated framework definition from implementation techniques. 465 o Removed RETURN references. 467 o Use origin when determining local IPs, rather than a well-known 468 IP. 470 Changes in draft -04: 472 o Rewording and cleanup in abstract, intro, and problem statement. 474 o Added 2119 boilerplate. 476 o Fixed weird reference spacing. 478 o Expanded acronyms on first use. 480 o Removed 8.8.8.8 mention. 482 o Removed mention of future browser considerations. 484 Changes in draft -03: 486 o Clarified when to use which modes. 488 o Added 2119 qualifiers to make normative statements. 490 o Defined 'proxy'. 492 o Mentioned split tunnels in problem statement. 494 Changes in draft -02: 496 o Recommendations -> Requirements 498 o Updated text regarding consent. 500 Changes in draft -01: 502 o Incorporated feedback from Adam Roach; changes to discussion of 503 cam/mic permission, as well as use of proxies, and various 504 editorial changes. 506 o Added several more references. 508 Changes in draft -00: 510 o Published as WG draft. 512 Author's Address 513 Justin Uberti 514 Google 515 747 6th St S 516 Kirkland, WA 98033 517 USA 519 Email: justin@uberti.name