idnits 2.17.1 draft-schwartz-rtcweb-return-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 146: '...nt F20, a WebRTC browser endpoint MUST...' RFC 2119 keyword, line 150: '... It MUST be possible to configure a ...' RFC 2119 keyword, line 154: '...k administrators SHOULD be able to pre...' RFC 2119 keyword, line 161: '... applications MUST have the ability ...' RFC 2119 keyword, line 164: '...e WebRTC browser MAY attempt to preven...' (33 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 247 has weird spacing: '... |relay srfl...' == Line 269 has weird spacing: '... |relay srfl...' -- The document date (November 10, 2014) is 3454 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == 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 (~~), 6 warnings (==), 4 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: May 14, 2015 November 10, 2014 7 Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in 8 WebRTC 9 draft-schwartz-rtcweb-return-04 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 May 14, 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 . . . . . . . . . . . . . . . . . . . . . . 4 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. Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 64 5.1. ICE candidates produced in the presence of a proxy . . . 7 65 5.2. Leaky proxy configuration . . . . . . . . . . . . . . . . 8 66 5.3. Sealed proxy configuration . . . . . . . . . . . . . . . 8 67 5.4. Proxy rank . . . . . . . . . . . . . . . . . . . . . . . 8 68 5.5. Multiple physical interfaces . . . . . . . . . . . . . . 8 69 5.6. IPv4 and IPv6 . . . . . . . . . . . . . . . . . . . . . . 8 70 5.7. Unspecified leakiness . . . . . . . . . . . . . . . . . . 9 71 5.8. Interaction with SOCKS5-UDP . . . . . . . . . . . . . . . 9 72 5.9. Encapsulation overhead, fragmentation, and Path MTU . . . 9 73 5.10. Interaction with alternate TURN server fallback . . . . . 10 74 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 6.1. Firewalled enterprise network with a basic application . 10 76 6.2. Conflicting proxies configured by Auto-Discovery and 77 local policy . . . . . . . . . . . . . . . . . 11 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 83 10.2. Informative References . . . . . . . . . . . . . . . . . 13 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 TURN [RFC5766] is a protocol for communication between a client and a 89 TURN server, in order to route UDP traffic to and from one or more 90 peers. As noted in [RFC5766], the TURN relay server "typically sits 91 in the public Internet". In a WebRTC context, if a TURN server is to 92 be used, it is typically provided by the application, either to 93 provide connectivity between users whose NATs would otherwise prevent 94 it, or to obscure the identity of the participants by concealing 95 their IP addresses from one another. 97 In many enterprises, direct UDP transmissions are not permitted 98 between clients on the internal networks and external IP addresses, 99 so media must flow over TCP. To enable WebRTC services in such a 100 situation, clients must use TURN-TCP, or TURN-TLS. These 101 configurations are not ideal: they send all traffic over TCP, which 102 leads to higher latency than would otherwise be necessary, and they 103 force the application provider to operate a TURN server because 104 WebRTC endpoints behind NAT cannot typically act as TCP servers. 105 These configurations may result in especially bad behaviors when 106 operating through TCP or HTTP proxies that were not designed to carry 107 real-time media streams. 109 To avoid forcing WebRTC media streams through a TCP stage, enterprise 110 network operators may operate a TURN server for their network, which 111 can be discovered by clients using TURN Auto-Discovery 112 [I-D.ietf-tram-turn-server-discovery], or through a proprietary 113 mechanism. This TURN server may be placed inside the network, with a 114 firewall configuration allowing it to communicate with the public 115 internet, or it may be operated by the a third party outside the 116 network, with a firewall configuration that allows hosts inside the 117 network. to communicate with it. Use of the specified TURN server 118 may be the only way for clients on the network to achieve a high 119 quality WebRTC experience. This scenario is required to be supported 120 by the WebRTC requirements document 121 [I-D.ietf-rtcweb-use-cases-and-requirements] Section 3.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. Goals 140 These goals are requirements on this document (not on implementations 141 of the specification). 143 2.1. Connectivity 145 As noted in [I-D.ietf-rtcweb-use-cases-and-requirements] 146 Section 3.3.5.1 and requirement F20, a WebRTC browser endpoint MUST 147 be able to direct UDP connections through a designated TURN server 148 configured by enterprise policy (a "proxy"). 150 It MUST be possible to configure a WebRTC endpoint that supports 151 proxies to achieve connectivity no worse than if the endpoint were 152 operating at the proxy's address. 154 For efficiency, network administrators SHOULD be able to prevent 155 browsers from attempting to send traffic through routes that are 156 already known to be blocked. 158 2.2. Privacy 160 To prevent WebRTC peers from determining each others' IP addresses, 161 applications MUST have the ability to direct all traffic through an 162 application-specified TURN server. 164 A compatible WebRTC browser MAY attempt to prevent a hostile web page 165 from determining the endpoint's public IP address. (This requirement 166 is documented in [I-D.ietf-rtcweb-security] Section 4.2.4. Note that 167 the measures proposed here are not sufficient by themselves to 168 achieve this goal. Implementing this specification in current 169 browsers would still leave many other ways for a malicious website to 170 determine the endpoint's IP address. Operating-system-wide VPN 171 configurations are therefore currently preferred for this purpose.) 173 A compatible WebRTC browser MAY allow the user to prevent non- 174 malicious web pages from accidentally revealing the IP address of 175 remote peers to a local passive network adversary. This ability 176 SHOULD NOT reduce performance when it is not in use. (Due to the 177 difficulty of distinguishing between stupidity and malice, this goal 178 is principally aspirational.) 180 3. Concepts 182 To achieve our goals, we introduce the following new concepts: 184 3.1. Proxy 186 In this document a "proxy" is any TURN server that was provided by 187 any mechanism other than through the standard WebRTC-application ICE 188 candidate provisioning API [I-D.ietf-rtcweb-jsep]. If a proxy is to 189 be used, it will be the destination of traffic generated by the 190 client. There is no analogue to the transparent/intercepting HTTP 191 proxy configuration, which modifies traffic at the network layer. 192 Mechanisms to configure a proxy include Auto-Discovery 193 [I-D.ietf-tram-turn-server-discovery] and local policy 194 ([I-D.ietf-rtcweb-jsep], "ICE candidate policy"). 196 In an application context, a proxy may be "active" (producing 197 candidates) or "inactive" (not in use, having no effect on the 198 context). 200 3.2. Virtual interface 202 A typical WebRTC browser endpoint may have multiple network 203 interfaces available, such as wired ethernet, wireless ethernet, and 204 WAN. In this document, a "virtual interface" is a procedure for 205 generating ICE candidates that are not simply generated by a 206 particular physical interface. A virtual interface can produce 207 "host", "server-reflexive", and "relay" candidates, but may be 208 restricted to only some type of candidate (e.g. UDP-only). 210 3.3. Proxy configuration leakiness 212 "Leakiness" is an attribute of a proxy configuration. This document 213 defines two values for the "leakiness" of a proxy configuration: 214 "leaky" and "sealed". Proxy configuration, including leakiness, may 215 be set by local policy ([I-D.ietf-rtcweb-jsep], "ICE candidate 216 policy") or other mechanisms. 218 A leaky configuration adds a proxy and also allows the browser to use 219 routes that transit directly via the endpoint's physical interfaces 220 (not through the proxy). In a leaky configuration, setting a proxy 221 augments the available set of ICE candidates. Multiple leaky- 222 configuration proxies may therefore be active simultaneously. 224 A sealed proxy configuration requires the browser to route all WebRTC 225 traffic through the proxy, eliminating all ICE candidates that do not 226 go through the proxy. Only one sealed proxy may be active at a time. 228 3.4. Sealed proxy rank 230 In some configurations, an endpoint may be subject to multiple sealed 231 proxy settings at the same time. In that case, one of those settings 232 will have highest rank, and it will be the active proxy. In a given 233 application context (e.g. a webpage), there is at most one active 234 sealed proxy. This document does not specify a representation for 235 rank. 237 4. Diagrams 239 This figure shows the connections that provide the ICE candidates for 240 WebRTC in the basic configuration (no proxy). This figure is 241 provided in order to serve as a baseline against which to compare the 242 candidate routes that make use of a proxy. 244 +-------------+ * * 245 |UDP generator| * * +----+ 246 | host+----+--O-----O.....+STUN| 247 |relay srflx| | * * +----+ 248 +--+-------+--+ | * * 249 | | | * LAN * 250 | \-------/ * * 251 | * * * 252 | +------+ * * +------+ * 253 \------+ TURN +==============+ TURN +-----O 254 |client| * * |server| * 255 +------+ * * +------+ * 257 .. STUN packets *** Network interface 258 -- Bare UDP content link *O* Candidate port 259 == TURN encapsulated link 261 Figure 1: Basic WebRTC ICE candidates (no proxy) 263 This figure shows the connections that provide the ICE candidates for 264 WebRTC on the virtual interface that represents a proxy. 266 +-------------+ * +------+ * +----+ 267 |UDP generator| * |Proxy | * .+STUN| 268 | host+-------+ TURN | * * . +----+ 269 |relay srflx| * |Client| * * . 270 +--+-------+--+ * | | * +------+ * . +------+ * 271 | | * | | * |Proxy | *. | App | * 272 | \----------+ +######+ TURN +????O=====+TURN +-----O 273 | * | | * |Server| * |Server| * 274 | +------+ * | | * +------+ * +------+ * 275 | | App | * | | * * 276 \------+ TURN +====+ | * * 277 |client| * | | * 278 +------+ * +------+ * 280 .. STUN packets *** Network interface 281 -- Bare UDP content link *O* Candidate port 282 == TURN encapsulated UDP content link 283 ## RETURN double-encapsulated link 284 ?? Mixed content link 286 Figure 2: WebRTC ICE candidates using a proxy 288 5. Requirements 290 5.1. ICE candidates produced in the presence of a proxy 292 When a proxy is configured, by Auto-Discovery or a proprietary means, 293 the browser MUST NOT report a "relay" candidate representing the 294 proxy. Instead, the browser MUST connect to the proxy and then, if 295 the connection is successful, treat the TURN tunnel as a UDP-only 296 virtual interface. 298 For a virtual interface representing a TURN proxy, this means that 299 the browser MUST report the public-facing IP address and port 300 acquired through TURN as a "host" candidate, the browser MUST perform 301 STUN through the TURN proxy (if STUN is configured), and it MUST 302 perform TURN by recursive encapsulation through the TURN proxy, 303 resulting in TURN candidates whose "raddr" and "rport" attributes 304 match the acquired public-facing IP address and port on the proxy. 306 Because the virtual interface has some additional overhead due to 307 indirection, it SHOULD have lower priority than the physical 308 interfaces if physical interfaces are also active. Specifically, 309 even host candidates generated by a virtual interface SHOULD have 310 priority 0 when physical interfaces are active (similar to [RFC5245] 311 Section 4.1.2.2, "the local preference for host candidates from a VPN 312 interface SHOULD have a priority of 0"). 314 5.2. Leaky proxy configuration 316 If the active proxy for an application is leaky, the browser should 317 undertake the standard ICE candidate discovery mechanism [RFC5245] on 318 the available physical and virtual interfaces. 320 5.3. Sealed proxy configuration 322 If the active proxy for an application is sealed, the browser MUST 323 NOT gather or produce any candidates on physical interfaces. The 324 WebRTC implementation MUST direct its traffic from those interfaces 325 only to the proxy, and perform ICE candidate discovery only on the 326 single virtual interface representing the active proxy. 328 5.4. Proxy rank 330 Any browser mechanism for specifying a proxy SHOULD allow the caller 331 to indicate a higher rank than the proxy provided by Auto-Discovery 332 [I-D.ietf-tram-turn-server-discovery]. 334 5.5. Multiple physical interfaces 336 Some operating systems allow the browser to use multiple interfaces 337 to contact a single remote IP address. To avoid producing an 338 excessive number of candidates, WebRTC endpoints MUST NOT use 339 multiple physical interfaces to connect to a single proxy 340 simultaneously. (If this were violated, it could produce a number of 341 virtual interfaces equal to the product of the number of physical 342 interfaces and the number of active proxies.) 344 For strategies to choose the best interface for communication with a 345 proxy, see [I-D.reddy-mmusic-ice-best-interface-pcp]. Similar 346 considerations apply when connecting to an application-specified TURN 347 server in the presence of physical and virtual interfaces. 349 5.6. IPv4 and IPv6 351 A proxy MAY have both an IPv4 and an IPv6 address (e.g. if the proxy 352 is specified by DNS and has both A and AAAA records). The client MAY 353 try both of these addresses, but MUST select one, preferring IPv6, 354 before allocating any remote addresses. This corresponds to the the 355 Happy Eyeballs [RFC6555] procedure for dual-stack clients. 357 A proxy MAY provide both IPv4 and IPv6 remote addresses to clients 358 [RFC6156]. A client SHOULD request both address families. If both 359 requests are granted, the client SHOULD treat the two addresses as 360 host candidates on a dual-stack virtual interface. 362 5.7. Unspecified leakiness 364 If a proxy configuration mechanism does not specify leakiness, 365 browsers SHOULD treat the proxy as leaky. This is similar to current 366 WebRTC implementations' behavior in the presence of SOCKS and HTTP 367 proxies: the candidate allocation code continues to generate UDP 368 candidates that do not transit through the proxy. 370 5.8. Interaction with SOCKS5-UDP 372 The SOCKS5 proxy standard [RFC1928] permits compliant SOCKS proxies 373 to support UDP traffic. However, most implementations of SOCKS5 374 today do not support UDP. Accordingly, WebRTC browsers MUST by 375 default (i.e. unless deliberately configured otherwise) treat SOCKS5 376 proxies as leaky and having lower rank than any configured TURN 377 proxies. 379 5.9. Encapsulation overhead, fragmentation, and Path MTU 381 Encapsulating a link in TURN adds overhead on the path between the 382 client and the TURN server, because each packet must be wrapped in a 383 TURN message. This overhead is sometimes doubled in RETURN proxying. 384 To avoid excessive overhead, client implementations SHOULD use 385 ChannelBind and ChannelData messages to connect and send data through 386 proxies and application TURN servers when possible. Clients MAY 387 buffer messages to be sent until the ChannelBind command completes 388 (requiring one round trip to the proxy), or they MAY use 389 CreatePermission and Send messages for the first few packets to 390 reduce startup latency at the cost of higher overhead. 392 Adding overhead to packets on a link decreases the effective Maximum 393 Transmissible Unit on that link. Accordingly, clients that support 394 proxying MUST NOT rely on the effective MTU complying with the 395 Internet Protocol's minimum MTU requirement. 397 ChannelData messages have constant overheard, enabling consistent 398 effective PMTU, but Send messages do not necessarily have constant 399 overhead. TURN messages may be fragmented and reassembled if they 400 are not marked with the Don't Fragment (DF) IP bit or the DONT- 401 FRAGMENT TURN attribute. Client implementors should keep this in 402 mind, especially if they choose to implement PMTU discovery through 403 the proxy. 405 5.10. Interaction with alternate TURN server fallback 407 As per [RFC5766], a TURN server MAY respond to an Allocate request 408 with an error code of 300 and an ALTERNATE-SERVER indication. When 409 connecting to proxies or application TURN servers, clients SHOULD 410 attempt to connect to the specified alternate server in accordance 411 with [RFC5766]. The client MUST route a connection to the alternate 412 server through the proxy if and only if the original connection 413 attempt was routed through the proxy. 415 6. Examples 417 6.1. Firewalled enterprise network with a basic application 419 In this example, an enterprise network is configured with a firewall 420 that blocks all UDP traffic, and a TURN server is advertised for 421 Auto-Discovery in accordance with 422 [I-D.ietf-tram-turn-server-discovery]. The proxy leakiness of the 423 TURN server is unspecified, so the browser treats it as leaky. 425 The application specifies a STUN and TURN server on the public net. 426 In accordance with the ICE candidate gathering algorithm RFC 5245 427 [RFC5245], it receives a set of candidates like: 429 1. A host candidate acquired from one interface. 431 * e.g. candidate:1610808681 1 udp 2122194687 [internal ip addr 432 for interface 0] 63555 typ host generation 0 434 2. A host candidate acquired from a different interface. 436 * e.g. candidate:1610808681 1 udp 2122194687 [internal ip addr 437 for interface 1] 54253 typ host generation 0 439 3. The proxy, as a host candidate. 441 * e.g. candidate:3458234523 1 udp 24584191 [public ip addr for 442 the proxy] 54606 typ host generation 0 444 4. The virtual interface also generates a STUN candidate, but it is 445 eliminated because it is redundant with the host candidate, as 446 noted in [RFC5245] Sec 4.1.2.. 448 5. The application-provided TURN server as seen through the virtual 449 interface. (Traffic through this candidate is recursively 450 encapsulated.) 451 * e.g. candidate:702786350 1 udp 24583935 [public ip addr of the 452 application TURN server] 52631 typ relay raddr [public ip addr 453 for the proxy] rport 54606 generation 0 455 There are no STUN or TURN candidates on the physical interfaces, 456 because the application-specified STUN and TURN servers are not 457 reachable through the firewall. 459 If the remote peer is within the same network, it may be possible to 460 establish a direct connection using both peers' host candidates. If 461 the network prevents this kind of direct connection, the path will 462 instead take a "hairpin" route through the enterprise's proxy, using 463 one peer's physical "host" candidate and the other's virtual "host" 464 candidate, or (if that is also disallowed by the network 465 configuration) a "double hairpin" using both endpoints' virtual 466 "host" candidates. 468 6.2. Conflicting proxies configured by Auto-Discovery and local policy 470 Consider an enterprise network with TURN and HTTP proxies advertised 471 for Auto-Discovery with unspecified leakiness (thus defaulting to 472 leaky). The browser endpoint configures an additional TURN proxy by 473 a proprietary local mechanism. 475 If the locally configured proxy is leaky, then the browser MUST 476 produce candidates representing any physical interfaces (including 477 SSLTCP routes through the HTTP proxy), plus candidates for both UDP- 478 only virtual interfaces created by the two TURN servers. 480 There MUST NOT be any candidate that uses both proxies. Multiple 481 configured proxies are not chained recursively. 483 If the locally configured proxy is "sealed", then the browser MUST 484 produce only candidates from the virtual interface associated with 485 that proxy. 487 If both proxies are configured for "sealed" use, then the browser 488 MUST produce only candidates from the virtual interface associated 489 with the proxy with higher rank. 491 7. Security Considerations 493 This document describes web browser behaviors that, if implemented 494 correctly, allow users to achieve greater identity-confidentiality 495 during WebRTC calls under certain configurations. 497 If a site administrator offers the site's users a TURN proxy, 498 websites running in the users' browsers will be able to initiate a 499 UDP-based WebRTC connection to any UDP transport address via the 500 proxy. Websites' connections will quickly terminate if the remote 501 endpoint does not reply with a positive indication of ICE consent, 502 but no such restriction applies to other applications that access the 503 TURN server. Administrators should take care to provide TURN access 504 credentials only to the users who are authorized to have global UDP 505 network access. 507 TURN proxies and application TURN servers can provide some privacy 508 protection by obscuring the identity of one peer from the other. 509 However, unencrypted TURN provides no additional privacy from an 510 observer who can monitor the link between the TURN client and server, 511 and even encrypted TURN ([I-D.ietf-tram-stun-dtls] Section 4.6) does 512 not provide significant privacy from an observer who sniff traffic on 513 both legs of the TURN connection, due to packet timing correlations. 515 8. IANA Considerations 517 This document requires no actions from IANA. 519 9. Acknowledgements 521 Significant review, including the virtual-interface formulation, was 522 provided by Justin Uberti. Thanks to Harald Alvestrand, Philipp 523 Hancke, and Tirumaleswar Reddy for suggestions to improve the content 524 and presentation. 526 10. References 528 10.1. Normative References 530 [I-D.ietf-rtcweb-jsep] 531 Uberti, J. and C. Jennings, "Javascript Session 532 Establishment Protocol", draft-ietf-rtcweb-jsep-06 (work 533 in progress), February 2014. 535 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 536 L. Jones, "SOCKS Protocol Version 5", RFC 5766, March 537 1996. 539 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 540 (ICE): A Protocol for Network Address Translator (NAT) 541 Traversal for Offer/Answer Protocols", RFC 5245, April 542 2010. 544 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 545 Relays around NAT (TURN): Relay Extensions to Session 546 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 548 [RFC6156] Camarillo, G., Novo, O., and S. Perreault, "Traversal 549 Using Relays around NAT (TURN) Extension for IPv6", RFC 550 6156, April 2011. 552 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 553 Dual-Stack Hosts", RFC 6555, April 2012. 555 10.2. Informative References 557 [I-D.ietf-rtcweb-security] 558 Rescorla, E., "Security Considerations for WebRTC", ietf- 559 rtcweb-security-07 (work in progress), July 2014. 561 [I-D.ietf-rtcweb-use-cases-and-requirements] 562 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 563 Time Communication Use-cases and Requirements", ietf- 564 rtcweb-use-cases-and-requirements-14 (work in progress), 565 February 2014. 567 [I-D.ietf-tram-stun-dtls] 568 Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport 569 Layer Security (DTLS) as Transport for Session Traversal 570 Utilities for NAT (STUN)", ietf-rtcweb-use-cases-and- 571 requirements-14 (work in progress), June 2014. 573 [I-D.ietf-tram-turn-server-discovery] 574 Patil, P., Reddy, T., and D. Wing, "TURN Server Auto 575 Discovery", draft-ietf-tram-turn-server-discovery-00 (work 576 in progress), July 2014. 578 [I-D.reddy-mmusic-ice-best-interface-pcp] 579 Reddy, T., Wing, D., VerSteeg, B., Penno, R., and V. 580 Singh, "Improving ICE Interface Selection Using Port 581 Control Protocol (PCP) Flow Extension", draft-ietf-tram- 582 turn-server-discovery-00 (work in progress), October 2013. 584 Authors' Addresses 586 Benjamin M. Schwartz 587 Google, Inc. 588 111 8th Ave 589 New York, NY 10011 590 USA 592 Email: bemasc@webrtc.org 593 Justin Uberti 594 Google, Inc. 595 747 6th Street South 596 Kirkland, WA 98033 597 USA 599 Email: justin@uberti.name