idnits 2.17.1 draft-ietf-rtcweb-return-02.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 359: '...browser endpoint MUST be able to direc...' RFC 2119 keyword, line 362: '... It MUST be possible to configure a ...' RFC 2119 keyword, line 366: '...k administrators SHOULD be able to pre...' RFC 2119 keyword, line 465: '... the browser MUST NOT report a "rela...' RFC 2119 keyword, line 466: '...ead, the browser MUST connect to the p...' (34 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 27, 2017) is 2586 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-19 ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** 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-rtcweb-ip-handling-03 == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-security-08 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-12 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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: September 28, 2017 March 27, 2017 7 Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in 8 WebRTC 9 draft-ietf-rtcweb-return-02 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 September 28, 2017. 36 Copyright Notice 38 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . 3 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 [RFC7478] Section 2.3.5.1. 123 When the application intends to use a TURN server for identity 124 cloaking, and the enterprise network administrator intends to use a 125 TURN server for connectivity, there is a conflict. In current WebRTC 126 implementations, TURN can only be used on a single-hop basis in each 127 candidate, but using only the enterprise's TURN server reveals 128 information about the user (e.g. organizational affiliation), and 129 using only the application's TURN server may be blocked by the 130 network administrator, or may require using TURN-TCP or TURN-TLS, 131 resulting in a significant sacrifice in latency. 133 To resolve this conflict, we introduce Recursively Encapsulated TURN, 134 a procedure that allows a WebRTC endpoint to route traffic through 135 multiple TURN servers, and get improved connectivity and privacy in 136 return. 138 2. Visual Overview of RETURN 139 ____________ inside network || outside network 140 / \ || NAT/FW 141 | host O ________||________ 142 | | / || \ 143 | srflx|.............|..................O ___________ 144 | | | || | / \ 145 | relay|- - - - - - -|- - - - - - - - - |- - -|- - - - - -O 146 | | | || | | | 147 | | | || | | | 148 | | | || | | | 149 | | | || | | | 150 | | | || | \___________/ 151 | | | || | 152 | | | || | Application TURN 153 | | | || | server in cloud 154 \____________/ \________||________/ 155 || 156 Browser || 157 || 158 KEY O Candidate 159 ..... Non encapsulated 160 - - - TURN encapsulated 161 || Network edge 163 Figure 1: Basic WebRTC ICE Candidates with TURN Server 165 Figure 1 shows a browser located inside a home or enterprise network 166 which connects to the Internet through a Network Address Translator 167 and Firewall (NAT/FW). A TURN server in the Internet cloud is also 168 shown, which is provided by the WebRTC application via the JavaScript 169 RTCIceServers object. 171 A WebRTC application can use a TURN server to provide NAT traversal, 172 but also to provide privacy, routing optimizations, logging, or 173 possibly other functionality. The application can accomplish this by 174 forcing all traffic to flow through the TURN server using the 175 JavaScript RTCIceTransportPolicy object [I-D.ietf-rtcweb-jsep]. 176 Since this TURN server is injected by the application, we will refer 177 to it as an Application TURN server. 179 ____________ inside network || outside network 180 / \ || NAT/FW 181 | host O ________||________ 182 | | / || \ 183 | srflx|.............|..................O 184 | | | || | 185 | | | || | 186 | | | _____||_____ | 187 | | | / || \ | 188 | (border)|- - - - - - -| -|- - - - - - O | 189 | | | | || | | 190 | | | | || | | 191 | | | | || | | 192 | | | | || | | 193 | | | \_____||_____/ | 194 \____________/ \________||________/ 195 || 196 Browser Border TURN || 197 server in DMZ || 198 KEY O Candidate 199 ..... Non encapsulated 200 - - - TURN encapsulated 201 || Network edge 203 Figure 2: WebRTC ICE Candidates with DMZ TURN Server 205 Figure 2 shows a TURN server co-resident with the NAT/FW, i.e. in the 206 DMZ of the FW. This TURN server might be used by an enterprise, ISP, 207 or home network to enable WebRTC media flows that would otherwise be 208 blocked by the firewall, or to improve quality of service on flows 209 that pass through this TURN server. This TURN server is not part of 210 a particular application, and is managed as part of the border 211 control system, so we call it a Border TURN Server. 213 Figure 2 shows the port allocated on this TURN server as "(border)", 214 not any particular candidate type, to distinguish it from the other 215 ports, which have been represented as ICE candidates in accordance 216 with the WebRTC specifications. This case is different, because 217 unlike an Application TURN server, there is not yet any specification 218 for how WebRTC should interact with a Border TURN server. Under what 219 conditions should WebRTC allocate a port on a Border TURN server? 220 How should WebRTC represent that port as an ICE candidate? This 221 draft serves to answer these two questions. 223 inside network || outside network 224 ____________ || NAT/FW 225 / \ ________||________ 226 | | / || \ 227 | | | || | 228 | host O.............X || | 229 | | | || | 230 | srflx|.............X..................O ___________ 231 | | | || | / \ 232 | relay|- - - - - - -X- - - - - - - - - |- - -|- - - - - -O 233 | | | _____||_____ | | | 234 | | | / || \ | | | 235 | (border)|- - - - - - -|- |- - - - - - O | | | 236 | | | | || | | \___________/ 237 | | | | || | | 238 | | | | || | | Application TURN 239 | | | | || | | server 240 | | | \_____||_____/ | 241 \____________/ \________||________/ 242 || 243 Browser Border TURN || 244 server || 245 KEY O Candidate 246 ..... Non encapsulated 247 - - - TURN encapsulated 248 || Network edge 249 X Firewall block 251 Figure 3: WebRTC ICE Candidates with Application and Border TURN 252 Servers 254 In Figure 3, there is both an Application TURN server and a Border 255 TURN server. The Firewall is blocking UDP traffic except for UDP 256 traffic to/from the Border TURN server, so only the "(border)" port 257 allocation will work. However, there is no specified way for WebRTC 258 to use this port as a candidate. Moreover, this port on its own 259 would not be sufficient to satisfy the user's needs. Both TURN 260 servers provide important functionality, so we need a way for WebRTC 261 to select a candidate that uses both TURN servers. 263 The solution proposed in this draft is for the browser to implement 264 RETURN, which provides a candidate that traverses both TURN servers, 265 as shown in Figure 4. 267 ____________ inside network || outside network 268 / \ || NAT/FW 269 | host O ________||________ 270 | | / || \ 271 | srflx|.............|..................O ___________ 272 | | | || | / \ 273 | relay|- - - - - - -|- - - - - - - - - |- - -|- - - - - -O 274 | | | _____||_____ | | | 275 | | | / || \ | | | 276 | relay2|-------------|--|------------| -|- - -|- - - - - -O 277 | | | | || | | \___________/ 278 | srflx2|- - - - - - -|- |- - - - - - O | 279 | | | | || | | Application TURN 280 | host2 |- - - - - - -|- |- - - - - - O | server 281 | | | \_____||_____/ | 282 \____________/ \________||________/ 283 || 284 Browser Border TURN Proxy || 285 server || 286 KEY O Candidate 287 ..... Non encapsulated 288 - - - TURN encapsulated 289 ----- Double TURN encapsulated 290 || Network edge 292 Figure 4: WebRTC ICE Candidates with Application TURN and Border TURN 293 Proxy Servers 295 The Browser in Figure 4 implements RETURN, so it allocates a port on 296 the Border TURN server, now referred to as a Border TURN Proxy by 297 analogy to an HTTP CONNECT or SOCKS Proxy (see Figure 5), and then 298 runs STUN and TURN over this allocation, resulting in three 299 candidates: relay2, srflx2, and host2. The relay2 candidate causes 300 traffic to flow through both TURN servers by encapsulating TURN 301 within TURN - hence the name Recursively Encapsulated TURN (RETURN). 303 The host2 and srflx2 candidates are probably identical, so one will 304 be dropped by ICE. If the NAT/FW blocks UDP and the application uses 305 only relay candidates, then the relay2 candidate will be selected. 306 Otherwise, the other candidates will be used, in accordance with the 307 usual ICE procedure. 309 Only the browser needs to implement the RETURN behavior - both the 310 Border TURN Proxy and Application TURN servers' TURN protocol usage 311 is unchanged. 313 Note that this arrangement preserves the end-to-end security and 314 privacy features of WebRTC media flows. The ability to steer the 315 media flows through multiple TURN servers while still allowing 316 end-to-end encryption and authentication is a key benefit of 317 RETURN. 319 ____________ inside network || outside network 320 / \ || NAT/FW 321 | | ________||________ 322 | | / _____||_____ \ 323 | | | / || \ | 324 | | | | || | | 325 | | | | || | | 326 | Web Traffic|=============|==|============H | 327 | | | | || | | 328 | | HTTP/ | | || | | 329 | | HTTPS | \_____||_____/ | 330 | | Proxy | || | 331 | | | _____||_____ | 332 | | | / || \ | 333 | | | | || | | 334 | | | | || | | 335 |WebRTC Media|- - - - - - -|- |- - - - - - O | 336 | | | | || | | 337 | | | | || | | 338 | | TURN | \_____||_____/ | 339 \____________/ Proxy \________||________/ 340 || 341 Browser || 342 || 343 KEY O TURN Proxy Candidate 344 H HTTP/HTTPS Proxy Address 345 - - - TURN encapsulated 346 ===== HTTP/HTTPS web traffic 347 || Network edge 349 Figure 5: Similarity between HTTP/HTTPS Proxy and TURN Proxy 351 3. Goals 353 These goals are requirements on this document (not on implementations 354 of the specification). 356 3.1. Connectivity 358 As noted in [RFC7478] Section 2.3.5.1 and requirement F20, a WebRTC 359 browser endpoint MUST be able to direct UDP connections through a 360 designated TURN server configured by enterprise policy (a "proxy"). 362 It MUST be possible to configure a WebRTC endpoint that supports 363 proxies to achieve connectivity no worse than if the endpoint were 364 operating at the proxy's address. 366 For efficiency, network administrators SHOULD be able to prevent 367 browsers from attempting to send traffic through routes that are 368 already known to be blocked. 370 3.2. Independent Path Control 372 Both network administrators and application developers may wish to 373 direct all their UDP flows through a particular TURN server. There 374 are many goals that might motivate such a choice, including 376 o improving quality of service by tunneling packets through a 377 network that is faster than the public internet, 379 o monitoring the usage of UDP services, 381 o troubleshooting and debugging problematic services, 383 o logging connection metadata for legal or auditing reasons, 385 o recording the entire contents of all connections, or 387 o providing partial IP address anonymization (as described in 388 [I-D.ietf-rtcweb-security] Section 4.2.4 and 389 [I-D.ietf-rtcweb-security-arch] Section 5.4). 391 4. Concepts 393 To achieve our goals, we introduce the following new concepts: 395 4.1. Proxy 397 In this document a "proxy" is any TURN server that was provided by 398 any mechanism other than through the standard WebRTC-application ICE 399 candidate provisioning API [I-D.ietf-rtcweb-jsep]. We call it a 400 "proxy" by analogy with SOCKS proxies and similar network services, 401 because it performs a similar function and can be configured in a 402 similar fashion. 404 If a proxy is to be used, it will be the destination of traffic 405 generated by the client. (There is no analogue to the transparent/ 406 intercepting HTTP proxy configuration, which modifies traffic at the 407 network layer.) Mechanisms to configure a proxy include Auto- 408 Discovery [I-D.ietf-tram-turn-server-discovery] and local policy 409 ([I-D.ietf-rtcweb-jsep] Section 3.5.3, "ICE candidate policy"). 411 In an application context, a proxy may be "active" (producing 412 candidates) or "inactive" (not in use, having no effect on the 413 context). 415 4.2. Virtual interface 417 A typical WebRTC browser endpoint may have multiple network 418 interfaces available, such as wired ethernet, wireless ethernet, and 419 WAN. In this document, a "virtual interface" is a procedure for 420 generating ICE candidates that are not simply generated by a 421 particular physical interface. A virtual interface can produce 422 "host", "server-reflexive", and "relay" candidates, but may be 423 restricted to only some type of candidate (e.g. UDP-only). 425 4.3. Proxy configuration leakiness 427 "Leakiness" is an attribute of a proxy configuration. This document 428 defines two values for the "leakiness" of a proxy configuration: 429 "leaky" and "sealed". Proxy configuration, including leakiness, may 430 be set by local policy ([I-D.ietf-rtcweb-jsep], "ICE candidate 431 policy") or other mechanisms. 433 A leaky configuration adds a proxy and also allows the browser to use 434 routes that transit directly via the endpoint's physical interfaces 435 (not through the proxy). In a leaky configuration, setting a proxy 436 augments the available set of ICE candidates. Multiple leaky- 437 configuration proxies may therefore be active simultaneously. 439 A sealed proxy configuration requires the browser to route all WebRTC 440 traffic through the proxy, eliminating all ICE candidates that do not 441 go through the proxy. Only one sealed proxy may be active at a time. 443 Leaky proxy configurations allow more efficient routes to be 444 selected. For example, two peers on the same LAN can connect 445 directly (peer to peer) if a leaky proxy is enabled, but must 446 "hairpin" through the TURN proxy if the configuration is sealed. 447 However, sealed proxy configurations can be faster to connect, 448 especially if many of the peer-to-peer routes that ICE will try first 449 are blocked by the network's firewall policies. 451 4.4. Sealed proxy rank 453 In some configurations, an endpoint may be subject to multiple sealed 454 proxy settings at the same time. In that case, one of those settings 455 will have highest rank, and it will be the active proxy. In a given 456 application context (e.g. a webpage), there is at most one active 457 sealed proxy. This document does not specify a representation for 458 rank. 460 5. Requirements 462 5.1. ICE candidates produced in the presence of a proxy 464 When a proxy is configured, by Auto-Discovery or a proprietary means, 465 the browser MUST NOT report a "relay" candidate representing the 466 proxy. Instead, the browser MUST connect to the proxy and then, if 467 the connection is successful, treat the TURN tunnel as a UDP-only 468 virtual interface. 470 For a virtual interface representing a TURN proxy, this means that 471 the browser MUST report the public-facing IP address and port 472 acquired through TURN as a "host" candidate, the browser MUST perform 473 STUN through the TURN proxy (if STUN is configured), and it MUST 474 perform TURN by recursive encapsulation through the TURN proxy, 475 resulting in TURN candidates whose "raddr" and "rport" attributes 476 match the acquired public-facing IP address and port on the proxy. 478 Because the virtual interface has some additional overhead due to 479 indirection, it SHOULD have lower priority than the physical 480 interfaces if physical interfaces are also active. Specifically, 481 even host candidates generated by a virtual interface SHOULD have 482 priority 0 when physical interfaces are active (similar to [RFC5245] 483 Section 4.1.2.2, "the local preference for host candidates from a VPN 484 interface SHOULD have a priority of 0"). 486 5.2. Leaky proxy configuration 488 If the active proxy for an application is leaky, the browser should 489 undertake the standard ICE candidate discovery mechanism [RFC5245] on 490 the available physical and virtual interfaces. 492 5.3. Sealed proxy configuration 494 If the active proxy for an application is sealed, the browser MUST 495 NOT gather or produce any candidates on physical interfaces. The 496 WebRTC implementation MUST direct its traffic from those interfaces 497 only to the proxy, and perform ICE candidate discovery only on the 498 single virtual interface representing the active proxy. 500 5.4. Proxy rank 502 Any browser mechanism for specifying a proxy SHOULD allow the caller 503 to indicate a higher rank than the proxy provided by Auto-Discovery 504 [I-D.ietf-tram-turn-server-discovery]. 506 5.5. Multiple physical interfaces 508 Some operating systems allow the browser to use multiple interfaces 509 to contact a single remote IP address. To avoid producing an 510 excessive number of candidates, WebRTC endpoints MUST NOT use 511 multiple physical interfaces to connect to a single proxy 512 simultaneously. (If this were violated, it could produce a number of 513 virtual interfaces equal to the product of the number of physical 514 interfaces and the number of active proxies.) 516 Mechanisms for configuring a RETURN proxy SHOULD allow configuring a 517 proxy that only applies to connections made from a single physical 518 interface. This is useful to optimize efficiency in modes 2 and 3 of 519 [I-D.ietf-rtcweb-ip-handling]. 521 5.6. IPv4 and IPv6 523 A proxy MAY have both an IPv4 and an IPv6 address (e.g. if the proxy 524 is specified by DNS and has both A and AAAA records). The client MAY 525 try both of these addresses, but MUST select one, preferring IPv6, 526 before allocating any remote addresses. This corresponds to the the 527 Happy Eyeballs [RFC6555] procedure for dual-stack clients. 529 A proxy MAY provide both IPv4 and IPv6 remote addresses to clients 530 [RFC6156]. A client SHOULD request both address families. If both 531 requests are granted, the client SHOULD treat the two addresses as 532 host candidates on a dual-stack virtual interface. 534 5.7. Unspecified leakiness 536 If a proxy configuration mechanism does not specify leakiness, 537 browsers SHOULD treat the proxy as leaky. This is similar to current 538 WebRTC implementations' behavior in the presence of SOCKS and HTTP 539 proxies: the candidate allocation code continues to generate UDP 540 candidates that do not transit through the proxy. 542 5.8. Interaction with SOCKS5-UDP 544 The SOCKS5 proxy standard [RFC1928] permits compliant SOCKS proxies 545 to support UDP traffic. However, most implementations of SOCKS5 546 today do not support UDP. Accordingly, WebRTC browsers MUST by 547 default (i.e. unless deliberately configured otherwise) treat SOCKS5 548 proxies as leaky and having lower rank than any configured TURN 549 proxies. 551 5.9. Encapsulation overhead, fragmentation, and Path MTU 553 Encapsulating a link in TURN adds overhead on the path between the 554 client and the TURN server, because each packet must be wrapped in a 555 TURN message. This overhead is sometimes doubled in RETURN proxying. 556 To avoid excessive overhead, client implementations SHOULD use 557 ChannelBind and ChannelData messages to connect and send data through 558 proxies and application TURN servers when possible. Clients MAY 559 buffer messages to be sent until the ChannelBind command completes 560 (requiring one round trip to the proxy), or they MAY use 561 CreatePermission and Send messages for the first few packets to 562 reduce startup latency at the cost of higher overhead. 564 Adding overhead to packets on a link decreases the effective Maximum 565 Transmissible Unit on that link. Accordingly, clients that support 566 proxying MUST NOT rely on the effective MTU complying with the 567 Internet Protocol's minimum MTU requirement. 569 ChannelData messages have constant overheard, enabling consistent 570 effective PMTU, but Send messages do not necessarily have constant 571 overhead. TURN messages may be fragmented and reassembled if they 572 are not marked with the Don't Fragment (DF) IP bit or the DONT- 573 FRAGMENT TURN attribute. Client implementors should keep this in 574 mind, especially if they choose to implement PMTU discovery through 575 the proxy. 577 5.10. Interaction with alternate TURN server fallback 579 As per [RFC5766], a TURN server MAY respond to an Allocate request 580 with an error code of 300 and an ALTERNATE-SERVER indication. When 581 connecting to proxies or application TURN servers, clients SHOULD 582 attempt to connect to the specified alternate server in accordance 583 with [RFC5766]. The client MUST route a connection to the alternate 584 server through the proxy if and only if the original connection 585 attempt was routed through the proxy. 587 5.11. Reusing the same TURN server 589 It is possible that the same TURN server may appear more than once in 590 the network path. For example, if both endpoints configure the same 591 sealed proxy, then each peer will only provide candidates on this 592 proxy. This is not a problem, and will work as expected. 594 It is also possible that the same TURN server could be used by both 595 the enterprise and the application. It might appear attractive to 596 connect to this server only once, rathering connecting to it through 597 itself, in order to avoid imposing unnecessary server load. However, 598 a RETURN client MUST connect to the server twice, even when this 599 appears redundant, to ensure correct session attribution. 601 For example, consider a TURN service operator that issues different 602 authentication credentials to different customers, and then allows 603 each customer to observe the source and destination IP addresses used 604 with their credentials. Suppose the application and enterprise both 605 have accounts on this service: the application uses it to prevent the 606 enterprise from learning its peers' IP addresses, and the enterprise 607 uses it to prevent the application from learning its employees' IP 608 addresses. If the client only connects to the service once, then 609 either the enterprise or the application will learn IP address 610 information (via the TURN provider's metadata reporting) that was 611 meant to be kept secret. 613 As a result of this requirement, it is possible for the same TURN 614 server to appear up to four times in a RETURN network path: once as 615 each peer's application's TURN server, and once as each peer's sealed 616 proxy. 618 6. Examples 620 6.1. Firewalled enterprise network with a basic application 622 In this example, an enterprise network is configured with a firewall 623 that blocks all UDP traffic, and a TURN server is advertised for 624 Auto-Discovery in accordance with 625 [I-D.ietf-tram-turn-server-discovery]. The proxy leakiness of the 626 TURN server is unspecified, so the browser treats it as leaky. 628 The application specifies a STUN and TURN server on the public net. 629 In accordance with the ICE candidate gathering algorithm RFC 5245 630 [RFC5245], it receives a set of candidates like: 632 1. A host candidate acquired from one interface. 634 * e.g. candidate:1610808681 1 udp 2122194687 [internal ip addr 635 for interface 0] 63555 typ host generation 0 637 2. A host candidate acquired from a different interface. 639 * e.g. candidate:1610808681 1 udp 2122194687 [internal ip addr 640 for interface 1] 54253 typ host generation 0 642 3. The proxy, as a host candidate. 644 * e.g. candidate:3458234523 1 udp 24584191 [public ip addr for 645 the proxy] 54606 typ host generation 0 647 4. The virtual interface also generates a STUN candidate, but it is 648 eliminated because it is redundant with the host candidate, as 649 noted in [RFC5245] Sec 4.1.2.. 651 5. The application-provided TURN server as seen through the virtual 652 interface. (Traffic through this candidate is recursively 653 encapsulated.) 655 * e.g. candidate:702786350 1 udp 24583935 [public ip addr of the 656 application TURN server] 52631 typ relay raddr [public ip addr 657 for the proxy] rport 54606 generation 0 659 There are no STUN or TURN candidates on the physical interfaces, 660 because the application-specified STUN and TURN servers are not 661 reachable through the firewall. 663 If the remote peer is within the same network, it may be possible to 664 establish a direct connection using both peers' host candidates. If 665 the network prevents this kind of direct connection, the path will 666 instead take a "hairpin" route through the enterprise's proxy, using 667 one peer's physical "host" candidate and the other's virtual "host" 668 candidate, or (if that is also disallowed by the network 669 configuration) a "double hairpin" using both endpoints' virtual 670 "host" candidates. 672 6.2. Conflicting proxies configured by Auto-Discovery and local policy 674 Consider an enterprise network with TURN and HTTP proxies advertised 675 for Auto-Discovery with unspecified leakiness (thus defaulting to 676 leaky). The browser endpoint configures an additional TURN proxy by 677 a proprietary local mechanism. 679 If the locally configured proxy is leaky, then the browser MUST 680 produce candidates representing any physical interfaces (including 681 SSLTCP routes through the HTTP proxy), plus candidates for both UDP- 682 only virtual interfaces created by the two TURN servers. 684 There MUST NOT be any candidate that uses both proxies. Multiple 685 configured proxies are not chained recursively. 687 If the locally configured proxy is "sealed", then the browser MUST 688 produce only candidates from the virtual interface associated with 689 that proxy. 691 If both proxies are configured for "sealed" use, then the browser 692 MUST produce only candidates from the virtual interface associated 693 with the proxy with higher rank. 695 7. Security Considerations 697 A RETURN proxy can capture, block, and otherwise interfere with all 698 of its clients' WebRTC network activity. Therefore, browsers and 699 other WebRTC endpoints MUST NOT use RETURN proxies that are provided 700 by untrusted sources. For example, endpoints MUST NOT implement a 701 configuration based on unauthenticated network multicast (e.g. mDNS) 702 unless the endpoint will only be used on networks where all other 703 users are fully trusted to intercept all WebRTC traffic. In 704 contrast, endpoints MAY implement mechanisms to configure RETURN 705 proxies by system-wide policy, which can only be modified by trusted 706 system administrators. 708 This document describes web browser behaviors that, if implemented 709 correctly, allow users to achieve greater identity-confidentiality 710 during WebRTC calls under certain configurations. 712 If a site administrator offers the site's users a TURN proxy, 713 websites running in the users' browsers will be able to initiate a 714 UDP-based WebRTC connection to any UDP transport address via the 715 proxy. Websites' connections will quickly terminate if the remote 716 endpoint does not reply with a positive indication of ICE consent, 717 but no such restriction applies to other applications that access the 718 TURN server. Administrators should take care to provide TURN access 719 credentials only to the users who are authorized to have global UDP 720 network access. 722 TURN proxies and application TURN servers can provide some privacy 723 protection by obscuring the identity of one peer from the other. 724 However, unencrypted TURN provides no additional privacy from an 725 observer who can monitor the link between the TURN client and server, 726 and even encrypted TURN ([RFC7350] Section 4.6) does not provide 727 significant privacy from an observer who sniff traffic on both legs 728 of the TURN connection, due to packet timing correlations. 730 8. IANA Considerations 732 This document requires no actions from IANA. 734 9. Acknowledgements 736 Thanks to Harald Alvestrand, Philipp Hancke, Tirumaleswar Reddy, Alan 737 Johnston, John Yoakum, and Cullen Jennings for suggestions to improve 738 the content and presentation. Special thanks to Alan Johnston for 739 contributing the visual overview in Section 2. 741 10. References 743 10.1. Normative References 745 [I-D.ietf-rtcweb-jsep] 746 Uberti, J., Jennings, C., and E. Rescorla, "Javascript 747 Session Establishment Protocol", draft-ietf-rtcweb-jsep-19 748 (work in progress), March 2017. 750 [I-D.ietf-tram-turn-server-discovery] 751 Patil, P., Reddy, T., and D. Wing, "TURN Server Auto 752 Discovery", draft-ietf-tram-turn-server-discovery-12 (work 753 in progress), January 2017. 755 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 756 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 757 DOI 10.17487/RFC1928, March 1996, 758 . 760 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 761 (ICE): A Protocol for Network Address Translator (NAT) 762 Traversal for Offer/Answer Protocols", RFC 5245, 763 DOI 10.17487/RFC5245, April 2010, 764 . 766 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 767 Relays around NAT (TURN): Relay Extensions to Session 768 Traversal Utilities for NAT (STUN)", RFC 5766, 769 DOI 10.17487/RFC5766, April 2010, 770 . 772 [RFC6156] Camarillo, G., Novo, O., and S. Perreault, Ed., "Traversal 773 Using Relays around NAT (TURN) Extension for IPv6", 774 RFC 6156, DOI 10.17487/RFC6156, April 2011, 775 . 777 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 778 Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 779 2012, . 781 10.2. Informative References 783 [I-D.ietf-rtcweb-ip-handling] 784 Uberti, J. and G. Shieh, "WebRTC IP Address Handling 785 Requirements", draft-ietf-rtcweb-ip-handling-03 (work in 786 progress), January 2017. 788 [I-D.ietf-rtcweb-security] 789 Rescorla, E., "Security Considerations for WebRTC", draft- 790 ietf-rtcweb-security-08 (work in progress), February 2015. 792 [I-D.ietf-rtcweb-security-arch] 793 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 794 rtcweb-security-arch-12 (work in progress), June 2016. 796 [RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport 797 Layer Security (DTLS) as Transport for Session Traversal 798 Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350, 799 August 2014, . 801 [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 802 Time Communication Use Cases and Requirements", RFC 7478, 803 DOI 10.17487/RFC7478, March 2015, 804 . 806 Authors' Addresses 808 Benjamin M. Schwartz 809 Google, Inc. 810 111 8th Ave 811 New York, NY 10011 812 USA 814 Email: bemasc@webrtc.org 816 Justin Uberti 817 Google, Inc. 818 747 6th Street South 819 Kirkland, WA 98033 820 USA 822 Email: justin@uberti.name