idnits 2.17.1 draft-schwartz-rtcweb-return-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 : ---------------------------------------------------------------------------- ** 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 137: '...browser endpoint MUST be able to direc...' RFC 2119 keyword, line 141: '... It MUST be possible to configure a ...' RFC 2119 keyword, line 145: '...k administrators SHOULD be able to pre...' RFC 2119 keyword, line 152: '... applications MUST have the ability ...' RFC 2119 keyword, line 155: '...e WebRTC browser MAY attempt to preven...' (20 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 19, 2014) is 3532 days in the past. Is this intentional? 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 (-26) exists of draft-ietf-rtcweb-jsep-06 ** Obsolete normative reference: RFC 5766 (ref. 'RFC1928') (Obsoleted by RFC 8656) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Duplicate reference: RFC5766, mentioned in 'RFC5766', was also mentioned in 'RFC1928'. ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) == Outdated reference: A later version (-12) exists of draft-ietf-tram-turn-server-discovery-00 == Outdated reference: A later version (-12) exists of draft-ietf-tram-turn-server-discovery-00 -- Duplicate reference: draft-ietf-tram-turn-server-discovery, mentioned in 'I-D.reddy-mmusic-ice-best-interface-pcp', was also mentioned in 'I-D.ietf-tram-turn-server-discovery'. Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Schwartz 3 Internet-Draft Google 4 Intended status: Standards Track August 19, 2014 5 Expires: February 20, 2015 7 Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in 8 WebRTC 9 draft-schwartz-rtcweb-return-00 11 Abstract 13 In the context of WebRTC, the concept of a local TURN proxy has been 14 suggested, but not reviewed in detail. WebRTC applications are 15 already using TURN to enhance connectivity and privacy. This 16 document explains how local TURN proxies and WebRTC applications can 17 work together. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on February 20, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Virtual interface . . . . . . . . . . . . . . . . . . . . 5 60 3.3. Proxy configuration leakiness . . . . . . . . . . . . . . 5 61 3.4. Sealed proxy rank . . . . . . . . . . . . . . . . . . . . 5 62 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.1. ICE candidates produced in the presence of a proxy . . . 6 64 4.2. Leaky proxy configuration . . . . . . . . . . . . . . . . 6 65 4.3. Sealed proxy configuration . . . . . . . . . . . . . . . 6 66 4.4. Proxy rank . . . . . . . . . . . . . . . . . . . . . . . 7 67 4.5. Multiple physical interfaces . . . . . . . . . . . . . . 7 68 4.6. Unspecified leakiness . . . . . . . . . . . . . . . . . . 7 69 4.7. Interaction with SOCKS5-UDP . . . . . . . . . . . . . . . 7 70 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 5.1. Firewalled enterprise network with a basic application . 7 72 5.2. Conflicting proxies configured by Auto-Discovery and 73 local policy . . . . . . . . . . . . . . . . . 8 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 79 9.2. Informative References . . . . . . . . . . . . . . . . . 10 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 82 1. Introduction 84 TURN [RFC5766] is a protocol for communication between a client and a 85 TURN server, in order to route UDP traffic to and from one or more 86 peers. As noted in [RFC5766], the TURN relay server "typically sits 87 in the public Internet". In a WebRTC context, if a TURN server is to 88 be used, it is typically provided by the application, either to 89 provide connectivity between users whose NATs would otherwise prevent 90 it, or to obscure the identity of the participants by concealing 91 their IP addresses from one another. 93 In many enterprises, direct UDP transmissions are not permitted 94 between clients on the internal networks and external IP addresses, 95 so media must flow over TCP. To enable WebRTC services in such a 96 situation, clients must use TURN-TCP, or TURN-TLS. These 97 configurations are not ideal: they send all traffic over TCP, which 98 leads to higher latency than would otherwise be necessary, and they 99 force the application provider to operate a TURN server because 100 WebRTC endpoints behind NAT cannot typically act as TCP servers. 101 These configurations may result in especially bad behaviors when 102 operating through TCP or HTTP proxies that were not designed to carry 103 real-time media streams. 105 To avoid forcing WebRTC media streams through a TCP stage, enterprise 106 network operators may operate a TURN server for their network, which 107 can be discovered by clients using TURN Auto-Discovery 108 [I-D.ietf-tram-turn-server-discovery], or through a proprietary 109 mechanism. Use of the specified TURN server may be the only way for 110 clients on the network to achieve a high quality WebRTC experience. 111 This scenario is required to be supported by the WebRTC requirements 112 document [I-D.ietf-rtcweb-use-cases-and-requirements] 113 Section 3.3.5.1. 115 When the application intends to use a TURN server for identity 116 cloaking, and the enterprise network administrator intends to use a 117 TURN server for connectivity, there is a conflict. In current WebRTC 118 implementations, only a single TURN server can be used in one 119 candidate, but using only the enterprise's TURN server reveals 120 information about the user (e.g. organizational affiliation), and 121 using only the application's TURN server may be blocked by the 122 network administrator, or may require using TURN-TCP or TURN-TLS, 123 resulting in a significant sacrifice in latency. 125 To resolve this conflict, we introduce Recursively Encapsulated TURN, 126 a procedure that allows a WebRTC endpoint to route traffic through 127 multiple TURN servers, and get improved connectivity and privacy in 128 return. 130 2. Goals 132 These goals are requirements on this document (not on implementations 133 of the specification). 135 2.1. Connectivity 136 As noted in [I-D.ietf-rtcweb-use-cases-and-requirements] 137 Section 3.3.5.1, a WebRTC browser endpoint MUST be able to direct UDP 138 connections through a designated TURN server configured by enterprise 139 policy (a "proxy"). 141 It MUST be possible to configure a WebRTC endpoint that supports 142 proxies to achieve connectivity no worse than if the endpoint were 143 operating at the proxy's address. 145 For efficiency, network administrators SHOULD be able to prevent 146 browsers from attempting to send traffic through routes that are 147 already known to be blocked. 149 2.2. Privacy 151 To prevent WebRTC peers from determining each others' IP addresses, 152 applications MUST have the ability to direct all traffic through an 153 application-specified TURN server. 155 A compatible WebRTC browser MAY attempt to prevent a hostile web page 156 from determining the endpoint's public IP address. (The measures 157 proposed here are not sufficient by themselves to achieve this goal. 158 Implementing this specification in current browsers would still leave 159 many other ways for a malicious website to determine the endpoint's 160 IP address. Operating-system-wide VPN configurations are therefore 161 currently preferred for this purpose.) 163 A compatible WebRTC browser MAY allow the user to prevent non- 164 malicious web pages from accidentally revealing the IP address of 165 remote peers to a local passive network adversary. This ability 166 SHOULD NOT reduce performance when it is not in use. (Due to the 167 difficulty of distinguishing between stupidity and malice, this goal 168 is principally aspirational.) 170 3. Concepts 172 To achieve our goals, we introduce the following new concepts: 174 3.1. Proxy 175 In this document a "proxy" is any TURN server that was provided by 176 any mechanism other than through the standard WebRTC-application ICE 177 candidate provisioning API [I-D.ietf-rtcweb-jsep]. If a proxy is to 178 be used, it will be the destination of traffic generated by the 179 client. There is no analogue to the transparent/intercepting HTTP 180 proxy configuration, which modifies traffic at the network layer. 181 Mechanisms to configure a proxy include Auto-Discovery 182 [I-D.ietf-tram-turn-server-discovery] and local policy 183 ([I-D.ietf-rtcweb-jsep], "ICE candidate policy"). 185 In an application context, a proxy may be "active" (producing 186 candidates) or "inactive" (not in use, having no effect on the 187 context). 189 3.2. Virtual interface 191 A typical WebRTC browser endpoint may have multiple network 192 interfaces available, such as wired ethernet, wireless ethernet, and 193 WAN. In this document, a "virtual interface" is a procedure for 194 generating ICE candidates that are not simply generated by a 195 particular physical interface. A virtual interface can produce 196 "host", "server-reflexive", and "relay" candidates, but may be 197 restricted to only some type of candidate (e.g. UDP-only). 199 3.3. Proxy configuration leakiness 201 "Leakiness" is an attribute of a proxy configuration. This document 202 defines two values for the "leakiness" of a proxy configuration: 203 "leaky" and "sealed". Proxy configuration, including leakiness, may 204 be set by local policy ([I-D.ietf-rtcweb-jsep], "ICE candidate 205 policy") or other mechanisms. 207 A leaky configuration adds a proxy and also allows the browser to use 208 routes that transit directly via the endpoint's physical interfaces 209 (not through the proxy). In a leaky configuration, setting a proxy 210 augments the available set of ICE candidates. Multiple leaky- 211 configuration proxies may therefore be active simultaneously. 213 A sealed proxy configuration requires the browser to route all WebRTC 214 traffic through the proxy, eliminating all ICE candidates that do not 215 go through the proxy. Only one sealed proxy may be active at a time. 217 3.4. Sealed proxy rank 219 In some configurations, an endpoint may be subject to multiple sealed 220 proxy settings at the same time. In that case, one of those settings 221 will have highest rank, and it will be the active proxy. In a given 222 application context (e.g. a webpage), there is at most one active 223 sealed proxy. This document does not specify a representation for 224 rank. 226 4. Requirements 228 4.1. ICE candidates produced in the presence of a proxy 230 When a proxy is configured, by Auto-Discovery or a proprietary means, 231 the browser MUST NOT report a "relay" candidate representing the 232 proxy. Instead, for each active proxy, the browser MUST connect to 233 the proxy and then, if the connection is successful, treat the TURN 234 tunnel as a UDP-only virtual interface. 236 For a virtual interface representing a TURN proxy, this means that 237 the browser MUST report the public-facing IP address and port 238 acquired through TURN as a "host" candidate, the browser MUST perform 239 STUN through the TURN proxy (if STUN is configured), and it MUST 240 perform TURN by recursive encapsulation through the TURN proxy, 241 resulting in TURN candidates whose "raddr" and "rport" attributes 242 match the acquired public-facing IP address and port on the proxy. 244 Because the virtual interface has some additional overhead due to 245 indirection, it SHOULD have lower priority than the physical 246 interfaces if physical interfaces are also active. Specifically, 247 even host candidates generated by a virtual interface SHOULD have 248 priority 0 when physical interfaces are active (similar to [RFC5245] 249 Section 4.1.2.2, "the local preference for host candidates from a VPN 250 interface SHOULD have a priority of 0"). 252 4.2. Leaky proxy configuration 254 If the active proxy for an application is leaky, the browser should 255 undertake the standard ICE candidate discovery mechanism [RFC5245] on 256 the available physical and virtual interfaces. 258 4.3. Sealed proxy configuration 260 If the active proxy for an application is sealed, the browser MUST 261 NOT gather or produce any candidates on physical interfaces. The 262 WebRTC implementation MUST direct its traffic from those interfaces 263 only to the proxy, and perform ICE candidate discovery only on the 264 single virtual interface representing the proxy. 266 4.4. Proxy rank 268 Any browser mechanism for specifying a proxy SHOULD allow the caller 269 to indicate a higher rank than the proxy provided by Auto-Discovery 270 [I-D.ietf-tram-turn-server-discovery]. 272 4.5. Multiple physical interfaces 274 Some operating systems allow the browser to use multiple interfaces 275 to contact a single remote IP address. To avoid producing an 276 excessive number of candidates, WebRTC endpoints MUST NOT use 277 multiple physical interfaces to connect to a single proxy 278 simultaneously. (If this were violated, it could produce a number of 279 virtual interfaces equal to the product of the number of physical 280 interfaces and the number of active proxies.) 282 For strategies to choose the best interface for communication with a 283 proxy, see [I-D.reddy-mmusic-ice-best-interface-pcp]. Similar 284 considerations apply when connecting to an application-specified TURN 285 server in the presence of physical and virtual interfaces. 287 4.6. Unspecified leakiness 289 If a proxy configuration mechanism does not specify leakiness, 290 browsers SHOULD treat the proxy as leaky. This is similar to current 291 WebRTC implementations' behavior in the presence of SOCKS and HTTP 292 proxies: the candidate allocation code continues to generate UDP 293 candidates that do not transit through the proxy. 295 4.7. Interaction with SOCKS5-UDP 297 The SOCKS5 proxy standard [RFC1928] permits compliant SOCKS proxies 298 to support UDP traffic. However, most implementations of SOCKS5 299 today do not support UDP. Accordingly, WebRTC browsers MUST by 300 default (i.e. unless deliberately configured otherwise) treat SOCKS5 301 proxies as leaky and having lower rank than any configured TURN 302 proxies. 304 5. Examples 306 5.1. Firewalled enterprise network with a basic application 308 In this example, an enterprise network is configured with a firewall 309 that blocks all UDP traffic, and a TURN server is advertised for 310 Auto-Discovery in accordance with 311 [I-D.ietf-tram-turn-server-discovery]. The proxy leakiness of the 312 TURN server is unspecified, so the browser treats it as leaky. 314 The application specifies a STUN and TURN server on the public net. 315 In accordance with the ICE candidate gathering algorithm RFC 5245 316 [RFC5245], it receives a set of candidates like: 318 1. A host candidate acquired from one interface. 320 * e.g. candidate:1610808681 1 udp 2122194687 [internal ip addr 321 for interface 0] 63555 typ host generation 0 323 2. A host candidate acquired from a different interface. 325 * e.g. candidate:1610808681 1 udp 2122194687 [internal ip addr 326 for interface 1] 54253 typ host generation 0 328 3. The proxy, as a host candidate. 330 * e.g. candidate:3458234523 1 udp 24584191 [public ip addr for 331 the proxy] 54606 typ host generation 0 333 4. The virtual interface also generates a STUN candidate, but it is 334 eliminated because it is redundant with the host candidate, as 335 noted in [RFC5245] Sec 4.1.2.. 337 5. The application-provided TURN server as seen through the virtual 338 interface. (Traffic through this candidate is recursively 339 encapsulated.) 341 * e.g. candidate:702786350 1 udp 24583935 [public ip addr of the 342 application TURN server] 52631 typ relay raddr [public ip addr 343 for the proxy] rport 54606 generation 0 345 There are no STUN or TURN candidates on the physical interfaces, 346 because the application-specified STUN and TURN servers are not 347 reachable through the firewall. 349 If the remote peer is within the same network, it may be possible to 350 establish a direct connection using both peers' host candidates. If 351 the network prevents this kind of direct connection, the path will 352 instead take a "hairpin" route through the enterprise's proxy, using 353 one peer's physical "host" candidate and the other's virtual "host" 354 candidate, or (if that is also disallowed by the network 355 configuration) a "double hairpin" using both endpoints' virtual 356 "host" candidates. 358 5.2. Conflicting proxies configured by Auto-Discovery and local policy 360 Consider an enterprise network with TURN and HTTP proxies advertised 361 for Auto-Discovery with unspecified leakiness (thus defaulting to 362 leaky). The browser endpoint configures an additional TURN proxy by 363 a proprietary local mechanism. 365 If the locally configured proxy is leaky, then the browser MUST 366 produce candidates representing any physical interfaces (including 367 SSLTCP routes through the HTTP proxy), plus candidates for both UDP- 368 only virtual interfaces created by the two TURN servers. 370 There MUST NOT be any candidate that uses both proxies. Multiple 371 configured proxies are not chained recursively. 373 If the locally configured proxy is "sealed", then the browser MUST 374 produce only candidates from the virtual interface associated with 375 that proxy. 377 If both proxies are configured for "sealed" use, then the browser 378 MUST produce only candidates from the virtual interface associated 379 with the proxy with higher rank. 381 6. Security Considerations 383 This document describes web browser behaviors that, if implemented 384 correctly, allow users to achieve greater identity-confidentiality 385 during WebRTC calls under certain configurations. 387 If a site administrator offers the site's users a TURN proxy, 388 websites running in the users' browsers will be able to initiate a 389 UDP-based WebRTC connection to any UDP transport address via the 390 proxy. Websites' connections will quickly terminate if the remote 391 endpoint does not reply with a positive indication of ICE consent, 392 but no such restriction applies to other applications that access the 393 TURN server. Administrators should take care to provide TURN access 394 credentials only to the users who are authorized to have global UDP 395 network access. 397 7. IANA Considerations 399 This document requires no actions from IANA. 401 8. Acknowledgements 403 Significant review, including the virtual-interface formulation, was 404 provided by Justin Uberti. 406 9. References 408 9.1. Normative References 410 [I-D.ietf-rtcweb-jsep] 411 Uberti, J. and C. Jennings, "Javascript Session 412 Establishment Protocol", draft-ietf-rtcweb-jsep-06 (work 413 in progress), February 2014. 415 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 416 L. Jones, "SOCKS Protocol Version 5", RFC 5766, March 417 1996. 419 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 420 (ICE): A Protocol for Network Address Translator (NAT) 421 Traversal for Offer/Answer Protocols", RFC 5245, April 422 2010. 424 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 425 Relays around NAT (TURN): Relay Extensions to Session 426 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 428 9.2. Informative References 430 [I-D.ietf-rtcweb-use-cases-and-requirements] 431 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 432 Time Communication Use-cases and Requirements", ietf- 433 rtcweb-use-cases-and-requirements-14 (work in progress), 434 February 2014. 436 [I-D.ietf-tram-turn-server-discovery] 437 Patil, P., Reddy, T., and D. Wing, "TURN Server Auto 438 Discovery", draft-ietf-tram-turn-server-discovery-00 (work 439 in progress), July 2014. 441 [I-D.reddy-mmusic-ice-best-interface-pcp] 442 Reddy, T., Wing, D., VerSteeg, B., Penno, R., and V. 443 Singh, "Improving ICE Interface Selection Using Port 444 Control Protocol (PCP) Flow Extension", draft-ietf-tram- 445 turn-server-discovery-00 (work in progress), October 2013. 447 Author's Address 449 Benjamin M. Schwartz 450 Google 451 747 6th Ave S 452 Kirkland, WA 98033 453 USA 455 Email: bemasc@webrtc.org