idnits 2.17.1 draft-schwartz-rtcweb-return-03.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 145: '...nt F20, a WebRTC browser endpoint MUST...' RFC 2119 keyword, line 149: '... It MUST be possible to configure a ...' RFC 2119 keyword, line 153: '...k administrators SHOULD be able to pre...' RFC 2119 keyword, line 160: '... applications MUST have the ability ...' RFC 2119 keyword, line 163: '...e WebRTC browser MAY attempt to preven...' (27 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 246 has weird spacing: '... |relay srfl...' == Line 268 has weird spacing: '... |relay srfl...' -- The document date (September 2, 2014) is 3516 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) -- No information found for draft-ietf-tram-stun-dtls - is the name correct? == Outdated reference: A later version (-12) exists of draft-ietf-tram-turn-server-discovery-00 == Outdated reference: A later version (-12) exists of draft-ietf-tram-turn-server-discovery-00 -- Duplicate reference: draft-ietf-tram-turn-server-discovery, mentioned in 'I-D.reddy-mmusic-ice-best-interface-pcp', was also mentioned in 'I-D.ietf-tram-turn-server-discovery'. Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Schwartz 3 Internet-Draft Google 4 Intended status: Standards Track September 2, 2014 5 Expires: March 6, 2015 7 Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in 8 WebRTC 9 draft-schwartz-rtcweb-return-03 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 March 6, 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. Unspecified leakiness . . . . . . . . . . . . . . . . . . 8 70 5.7. Interaction with SOCKS5-UDP . . . . . . . . . . . . . . . 9 71 5.8. Encapsulation overhead, fragmentation, and Path MTU . . . 9 72 5.9. Interaction with alternate TURN server fallback . . . . . 9 73 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 6.1. Firewalled enterprise network with a basic application . 10 75 6.2. Conflicting proxies configured by Auto-Discovery and 76 local policy . . . . . . . . . . . . . . . . . 11 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 82 10.2. Informative References . . . . . . . . . . . . . . . . . 12 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 TURN [RFC5766] is a protocol for communication between a client and a 88 TURN server, in order to route UDP traffic to and from one or more 89 peers. As noted in [RFC5766], the TURN relay server "typically sits 90 in the public Internet". In a WebRTC context, if a TURN server is to 91 be used, it is typically provided by the application, either to 92 provide connectivity between users whose NATs would otherwise prevent 93 it, or to obscure the identity of the participants by concealing 94 their IP addresses from one another. 96 In many enterprises, direct UDP transmissions are not permitted 97 between clients on the internal networks and external IP addresses, 98 so media must flow over TCP. To enable WebRTC services in such a 99 situation, clients must use TURN-TCP, or TURN-TLS. These 100 configurations are not ideal: they send all traffic over TCP, which 101 leads to higher latency than would otherwise be necessary, and they 102 force the application provider to operate a TURN server because 103 WebRTC endpoints behind NAT cannot typically act as TCP servers. 104 These configurations may result in especially bad behaviors when 105 operating through TCP or HTTP proxies that were not designed to carry 106 real-time media streams. 108 To avoid forcing WebRTC media streams through a TCP stage, enterprise 109 network operators may operate a TURN server for their network, which 110 can be discovered by clients using TURN Auto-Discovery 111 [I-D.ietf-tram-turn-server-discovery], or through a proprietary 112 mechanism. This TURN server may be placed inside the network, with a 113 firewall configuration allowing it to communicate with the public 114 internet, or it may be operated by the a third party outside the 115 network, with a firewall configuration that allows hosts inside the 116 network. to communicate with it. Use of the specified TURN server 117 may be the only way for clients on the network to achieve a high 118 quality WebRTC experience. This scenario is required to be supported 119 by the WebRTC requirements document 120 [I-D.ietf-rtcweb-use-cases-and-requirements] Section 3.3.5.1. 122 When the application intends to use a TURN server for identity 123 cloaking, and the enterprise network administrator intends to use a 124 TURN server for connectivity, there is a conflict. In current WebRTC 125 implementations, TURN can only be used on a single-hop basis in each 126 candidate, but using only the enterprise's TURN server reveals 127 information about the user (e.g. organizational affiliation), and 128 using only the application's TURN server may be blocked by the 129 network administrator, or may require using TURN-TCP or TURN-TLS, 130 resulting in a significant sacrifice in latency. 132 To resolve this conflict, we introduce Recursively Encapsulated TURN, 133 a procedure that allows a WebRTC endpoint to route traffic through 134 multiple TURN servers, and get improved connectivity and privacy in 135 return. 137 2. Goals 139 These goals are requirements on this document (not on implementations 140 of the specification). 142 2.1. Connectivity 144 As noted in [I-D.ietf-rtcweb-use-cases-and-requirements] 145 Section 3.3.5.1 and requirement F20, a WebRTC browser endpoint MUST 146 be able to direct UDP connections through a designated TURN server 147 configured by enterprise policy (a "proxy"). 149 It MUST be possible to configure a WebRTC endpoint that supports 150 proxies to achieve connectivity no worse than if the endpoint were 151 operating at the proxy's address. 153 For efficiency, network administrators SHOULD be able to prevent 154 browsers from attempting to send traffic through routes that are 155 already known to be blocked. 157 2.2. Privacy 159 To prevent WebRTC peers from determining each others' IP addresses, 160 applications MUST have the ability to direct all traffic through an 161 application-specified TURN server. 163 A compatible WebRTC browser MAY attempt to prevent a hostile web page 164 from determining the endpoint's public IP address. (This requirement 165 is documented in [I-D.ietf-rtcweb-security] Section 4.2.4. Note that 166 the measures proposed here are not sufficient by themselves to 167 achieve this goal. Implementing this specification in current 168 browsers would still leave many other ways for a malicious website to 169 determine the endpoint's IP address. Operating-system-wide VPN 170 configurations are therefore currently preferred for this purpose.) 172 A compatible WebRTC browser MAY allow the user to prevent non- 173 malicious web pages from accidentally revealing the IP address of 174 remote peers to a local passive network adversary. This ability 175 SHOULD NOT reduce performance when it is not in use. (Due to the 176 difficulty of distinguishing between stupidity and malice, this goal 177 is principally aspirational.) 179 3. Concepts 181 To achieve our goals, we introduce the following new concepts: 183 3.1. Proxy 185 In this document a "proxy" is any TURN server that was provided by 186 any mechanism other than through the standard WebRTC-application ICE 187 candidate provisioning API [I-D.ietf-rtcweb-jsep]. If a proxy is to 188 be used, it will be the destination of traffic generated by the 189 client. There is no analogue to the transparent/intercepting HTTP 190 proxy configuration, which modifies traffic at the network layer. 191 Mechanisms to configure a proxy include Auto-Discovery 192 [I-D.ietf-tram-turn-server-discovery] and local policy 193 ([I-D.ietf-rtcweb-jsep], "ICE candidate policy"). 195 In an application context, a proxy may be "active" (producing 196 candidates) or "inactive" (not in use, having no effect on the 197 context). 199 3.2. Virtual interface 201 A typical WebRTC browser endpoint may have multiple network 202 interfaces available, such as wired ethernet, wireless ethernet, and 203 WAN. In this document, a "virtual interface" is a procedure for 204 generating ICE candidates that are not simply generated by a 205 particular physical interface. A virtual interface can produce 206 "host", "server-reflexive", and "relay" candidates, but may be 207 restricted to only some type of candidate (e.g. UDP-only). 209 3.3. Proxy configuration leakiness 211 "Leakiness" is an attribute of a proxy configuration. This document 212 defines two values for the "leakiness" of a proxy configuration: 213 "leaky" and "sealed". Proxy configuration, including leakiness, may 214 be set by local policy ([I-D.ietf-rtcweb-jsep], "ICE candidate 215 policy") or other mechanisms. 217 A leaky configuration adds a proxy and also allows the browser to use 218 routes that transit directly via the endpoint's physical interfaces 219 (not through the proxy). In a leaky configuration, setting a proxy 220 augments the available set of ICE candidates. Multiple leaky- 221 configuration proxies may therefore be active simultaneously. 223 A sealed proxy configuration requires the browser to route all WebRTC 224 traffic through the proxy, eliminating all ICE candidates that do not 225 go through the proxy. Only one sealed proxy may be active at a time. 227 3.4. Sealed proxy rank 229 In some configurations, an endpoint may be subject to multiple sealed 230 proxy settings at the same time. In that case, one of those settings 231 will have highest rank, and it will be the active proxy. In a given 232 application context (e.g. a webpage), there is at most one active 233 sealed proxy. This document does not specify a representation for 234 rank. 236 4. Diagrams 238 This figure shows the connections that provide the ICE candidates for 239 WebRTC in the basic configuration (no proxy). This figure is 240 provided in order to serve as a baseline against which to compare the 241 candidate routes that make use of a proxy. 243 +-------------+ * * 244 |UDP generator| * * +----+ 245 | host+----+--O-----O.....+STUN| 246 |relay srflx| | * * +----+ 247 +--+-------+--+ | * * 248 | | | * LAN * 249 | \-------/ * * 250 | * * * 251 | +------+ * * +------+ * 252 \------+ TURN +==============+ TURN +-----O 253 |client| * * |server| * 254 +------+ * * +------+ * 256 .. STUN packets *** Network interface 257 -- Bare UDP content link *O* Candidate port 258 == TURN encapsulated link 260 Figure 1: Basic WebRTC ICE candidates (no proxy) 262 This figure shows the connections that provide the ICE candidates for 263 WebRTC on the virtual interface that represents a proxy. 265 +-------------+ * +------+ * +----+ 266 |UDP generator| * |Proxy | * .+STUN| 267 | host+-------+ TURN | * * . +----+ 268 |relay srflx| * |Client| * * . 269 +--+-------+--+ * | | * +------+ * . +------+ * 270 | | * | | * |Proxy | *. | App | * 271 | \----------+ +######+ TURN +????O=====+TURN +-----O 272 | * | | * |Server| * |Server| * 273 | +------+ * | | * +------+ * +------+ * 274 | | App | * | | * * 275 \------+ TURN +====+ | * * 276 |client| * | | * 277 +------+ * +------+ * 279 .. STUN packets *** Network interface 280 -- Bare UDP content link *O* Candidate port 281 == TURN encapsulated UDP content link 282 ## RETURN double-encapsulated link 283 ?? Mixed content link 285 Figure 2: WebRTC ICE candidates using a proxy 287 5. Requirements 289 5.1. ICE candidates produced in the presence of a proxy 291 When a proxy is configured, by Auto-Discovery or a proprietary means, 292 the browser MUST NOT report a "relay" candidate representing the 293 proxy. Instead, for each active proxy, the browser MUST connect to 294 the proxy and then, if the connection is successful, treat the TURN 295 tunnel as a UDP-only virtual interface. 297 For a virtual interface representing a TURN proxy, this means that 298 the browser MUST report the public-facing IP address and port 299 acquired through TURN as a "host" candidate, the browser MUST perform 300 STUN through the TURN proxy (if STUN is configured), and it MUST 301 perform TURN by recursive encapsulation through the TURN proxy, 302 resulting in TURN candidates whose "raddr" and "rport" attributes 303 match the acquired public-facing IP address and port on the proxy. 305 Because the virtual interface has some additional overhead due to 306 indirection, it SHOULD have lower priority than the physical 307 interfaces if physical interfaces are also active. Specifically, 308 even host candidates generated by a virtual interface SHOULD have 309 priority 0 when physical interfaces are active (similar to [RFC5245] 310 Section 4.1.2.2, "the local preference for host candidates from a VPN 311 interface SHOULD have a priority of 0"). 313 5.2. Leaky proxy configuration 315 If the active proxy for an application is leaky, the browser should 316 undertake the standard ICE candidate discovery mechanism [RFC5245] on 317 the available physical and virtual interfaces. 319 5.3. Sealed proxy configuration 321 If the active proxy for an application is sealed, the browser MUST 322 NOT gather or produce any candidates on physical interfaces. The 323 WebRTC implementation MUST direct its traffic from those interfaces 324 only to the proxy, and perform ICE candidate discovery only on the 325 single virtual interface representing the active proxy. 327 5.4. Proxy rank 329 Any browser mechanism for specifying a proxy SHOULD allow the caller 330 to indicate a higher rank than the proxy provided by Auto-Discovery 331 [I-D.ietf-tram-turn-server-discovery]. 333 5.5. Multiple physical interfaces 335 Some operating systems allow the browser to use multiple interfaces 336 to contact a single remote IP address. To avoid producing an 337 excessive number of candidates, WebRTC endpoints MUST NOT use 338 multiple physical interfaces to connect to a single proxy 339 simultaneously. (If this were violated, it could produce a number of 340 virtual interfaces equal to the product of the number of physical 341 interfaces and the number of active proxies.) 343 For strategies to choose the best interface for communication with a 344 proxy, see [I-D.reddy-mmusic-ice-best-interface-pcp]. Similar 345 considerations apply when connecting to an application-specified TURN 346 server in the presence of physical and virtual interfaces. 348 5.6. Unspecified leakiness 350 If a proxy configuration mechanism does not specify leakiness, 351 browsers SHOULD treat the proxy as leaky. This is similar to current 352 WebRTC implementations' behavior in the presence of SOCKS and HTTP 353 proxies: the candidate allocation code continues to generate UDP 354 candidates that do not transit through the proxy. 356 5.7. Interaction with SOCKS5-UDP 358 The SOCKS5 proxy standard [RFC1928] permits compliant SOCKS proxies 359 to support UDP traffic. However, most implementations of SOCKS5 360 today do not support UDP. Accordingly, WebRTC browsers MUST by 361 default (i.e. unless deliberately configured otherwise) treat SOCKS5 362 proxies as leaky and having lower rank than any configured TURN 363 proxies. 365 5.8. Encapsulation overhead, fragmentation, and Path MTU 367 Encapsulating a link in TURN adds overhead on the path between the 368 client and the TURN server, because each packet must be wrapped in a 369 TURN message. This overhead is sometimes doubled in RETURN proxying. 370 To avoid excessive overhead, client implementations SHOULD use 371 ChannelBind and ChannelData messages to connect and send data through 372 proxies and application TURN servers when possible. Clients MAY 373 buffer messages to be sent until the ChannelBind command completes 374 (requiring one round trip to the proxy), or they MAY use 375 CreatePermission and Send messages for the first few packets to 376 reduce startup latency at the cost of higher overhead. 378 Adding overhead to packets on a link decreases the effective Maximum 379 Transmissible Unit on that link. Accordingly, clients that support 380 proxying MUST NOT rely on the effective MTU complying with the 381 Internet Protocol's minimum MTU requirement. 383 ChannelData messages have constant overheard, enabling consistent 384 effective PMTU, but Send messages do not necessarily have constant 385 overhead. TURN messages may be fragmented and reassembled if they 386 are not marked with the Don't Fragment (DF) IP bit or the DONT- 387 FRAGMENT TURN attribute. Client implementors should keep this in 388 mind, especially if they choose to implement PMTU discovery through 389 the proxy. 391 5.9. Interaction with alternate TURN server fallback 393 As per [RFC5766], a TURN server MAY respond to an Allocate request 394 with an error code of 300 and an ALTERNATE-SERVER indication. When 395 connecting to proxies or application TURN servers, clients SHOULD 396 attempt to connect to the specified alternate server in accordance 397 with [RFC5766]. The client MUST route a connection to the alternate 398 server through the proxy if and only if the original connection 399 attempt was routed through the proxy. 401 6. Examples 403 6.1. Firewalled enterprise network with a basic application 405 In this example, an enterprise network is configured with a firewall 406 that blocks all UDP traffic, and a TURN server is advertised for 407 Auto-Discovery in accordance with 408 [I-D.ietf-tram-turn-server-discovery]. The proxy leakiness of the 409 TURN server is unspecified, so the browser treats it as leaky. 411 The application specifies a STUN and TURN server on the public net. 412 In accordance with the ICE candidate gathering algorithm RFC 5245 413 [RFC5245], it receives a set of candidates like: 415 1. A host candidate acquired from one interface. 417 * e.g. candidate:1610808681 1 udp 2122194687 [internal ip addr 418 for interface 0] 63555 typ host generation 0 420 2. A host candidate acquired from a different interface. 422 * e.g. candidate:1610808681 1 udp 2122194687 [internal ip addr 423 for interface 1] 54253 typ host generation 0 425 3. The proxy, as a host candidate. 427 * e.g. candidate:3458234523 1 udp 24584191 [public ip addr for 428 the proxy] 54606 typ host generation 0 430 4. The virtual interface also generates a STUN candidate, but it is 431 eliminated because it is redundant with the host candidate, as 432 noted in [RFC5245] Sec 4.1.2.. 434 5. The application-provided TURN server as seen through the virtual 435 interface. (Traffic through this candidate is recursively 436 encapsulated.) 438 * e.g. candidate:702786350 1 udp 24583935 [public ip addr of the 439 application TURN server] 52631 typ relay raddr [public ip addr 440 for the proxy] rport 54606 generation 0 442 There are no STUN or TURN candidates on the physical interfaces, 443 because the application-specified STUN and TURN servers are not 444 reachable through the firewall. 446 If the remote peer is within the same network, it may be possible to 447 establish a direct connection using both peers' host candidates. If 448 the network prevents this kind of direct connection, the path will 449 instead take a "hairpin" route through the enterprise's proxy, using 450 one peer's physical "host" candidate and the other's virtual "host" 451 candidate, or (if that is also disallowed by the network 452 configuration) a "double hairpin" using both endpoints' virtual 453 "host" candidates. 455 6.2. Conflicting proxies configured by Auto-Discovery and local policy 457 Consider an enterprise network with TURN and HTTP proxies advertised 458 for Auto-Discovery with unspecified leakiness (thus defaulting to 459 leaky). The browser endpoint configures an additional TURN proxy by 460 a proprietary local mechanism. 462 If the locally configured proxy is leaky, then the browser MUST 463 produce candidates representing any physical interfaces (including 464 SSLTCP routes through the HTTP proxy), plus candidates for both UDP- 465 only virtual interfaces created by the two TURN servers. 467 There MUST NOT be any candidate that uses both proxies. Multiple 468 configured proxies are not chained recursively. 470 If the locally configured proxy is "sealed", then the browser MUST 471 produce only candidates from the virtual interface associated with 472 that proxy. 474 If both proxies are configured for "sealed" use, then the browser 475 MUST produce only candidates from the virtual interface associated 476 with the proxy with higher rank. 478 7. Security Considerations 480 This document describes web browser behaviors that, if implemented 481 correctly, allow users to achieve greater identity-confidentiality 482 during WebRTC calls under certain configurations. 484 If a site administrator offers the site's users a TURN proxy, 485 websites running in the users' browsers will be able to initiate a 486 UDP-based WebRTC connection to any UDP transport address via the 487 proxy. Websites' connections will quickly terminate if the remote 488 endpoint does not reply with a positive indication of ICE consent, 489 but no such restriction applies to other applications that access the 490 TURN server. Administrators should take care to provide TURN access 491 credentials only to the users who are authorized to have global UDP 492 network access. 494 TURN proxies and application TURN servers can provide some privacy 495 protection by obscuring the identity of one peer from the other. 496 However, unencrypted TURN provides no additional privacy from an 497 observer who can monitor the link between the TURN client and server, 498 and even encrypted TURN ([I-D.ietf-tram-stun-dtls] Section 4.6) does 499 not provide significant privacy from an observer who sniff traffic on 500 both legs of the TURN connection, due to packet timing correlations. 502 8. IANA Considerations 504 This document requires no actions from IANA. 506 9. Acknowledgements 508 Significant review, including the virtual-interface formulation, was 509 provided by Justin Uberti. Thanks to Harald Alvestrand, Phillip 510 Hancke, and Tirumaleswar Reddy for suggestions to improve the content 511 and presentation. 513 10. References 515 10.1. Normative References 517 [I-D.ietf-rtcweb-jsep] 518 Uberti, J. and C. Jennings, "Javascript Session 519 Establishment Protocol", draft-ietf-rtcweb-jsep-06 (work 520 in progress), February 2014. 522 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 523 L. Jones, "SOCKS Protocol Version 5", RFC 5766, March 524 1996. 526 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 527 (ICE): A Protocol for Network Address Translator (NAT) 528 Traversal for Offer/Answer Protocols", RFC 5245, April 529 2010. 531 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 532 Relays around NAT (TURN): Relay Extensions to Session 533 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 535 10.2. Informative References 537 [I-D.ietf-rtcweb-security] 538 Rescorla, E., "Security Considerations for WebRTC", ietf- 539 rtcweb-security-07 (work in progress), July 2014. 541 [I-D.ietf-rtcweb-use-cases-and-requirements] 542 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 543 Time Communication Use-cases and Requirements", ietf- 544 rtcweb-use-cases-and-requirements-14 (work in progress), 545 February 2014. 547 [I-D.ietf-tram-stun-dtls] 548 Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport 549 Layer Security (DTLS) as Transport for Session Traversal 550 Utilities for NAT (STUN)", ietf-rtcweb-use-cases-and- 551 requirements-14 (work in progress), June 2014. 553 [I-D.ietf-tram-turn-server-discovery] 554 Patil, P., Reddy, T., and D. Wing, "TURN Server Auto 555 Discovery", draft-ietf-tram-turn-server-discovery-00 (work 556 in progress), July 2014. 558 [I-D.reddy-mmusic-ice-best-interface-pcp] 559 Reddy, T., Wing, D., VerSteeg, B., Penno, R., and V. 560 Singh, "Improving ICE Interface Selection Using Port 561 Control Protocol (PCP) Flow Extension", draft-ietf-tram- 562 turn-server-discovery-00 (work in progress), October 2013. 564 Author's Address 566 Benjamin M. Schwartz 567 Google 568 747 6th Ave S 569 Kirkland, WA 98033 570 USA 572 Email: bemasc@webrtc.org