idnits 2.17.1 draft-ietf-rtcweb-return-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 : ---------------------------------------------------------------------------- ** 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 361: '...nt F20, a WebRTC browser endpoint MUST...' RFC 2119 keyword, line 365: '... It MUST be possible to configure a ...' RFC 2119 keyword, line 369: '...k administrators SHOULD be able to pre...' RFC 2119 keyword, line 467: '... the browser MUST NOT report a "rela...' RFC 2119 keyword, line 468: '...ead, the browser MUST connect to the p...' (33 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 26, 2016) is 3006 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) ** Obsolete normative reference: RFC 6156 (Obsoleted by RFC 8656) ** Obsolete normative reference: RFC 6555 (Obsoleted by RFC 8305) == 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: 6 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 J. Uberti 4 Intended status: Standards Track Google 5 Expires: July 29, 2016 January 26, 2016 7 Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in 8 WebRTC 9 draft-ietf-rtcweb-return-01 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 July 29, 2016. 36 Copyright Notice 38 Copyright (c) 2016 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. Visual Overview of RETURN . . . . . . . . . . . . . . . . . . 4 55 3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 3.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . 8 57 3.2. Independent Path Control . . . . . . . . . . . . . . . . 9 58 4. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 4.1. Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 4.2. Virtual interface . . . . . . . . . . . . . . . . . . . . 10 61 4.3. Proxy configuration leakiness . . . . . . . . . . . . . . 10 62 4.4. Sealed proxy rank . . . . . . . . . . . . . . . . . . . . 10 63 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11 64 5.1. ICE candidates produced in the presence of a proxy . . . 11 65 5.2. Leaky proxy configuration . . . . . . . . . . . . . . . . 11 66 5.3. Sealed proxy configuration . . . . . . . . . . . . . . . 11 67 5.4. Proxy rank . . . . . . . . . . . . . . . . . . . . . . . 11 68 5.5. Multiple physical interfaces . . . . . . . . . . . . . . 12 69 5.6. IPv4 and IPv6 . . . . . . . . . . . . . . . . . . . . . . 12 70 5.7. Unspecified leakiness . . . . . . . . . . . . . . . . . . 12 71 5.8. Interaction with SOCKS5-UDP . . . . . . . . . . . . . . . 12 72 5.9. Encapsulation overhead, fragmentation, and Path MTU . . . 13 73 5.10. Interaction with alternate TURN server fallback . . . . . 13 74 5.11. Reusing the same TURN server . . . . . . . . . . . . . . 13 75 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 6.1. Firewalled enterprise network with a basic application . 14 77 6.2. Conflicting proxies configured by Auto-Discovery and 78 local policy . . . . . . . . . . . . . . . . . 15 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 84 10.2. Informative References . . . . . . . . . . . . . . . . . 17 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 87 1. Introduction 89 TURN [RFC5766] is a protocol for communication between a client and a 90 TURN server, in order to route UDP traffic to and from one or more 91 peers. As noted in [RFC5766], the TURN relay server "typically sits 92 in the public Internet". In a WebRTC context, if a TURN server is to 93 be used, it is typically provided by the application, either to 94 provide connectivity between users whose NATs would otherwise prevent 95 it, or to obscure the identity of the participants by concealing 96 their IP addresses from one another. 98 In many enterprises, direct UDP transmissions are not permitted 99 between clients on the internal networks and external IP addresses, 100 so media must flow over TCP. To enable WebRTC services in such a 101 situation, clients must use TURN-TCP, or TURN-TLS. These 102 configurations are not ideal: they send all traffic over TCP, which 103 leads to higher latency than would otherwise be necessary, and they 104 force the application provider to operate a TURN server because 105 WebRTC endpoints behind NAT cannot typically act as TCP servers. 106 These configurations may result in especially bad behaviors when 107 operating through TCP or HTTP proxies that were not designed to carry 108 real-time media streams. 110 To avoid forcing WebRTC media streams through a TCP stage, enterprise 111 network operators may operate a TURN server for their network, which 112 can be discovered by clients using TURN Auto-Discovery 113 [I-D.ietf-tram-turn-server-discovery], or through a proprietary 114 mechanism. This TURN server may be placed inside the network, with a 115 firewall configuration allowing it to communicate with the public 116 internet, or it may be operated by a third party outside the network, 117 with a firewall configuration that allows hosts inside the network to 118 communicate with it. Use of the specified TURN server may be the 119 only way for clients on the network to achieve a high quality WebRTC 120 experience. This scenario is required to be supported by the WebRTC 121 requirements document [I-D.ietf-rtcweb-use-cases-and-requirements] 122 Section 3.3.5.1. 124 When the application intends to use a TURN server for identity 125 cloaking, and the enterprise network administrator intends to use a 126 TURN server for connectivity, there is a conflict. In current WebRTC 127 implementations, TURN can only be used on a single-hop basis in each 128 candidate, but using only the enterprise's TURN server reveals 129 information about the user (e.g. organizational affiliation), and 130 using only the application's TURN server may be blocked by the 131 network administrator, or may require using TURN-TCP or TURN-TLS, 132 resulting in a significant sacrifice in latency. 134 To resolve this conflict, we introduce Recursively Encapsulated TURN, 135 a procedure that allows a WebRTC endpoint to route traffic through 136 multiple TURN servers, and get improved connectivity and privacy in 137 return. 139 2. Visual Overview of RETURN 141 ____________ inside network || outside network 142 / \ || NAT/FW 143 | host O ________||________ 144 | | / || \ 145 | srflx|.............|..................O ___________ 146 | | | || | / \ 147 | relay|- - - - - - -|- - - - - - - - - |- - -|- - - - - -O 148 | | | || | | | 149 | | | || | | | 150 | | | || | | | 151 | | | || | | | 152 | | | || | \___________/ 153 | | | || | 154 | | | || | Application TURN 155 | | | || | server in cloud 156 \____________/ \________||________/ 157 || 158 Browser || 159 || 160 KEY O Candidate 161 ..... Non encapsulated 162 - - - TURN encapsulated 163 || Network edge 165 Figure 1: Basic WebRTC ICE Candidates with TURN Server 167 Figure 1 shows a browser located inside a home or enterprise network 168 which connects to the Internet through a Network Address Translator 169 and Firewall (NAT/FW). A TURN server in the Internet cloud is also 170 shown, which is provided by the WebRTC application via the JavaScript 171 IceServers object. 173 A WebRTC application can use a TURN server to provide NAT traversal, 174 but also to provide privacy, routing optimizations, logging, or 175 possibly other functionality. The application can accomplish this by 176 forcing all traffic to flow through the TURN server using the 177 JavaScript RTCIceTransportPolicy object [I-D.ietf-rtcweb-jsep]. 178 Since this TURN server is injected by the application, we will refer 179 to it as an Application TURN server. 181 ____________ inside network || outside network 182 / \ || NAT/FW 183 | host O ________||________ 184 | | / || \ 185 | srflx|.............|..................O 186 | | | || | 187 | | | || | 188 | | | _____||_____ | 189 | | | / || \ | 190 | (border)|- - - - - - -| -|- - - - - - O | 191 | | | | || | | 192 | | | | || | | 193 | | | | || | | 194 | | | | || | | 195 | | | \_____||_____/ | 196 \____________/ \________||________/ 197 || 198 Browser Border TURN || 199 server in DMZ || 200 KEY O Candidate 201 ..... Non encapsulated 202 - - - TURN encapsulated 203 || Network edge 205 Figure 2: WebRTC ICE Candidates with DMZ TURN Server 207 Figure 2 shows a TURN server co-resident with the NAT/FW, i.e. in the 208 DMZ of the FW. This TURN server might be used by an enterprise, ISP, 209 or home network to enable WebRTC media flows that would otherwise be 210 blocked by the firewall, or to improve quality of service on flows 211 that pass through this TURN server. This TURN server is not part of 212 a particular application, and is managed as part of the border 213 control system, so we call it a Border TURN Server. 215 Figure 2 shows the port allocated on this TURN server as "(border)", 216 not any particular candidate type, to distinguish it from the other 217 ports, which have been represented as ICE candidates in accordance 218 with the WebRTC specifications. This case is different, because 219 unlike an Application TURN server, there is not yet any specification 220 for how WebRTC should interact with a Border TURN server. Under what 221 conditions should WebRTC allocate a port on a Border TURN server? 222 How should WebRTC represent that port as an ICE candidate? This 223 draft serves to answer these two questions. 225 inside network || outside network 226 ____________ || NAT/FW 227 / \ ________||________ 228 | | / || \ 229 | | | || | 230 | host O.............X || | 231 | | | || | 232 | srflx|.............X..................O ___________ 233 | | | || | / \ 234 | relay|- - - - - - -X- - - - - - - - - |- - -|- - - - - -O 235 | | | _____||_____ | | | 236 | | | / || \ | | | 237 | (border)|- - - - - - -|- |- - - - - - O | | | 238 | | | | || | | \___________/ 239 | | | | || | | 240 | | | | || | | Application TURN 241 | | | | || | | server 242 | | | \_____||_____/ | 243 \____________/ \________||________/ 244 || 245 Browser Border TURN || 246 server || 247 KEY O Candidate 248 ..... Non encapsulated 249 - - - TURN encapsulated 250 || Network edge 251 X Firewall block 253 Figure 3: WebRTC ICE Candidates with Application and Border TURN 254 Servers 256 In Figure 3, there is both an Application TURN server and a Border 257 TURN server. The Firewall is blocking UDP traffic except for UDP 258 traffic to/from the Border TURN server, so only the "(border)" port 259 allocation will work. However, there is no specified way for WebRTC 260 to use this port as a candidate. Moreover, this port on its own 261 would not be sufficient to satisfy the user's needs. Both TURN 262 servers provide important functionality, so we need a way for WebRTC 263 to select a candidate that uses both TURN servers. 265 The solution proposed in this draft is for the browser to implement 266 RETURN, which provides a candidate that traverses both TURN servers, 267 as shown in Figure 4. 269 ____________ inside network || outside network 270 / \ || NAT/FW 271 | host O ________||________ 272 | | / || \ 273 | srflx|.............|..................O ___________ 274 | | | || | / \ 275 | relay|- - - - - - -|- - - - - - - - - |- - -|- - - - - -O 276 | | | _____||_____ | | | 277 | | | / || \ | | | 278 | relay2|-------------|--|------------| -|- - -|- - - - - -O 279 | | | | || | | \___________/ 280 | srflx2|- - - - - - -|- |- - - - - - O | 281 | | | | || | | Application TURN 282 | host2 |- - - - - - -|- |- - - - - - O | server 283 | | | \_____||_____/ | 284 \____________/ \________||________/ 285 || 286 Browser Border TURN Proxy || 287 server || 288 KEY O Candidate 289 ..... Non encapsulated 290 - - - TURN encapsulated 291 ----- Double TURN encapsulated 292 || Network edge 294 Figure 4: WebRTC ICE Candidates with Application TURN and Border TURN 295 Proxy Servers 297 The Browser in Figure 4 implements RETURN, so it allocates a port on 298 the Border TURN server, now referred to as a Border TURN Proxy by 299 analogy to an HTTP CONNECT or SOCKS Proxy (see Figure 5), and then 300 runs STUN and TURN over this allocation, resulting in three 301 candidates: relay2, srflx2, and host2. The relay2 candidate causes 302 traffic to flow through both TURN servers by encapsulating TURN 303 within TURN - hence the name Recursively Encapsulated TURN (RETURN). 305 The host2 and srflx2 candidates are probably identical, so one will 306 be dropped by ICE. If the NAT/FW blocks UDP and the application uses 307 only relay candidates, then the relay2 candidate will be selected. 308 Otherwise, the other candidates will be used, in accordance with the 309 usual ICE procedure. 311 Only the browser needs to implement the RETURN behavior - both the 312 Border TURN Proxy and Application TURN servers' TURN protocol usage 313 is unchanged. 315 Note that this arrangement preserves the end-to-end security and 316 privacy features of WebRTC media flows. The ability to steer the 317 media flows through multiple TURN servers while still allowing 318 end-to-end encryption and authentication is a key benefit of 319 RETURN. 321 ____________ inside network || outside network 322 / \ || NAT/FW 323 | | ________||________ 324 | | / _____||_____ \ 325 | | | / || \ | 326 | | | | || | | 327 | | | | || | | 328 | Web Traffic|=============|==|============H | 329 | | | | || | | 330 | | HTTP/ | | || | | 331 | | HTTPS | \_____||_____/ | 332 | | Proxy | || | 333 | | | _____||_____ | 334 | | | / || \ | 335 | | | | || | | 336 | | | | || | | 337 |WebRTC Media|- - - - - - -|- |- - - - - - O | 338 | | | | || | | 339 | | | | || | | 340 | | TURN | \_____||_____/ | 341 \____________/ Proxy \________||________/ 342 || 343 Browser || 344 || 345 KEY O TURN Proxy Candidate 346 H HTTP/HTTPS Proxy Address 347 - - - TURN encapsulated 348 ===== HTTP/HTTPS web traffic 349 || Network edge 351 Figure 5: Similarity between HTTP/HTTPS Proxy and TURN Proxy 353 3. Goals 355 These goals are requirements on this document (not on implementations 356 of the specification). 358 3.1. Connectivity 360 As noted in [I-D.ietf-rtcweb-use-cases-and-requirements] 361 Section 3.3.5.1 and requirement F20, a WebRTC browser endpoint MUST 362 be able to direct UDP connections through a designated TURN server 363 configured by enterprise policy (a "proxy"). 365 It MUST be possible to configure a WebRTC endpoint that supports 366 proxies to achieve connectivity no worse than if the endpoint were 367 operating at the proxy's address. 369 For efficiency, network administrators SHOULD be able to prevent 370 browsers from attempting to send traffic through routes that are 371 already known to be blocked. 373 3.2. Independent Path Control 375 Both network administrators and application developers may wish to 376 direct all their UDP flows through a particular TURN server. There 377 are many goals that might motivate such a choice, including 379 o improving quality of service by tunneling packets through a 380 network that is faster than the public internet, 382 o monitoring the usage of UDP services, 384 o troubleshooting and debugging problematic services, 386 o logging connection metadata for legal or auditing reasons, 388 o recording the entire contents of all connections, or 390 o providing partial IP address anonymization (as described in 391 [I-D.ietf-rtcweb-security] Section 4.2.4). 393 4. Concepts 395 To achieve our goals, we introduce the following new concepts: 397 4.1. Proxy 399 In this document a "proxy" is any TURN server that was provided by 400 any mechanism other than through the standard WebRTC-application ICE 401 candidate provisioning API [I-D.ietf-rtcweb-jsep]. We call it a 402 "proxy" by analogy with SOCKS proxies and similar network services, 403 because it performs a similar function and can be configured in a 404 similar fashion. 406 If a proxy is to be used, it will be the destination of traffic 407 generated by the client. (There is no analogue to the transparent/ 408 intercepting HTTP proxy configuration, which modifies traffic at the 409 network layer.) Mechanisms to configure a proxy include Auto- 410 Discovery [I-D.ietf-tram-turn-server-discovery] and local policy 411 ([I-D.ietf-rtcweb-jsep], "ICE candidate policy"). 413 In an application context, a proxy may be "active" (producing 414 candidates) or "inactive" (not in use, having no effect on the 415 context). 417 4.2. Virtual interface 419 A typical WebRTC browser endpoint may have multiple network 420 interfaces available, such as wired ethernet, wireless ethernet, and 421 WAN. In this document, a "virtual interface" is a procedure for 422 generating ICE candidates that are not simply generated by a 423 particular physical interface. A virtual interface can produce 424 "host", "server-reflexive", and "relay" candidates, but may be 425 restricted to only some type of candidate (e.g. UDP-only). 427 4.3. Proxy configuration leakiness 429 "Leakiness" is an attribute of a proxy configuration. This document 430 defines two values for the "leakiness" of a proxy configuration: 431 "leaky" and "sealed". Proxy configuration, including leakiness, may 432 be set by local policy ([I-D.ietf-rtcweb-jsep], "ICE candidate 433 policy") or other mechanisms. 435 A leaky configuration adds a proxy and also allows the browser to use 436 routes that transit directly via the endpoint's physical interfaces 437 (not through the proxy). In a leaky configuration, setting a proxy 438 augments the available set of ICE candidates. Multiple leaky- 439 configuration proxies may therefore be active simultaneously. 441 A sealed proxy configuration requires the browser to route all WebRTC 442 traffic through the proxy, eliminating all ICE candidates that do not 443 go through the proxy. Only one sealed proxy may be active at a time. 445 Leaky proxy configurations allow more efficient routes to be 446 selected. For example, two peers on the same LAN can connect 447 directly (peer to peer) if a leaky proxy is enabled, but must 448 "hairpin" through the TURN proxy if the configuration is sealed. 449 However, sealed proxy configurations can be faster to connect, 450 especially if many of the peer-to-peer routes that ICE will try first 451 are blocked by the network's firewall policies. 453 4.4. Sealed proxy rank 455 In some configurations, an endpoint may be subject to multiple sealed 456 proxy settings at the same time. In that case, one of those settings 457 will have highest rank, and it will be the active proxy. In a given 458 application context (e.g. a webpage), there is at most one active 459 sealed proxy. This document does not specify a representation for 460 rank. 462 5. Requirements 464 5.1. ICE candidates produced in the presence of a proxy 466 When a proxy is configured, by Auto-Discovery or a proprietary means, 467 the browser MUST NOT report a "relay" candidate representing the 468 proxy. Instead, the browser MUST connect to the proxy and then, if 469 the connection is successful, treat the TURN tunnel as a UDP-only 470 virtual interface. 472 For a virtual interface representing a TURN proxy, this means that 473 the browser MUST report the public-facing IP address and port 474 acquired through TURN as a "host" candidate, the browser MUST perform 475 STUN through the TURN proxy (if STUN is configured), and it MUST 476 perform TURN by recursive encapsulation through the TURN proxy, 477 resulting in TURN candidates whose "raddr" and "rport" attributes 478 match the acquired public-facing IP address and port on the proxy. 480 Because the virtual interface has some additional overhead due to 481 indirection, it SHOULD have lower priority than the physical 482 interfaces if physical interfaces are also active. Specifically, 483 even host candidates generated by a virtual interface SHOULD have 484 priority 0 when physical interfaces are active (similar to [RFC5245] 485 Section 4.1.2.2, "the local preference for host candidates from a VPN 486 interface SHOULD have a priority of 0"). 488 5.2. Leaky proxy configuration 490 If the active proxy for an application is leaky, the browser should 491 undertake the standard ICE candidate discovery mechanism [RFC5245] on 492 the available physical and virtual interfaces. 494 5.3. Sealed proxy configuration 496 If the active proxy for an application is sealed, the browser MUST 497 NOT gather or produce any candidates on physical interfaces. The 498 WebRTC implementation MUST direct its traffic from those interfaces 499 only to the proxy, and perform ICE candidate discovery only on the 500 single virtual interface representing the active proxy. 502 5.4. Proxy rank 504 Any browser mechanism for specifying a proxy SHOULD allow the caller 505 to indicate a higher rank than the proxy provided by Auto-Discovery 506 [I-D.ietf-tram-turn-server-discovery]. 508 5.5. Multiple physical interfaces 510 Some operating systems allow the browser to use multiple interfaces 511 to contact a single remote IP address. To avoid producing an 512 excessive number of candidates, WebRTC endpoints MUST NOT use 513 multiple physical interfaces to connect to a single proxy 514 simultaneously. (If this were violated, it could produce a number of 515 virtual interfaces equal to the product of the number of physical 516 interfaces and the number of active proxies.) 518 For strategies to choose the best interface for communication with a 519 proxy, see [I-D.reddy-mmusic-ice-best-interface-pcp]. Similar 520 considerations apply when connecting to an application-specified TURN 521 server in the presence of physical and virtual interfaces. 523 5.6. IPv4 and IPv6 525 A proxy MAY have both an IPv4 and an IPv6 address (e.g. if the proxy 526 is specified by DNS and has both A and AAAA records). The client MAY 527 try both of these addresses, but MUST select one, preferring IPv6, 528 before allocating any remote addresses. This corresponds to the the 529 Happy Eyeballs [RFC6555] procedure for dual-stack clients. 531 A proxy MAY provide both IPv4 and IPv6 remote addresses to clients 532 [RFC6156]. A client SHOULD request both address families. If both 533 requests are granted, the client SHOULD treat the two addresses as 534 host candidates on a dual-stack virtual interface. 536 5.7. Unspecified leakiness 538 If a proxy configuration mechanism does not specify leakiness, 539 browsers SHOULD treat the proxy as leaky. This is similar to current 540 WebRTC implementations' behavior in the presence of SOCKS and HTTP 541 proxies: the candidate allocation code continues to generate UDP 542 candidates that do not transit through the proxy. 544 5.8. Interaction with SOCKS5-UDP 546 The SOCKS5 proxy standard [RFC1928] permits compliant SOCKS proxies 547 to support UDP traffic. However, most implementations of SOCKS5 548 today do not support UDP. Accordingly, WebRTC browsers MUST by 549 default (i.e. unless deliberately configured otherwise) treat SOCKS5 550 proxies as leaky and having lower rank than any configured TURN 551 proxies. 553 5.9. Encapsulation overhead, fragmentation, and Path MTU 555 Encapsulating a link in TURN adds overhead on the path between the 556 client and the TURN server, because each packet must be wrapped in a 557 TURN message. This overhead is sometimes doubled in RETURN proxying. 558 To avoid excessive overhead, client implementations SHOULD use 559 ChannelBind and ChannelData messages to connect and send data through 560 proxies and application TURN servers when possible. Clients MAY 561 buffer messages to be sent until the ChannelBind command completes 562 (requiring one round trip to the proxy), or they MAY use 563 CreatePermission and Send messages for the first few packets to 564 reduce startup latency at the cost of higher overhead. 566 Adding overhead to packets on a link decreases the effective Maximum 567 Transmissible Unit on that link. Accordingly, clients that support 568 proxying MUST NOT rely on the effective MTU complying with the 569 Internet Protocol's minimum MTU requirement. 571 ChannelData messages have constant overheard, enabling consistent 572 effective PMTU, but Send messages do not necessarily have constant 573 overhead. TURN messages may be fragmented and reassembled if they 574 are not marked with the Don't Fragment (DF) IP bit or the DONT- 575 FRAGMENT TURN attribute. Client implementors should keep this in 576 mind, especially if they choose to implement PMTU discovery through 577 the proxy. 579 5.10. Interaction with alternate TURN server fallback 581 As per [RFC5766], a TURN server MAY respond to an Allocate request 582 with an error code of 300 and an ALTERNATE-SERVER indication. When 583 connecting to proxies or application TURN servers, clients SHOULD 584 attempt to connect to the specified alternate server in accordance 585 with [RFC5766]. The client MUST route a connection to the alternate 586 server through the proxy if and only if the original connection 587 attempt was routed through the proxy. 589 5.11. Reusing the same TURN server 591 It is possible that the same TURN server may appear more than once in 592 the network path. For example, if both endpoints configure the same 593 sealed proxy, then each peer will only provide candidates on this 594 proxy. This is not a problem, and will work as expected. 596 It is also possible that the same TURN server could be used by both 597 the enterprise and the application. It might appear attractive to 598 connect to this server only once, rathering connecting to it through 599 itself, in order to avoid imposing unnecessary server load. However, 600 a RETURN client MUST connect to the server twice, even when this 601 appears redundant, to ensure correct session attribution. 603 For example, consider a TURN service operator that issues different 604 authentication credentials to different customers, and then allows 605 each customer to observe the source and destination IP addresses used 606 with their credentials. Suppose the application and enterprise both 607 have accounts on this service: the application uses it to prevent the 608 enterprise from learning its peers' IP addresses, and the enterprise 609 uses it to prevent the application from learning its employees' IP 610 addresses. If the client only connects to the service once, then 611 either the enterprise or the application will learn IP address 612 information (via the TURN provider's metadata reporting) that was 613 meant to be kept secret. 615 As a result of this requirement, it is possible for the same TURN 616 server to appear up to four times in a RETURN network path: once as 617 each peer's application's TURN server, and once as each peer's sealed 618 proxy. 620 6. Examples 622 6.1. Firewalled enterprise network with a basic application 624 In this example, an enterprise network is configured with a firewall 625 that blocks all UDP traffic, and a TURN server is advertised for 626 Auto-Discovery in accordance with 627 [I-D.ietf-tram-turn-server-discovery]. The proxy leakiness of the 628 TURN server is unspecified, so the browser treats it as leaky. 630 The application specifies a STUN and TURN server on the public net. 631 In accordance with the ICE candidate gathering algorithm RFC 5245 632 [RFC5245], it receives a set of candidates like: 634 1. A host candidate acquired from one interface. 636 * e.g. candidate:1610808681 1 udp 2122194687 [internal ip addr 637 for interface 0] 63555 typ host generation 0 639 2. A host candidate acquired from a different interface. 641 * e.g. candidate:1610808681 1 udp 2122194687 [internal ip addr 642 for interface 1] 54253 typ host generation 0 644 3. The proxy, as a host candidate. 646 * e.g. candidate:3458234523 1 udp 24584191 [public ip addr for 647 the proxy] 54606 typ host generation 0 649 4. The virtual interface also generates a STUN candidate, but it is 650 eliminated because it is redundant with the host candidate, as 651 noted in [RFC5245] Sec 4.1.2.. 653 5. The application-provided TURN server as seen through the virtual 654 interface. (Traffic through this candidate is recursively 655 encapsulated.) 657 * e.g. candidate:702786350 1 udp 24583935 [public ip addr of the 658 application TURN server] 52631 typ relay raddr [public ip addr 659 for the proxy] rport 54606 generation 0 661 There are no STUN or TURN candidates on the physical interfaces, 662 because the application-specified STUN and TURN servers are not 663 reachable through the firewall. 665 If the remote peer is within the same network, it may be possible to 666 establish a direct connection using both peers' host candidates. If 667 the network prevents this kind of direct connection, the path will 668 instead take a "hairpin" route through the enterprise's proxy, using 669 one peer's physical "host" candidate and the other's virtual "host" 670 candidate, or (if that is also disallowed by the network 671 configuration) a "double hairpin" using both endpoints' virtual 672 "host" candidates. 674 6.2. Conflicting proxies configured by Auto-Discovery and local policy 676 Consider an enterprise network with TURN and HTTP proxies advertised 677 for Auto-Discovery with unspecified leakiness (thus defaulting to 678 leaky). The browser endpoint configures an additional TURN proxy by 679 a proprietary local mechanism. 681 If the locally configured proxy is leaky, then the browser MUST 682 produce candidates representing any physical interfaces (including 683 SSLTCP routes through the HTTP proxy), plus candidates for both UDP- 684 only virtual interfaces created by the two TURN servers. 686 There MUST NOT be any candidate that uses both proxies. Multiple 687 configured proxies are not chained recursively. 689 If the locally configured proxy is "sealed", then the browser MUST 690 produce only candidates from the virtual interface associated with 691 that proxy. 693 If both proxies are configured for "sealed" use, then the browser 694 MUST produce only candidates from the virtual interface associated 695 with the proxy with higher rank. 697 7. Security Considerations 699 A RETURN proxy can capture, block, and otherwise interfere with all 700 of its clients' WebRTC network activity. Therefore, browsers and 701 other WebRTC endpoints MUST NOT use RETURN proxies that are provided 702 by untrusted sources. For example, endpoints MUST NOT implement a 703 configuration based on unauthenticated network multicast (e.g. mDNS) 704 unless the endpoint will only be used on networks where all other 705 users are fully trusted to intercept all WebRTC traffic. In 706 contrast, endpoints MAY implement mechanisms to configure RETURN 707 proxies by system-wide policy, which can only be modified by trusted 708 system administrators. 710 This document describes web browser behaviors that, if implemented 711 correctly, allow users to achieve greater identity-confidentiality 712 during WebRTC calls under certain configurations. 714 If a site administrator offers the site's users a TURN proxy, 715 websites running in the users' browsers will be able to initiate a 716 UDP-based WebRTC connection to any UDP transport address via the 717 proxy. Websites' connections will quickly terminate if the remote 718 endpoint does not reply with a positive indication of ICE consent, 719 but no such restriction applies to other applications that access the 720 TURN server. Administrators should take care to provide TURN access 721 credentials only to the users who are authorized to have global UDP 722 network access. 724 TURN proxies and application TURN servers can provide some privacy 725 protection by obscuring the identity of one peer from the other. 726 However, unencrypted TURN provides no additional privacy from an 727 observer who can monitor the link between the TURN client and server, 728 and even encrypted TURN ([I-D.ietf-tram-stun-dtls] Section 4.6) does 729 not provide significant privacy from an observer who sniff traffic on 730 both legs of the TURN connection, due to packet timing correlations. 732 8. IANA Considerations 734 This document requires no actions from IANA. 736 9. Acknowledgements 738 Thanks to Harald Alvestrand, Philipp Hancke, Tirumaleswar Reddy, Alan 739 Johnston, John Yoakum, and Cullen Jennings for suggestions to improve 740 the content and presentation. Special thanks to Alan Johnston for 741 contributing the visual overview in Section 2. 743 10. References 745 10.1. Normative References 747 [I-D.ietf-rtcweb-jsep] 748 Uberti, J. and C. Jennings, "Javascript Session 749 Establishment Protocol", draft-ietf-rtcweb-jsep-06 (work 750 in progress), February 2014. 752 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 753 L. Jones, "SOCKS Protocol Version 5", RFC 5766, March 754 1996. 756 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 757 (ICE): A Protocol for Network Address Translator (NAT) 758 Traversal for Offer/Answer Protocols", RFC 5245, April 759 2010. 761 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 762 Relays around NAT (TURN): Relay Extensions to Session 763 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 765 [RFC6156] Camarillo, G., Novo, O., and S. Perreault, "Traversal 766 Using Relays around NAT (TURN) Extension for IPv6", RFC 767 6156, April 2011. 769 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 770 Dual-Stack Hosts", RFC 6555, April 2012. 772 10.2. Informative References 774 [I-D.ietf-rtcweb-security] 775 Rescorla, E., "Security Considerations for WebRTC", ietf- 776 rtcweb-security-07 (work in progress), July 2014. 778 [I-D.ietf-rtcweb-use-cases-and-requirements] 779 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 780 Time Communication Use-cases and Requirements", ietf- 781 rtcweb-use-cases-and-requirements-14 (work in progress), 782 February 2014. 784 [I-D.ietf-tram-stun-dtls] 785 Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport 786 Layer Security (DTLS) as Transport for Session Traversal 787 Utilities for NAT (STUN)", ietf-rtcweb-use-cases-and- 788 requirements-14 (work in progress), June 2014. 790 [I-D.ietf-tram-turn-server-discovery] 791 Patil, P., Reddy, T., and D. Wing, "TURN Server Auto 792 Discovery", draft-ietf-tram-turn-server-discovery-00 (work 793 in progress), July 2014. 795 [I-D.reddy-mmusic-ice-best-interface-pcp] 796 Reddy, T., Wing, D., VerSteeg, B., Penno, R., and V. 797 Singh, "Improving ICE Interface Selection Using Port 798 Control Protocol (PCP) Flow Extension", draft-ietf-tram- 799 turn-server-discovery-00 (work in progress), October 2013. 801 Authors' Addresses 803 Benjamin M. Schwartz 804 Google, Inc. 805 111 8th Ave 806 New York, NY 10011 807 USA 809 Email: bemasc@webrtc.org 811 Justin Uberti 812 Google, Inc. 813 747 6th Street South 814 Kirkland, WA 98033 815 USA 817 Email: justin@uberti.name