idnits 2.17.1 draft-hutton-rtcweb-nat-firewall-considerations-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 20, 2014) is 3747 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Stach 3 Internet-Draft A. Hutton 4 Intended status: Informational Unify 5 Expires: July 24, 2014 J. Uberti 6 Google 7 January 20, 2014 9 RTCWEB Considerations for NATs, Firewalls and HTTP proxies 10 draft-hutton-rtcweb-nat-firewall-considerations-03 12 Abstract 14 This document describes mechanism to enable media stream 15 establishment for Real-Time Communication in WEB-browsers (WebRTC) in 16 the presence of network address translators, firewalls and HTTP 17 proxies. HTTP proxy and firewall deployed in many private network 18 domains introduce obstacles to the successful establishment of media 19 stream via WebRTC. This document examines some of these deployment 20 scenarios and specifies requirements on WebRTC enabled web browsers 21 designed to provide the best possible chance of media connectivity 22 between WebRTC peers. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 24, 2014. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 60 2. Considerations for NATs/Firewalls independent of HTTP proxies 4 61 2.1. NAT/Firewall open for outgoing UDP and TCP traffic . . . 4 62 2.2. NAT/Firewall open only for TCP traffic . . . . . . . . . 4 63 2.3. NAT/Firewall open only for TCP on restricted ports . . . 5 64 3. Considerations for NATs/Firewalls in presence of HTTP proxies 6 65 3.1. HTTP proxy with NAT/Firewall open for 66 outgoing UDP and TCP traffic . . . . . . . . . . . . . . 6 67 3.2. HTTP proxy with NAT/Firewall open only for TCP traffic . 6 68 3.3. HTTP proxy with NAT/Firewall open only to proxy routed 69 traffic . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4. Solutions for Further Study . . . . . . . . . . . . . . . . . 7 71 4.1. HTTP CONNECT based mechanism . . . . . . . . . . . . . . 7 72 4.2. ALPN - Use of Application Layer Protocol Negotiation . . 8 73 4.3. TURN server connection via WebSocket . . . . . . . . . . 9 74 4.4. HTTP Fallback for RTP Media Streams . . . . . . . . . . . 9 75 4.5. Port Control Protocol . . . . . . . . . . . . . . . . . . 9 76 4.6. Network Specific TURN Server . . . . . . . . . . . . . . 9 77 5. Requirements for RTCWEB-enabled browsers . . . . . . . . . . 10 78 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 83 9.2. Informative References . . . . . . . . . . . . . . . . . 12 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 WebRTC is a web-based technique for direct interactive rich 89 communication using audio, video, and data between two peer browsers. 91 Many organizations, e.g. an enterprise, a public service agency or a 92 university, deploy Network Address Translators (NAT) and firewalls 93 (FW) at the border to the public internet. WebRTC relies on ICE 94 [RFC5245] in order to establish a media path between two WebRTC peers 95 in the presence of such NATs/FWs. 97 When WebRTC is deployed by the corporate IT department one can assume 98 that the corporate IT configures the corporate NATs, Firewalls, DPI 99 units, TURN servers accordingly. If so desired by the organization 100 WebRTC media streams can then be established to WebRTC peers outside 101 of the organization subject to the applied policies. In order to 102 cater for NAT/FWs with address and port dependent mapping 103 characteristics [RFC4787], the peers will introduce a TURN server 104 [RFC5766] in the public internet as a media relay. Such a TURN 105 server could be deployed by the organization wanting to assert policy 106 on WebRTC traffic. 108 However, there are also environments that are not prepared for WebRTC 109 and have NAT/FW deployed that prevent media stream establishment 110 although such blocking is not intentional. These environments 111 include e.g. internet cafes or hotels offering their customers access 112 to the web and have opened the well-known HTTP(S) ports but nothing 113 else. In such an environment ICE will fail to establish 114 connectivity. Re-configuration of the NAT/FW is also often 115 impracticable or not possible. 117 In such an environment a WebRTC user may easily reach its WebRTC 118 server possibly via an HTTP proxy and start establishing a WebRTC 119 session, but will become frustrated when a media connection cannot be 120 established. A corresponding use case and its requirements relating 121 to WebRTC NAT/FW traversal can be found in 122 [draft-ietf-rtcweb-use-cases-and-requirements]. 124 The TURN server in the public internet is not sufficient to establish 125 connectivity for RTP-based media [RFC3550] and the WebRTC data 126 channel [draft-ietf-rtcweb-data-channel] towards external WebRTC 127 peers since the FW policies include blocking of all UDP based traffic 128 and allowing only traffic to the TCP ports 80/443 with the intent to 129 support HTTP(S) [RFC2616]. 131 We explicitly don't address even more restricted environments, that 132 deploy HTTP traffic validation. This could e.g. be done by means of 133 DPI validation or traffic pattern analysis to determine the contents 134 of the packets that the traffic is, in fact, HTTP or HTTPS-looking or 135 by an HTTP proxy that breaks into the TLS exchange and looks for HTTP 136 in the traffic. However we want to address the case when access to 137 the World Wide Web from inside an organization is only possible via a 138 transparent HTTP Proxy that just tunnels traffic after e.g. enforcing 139 an acceptable use policy. 141 This document examines impact of NAT/FW policies in Section 2. 142 Additional impacts due to the presence of a HTTP proxy are examined 143 in Section 3. 145 1.1. Requirements Language 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 2. Considerations for NATs/Firewalls independent of HTTP proxies 153 This section covers aspects of how NAT/FW characteristic influence 154 the establishment of a media stream. Additional aspects introduced 155 by the presence of a HTTP proxy are covered in Section 3. 157 If the NATs serving caller and callee both show port and address 158 dependent mapping behavior the need for a TURN server arises in order 159 to establish connectivity for media streams. The TURN server will 160 relay the RTP packet to the WebRTC peer using UDP. How the RTP 161 packets can be transported from the WebRTC client within the private 162 network to the TURN server depends on what the firewall will let pass 163 through. 165 Other types of NATs do not require using the TURN relay. 166 Nevertheless, the FW rules and policies still affect how media 167 streams can be established. 169 2.1. NAT/Firewall open for outgoing UDP and TCP traffic 171 This scenario assumes that the NAT/FW is transparent for all outgoing 172 traffic independent of using UDP or TCP as the transport protocol. 173 This case is used as starting point for introduction of more 174 restrictive firewall policies. It presents the least critical 175 example with respect to the establishment of the media streams. 177 The TURN server can be reached directly from within the private 178 network via the NAT/FW and the ICE procedures will reveal that media 179 can be sent via the TURN server. The TURN client will send its media 180 to the allocated resources at the TURN server via UDP. 182 Dependent on the port range that is used for WebRTC media streams, 183 the same statement would be true if the NAT/Firewall would allow UDP 184 traffic for a restricted UDP port range only. 186 2.2. NAT/Firewall open only for TCP traffic 188 This scenario assumes that the NAT/FW is transparent for outgoing 189 traffic only using TCP as transport protocol. Theoretically, this 190 gives two options for media stream establishment dependent on the 191 NAT's mapping characteristics. Either transporting RTP over TCP 192 directly to the peer or contacting a TURN server via TCP that then 193 relays RTP. 195 In the first case the browser does not use any TURN server to get 196 through its NAT/FW. However, the browser needs to use ICE-TCP 197 [RFC6544] and provide active, passive and/or simultaneous-open TCP 198 candidates. Assuming the peer also provides TCP candidates, a 199 connectivity check for a TCP connection between the two peers should 200 be successful. 202 In the second case the browser contacts the TURN server via TCP for 203 allocation of an UDP-based relay address at the TURN server. The ICE 204 procedures will reveal that RTP media can be sent via the TURN relay 205 using the TCP connection between TURN client and TURN server. The 206 TURN server would then relay the RTP packets using UDP, as well as 207 other UDP-based protocols. ICE-TCP is not needed in this context. 209 Note that the second case is not to be confused with using TURN to 210 request a "TCP Allocation" as described in [RFC6062], which deals 211 with how to establish a TCP connection from a TURN server to the 212 peer. For this document we assume that the TURN server can reach the 213 peer always via UDP, possibly via a second TURN server, in case the 214 WebRTC peer is located in a similar environment as described in this 215 section. 217 We don't see a need to request TCP allocations at the TURN server 218 since it is preferable that WebRTC media is transported over UDP as 219 far as possible. For the same reason we also prefer using TCP just 220 as transport to the TURN server over using the ICE-TCP with an end- 221 to-end TCP connection 223 2.3. NAT/Firewall open only for TCP on restricted ports 225 In this case the firewall blocks all outgoing traffic except for TCP 226 traffic to specific ports, for example port 80 (HTTP) for HTTP or 443 227 for HTTPS(HTTPS). A TURN server listening to its default ports (3478 228 for TCP/UDP, 5349 for TLS) would not be reachable in this case. 229 However, the TURN server can still be reached when it is configured 230 to listen to e.g. the HTTP(S) ports. 232 In addition the browser needs to be configured to contact the TURN 233 server over the HTTP(S) ports and/or the WebRTC client has to provide 234 this information to browser. 236 3. Considerations for NATs/Firewalls in presence of HTTP proxies 238 This section considers a scenario where all HTTP(S) traffic is routed 239 via an HTTP proxy. We assume that the HTTP proxy is tranparent and 240 just tunnels traffic after e.g. enforcing an acceptable use policy 241 with respect to domains that are allowed to be reached. We don't 242 consider cases where the HTTP proxy is used to deploy HTTP traffic 243 validation. This includes DPI validation that the traffic is, in 244 fact, HTTP or HTTPS-looking or a HTTP proxy that breaks into the TLS 245 exchange and looks for HTTP in the traffic. 247 Note: If both WebRTC clients are located behind the same HTTP proxy, 248 we, of course, assume that ICE would give us a direct media 249 connection within the private network. We don't consider this case 250 in detail within this document. 252 3.1. HTTP proxy with NAT/Firewall open for outgoing UDP and TCP traffic 254 As in Section 2.1 we assume that the NAT/FW is transparent for all 255 outgoing traffic independent of using UDP or TCP as transport 256 protocol. The HTTP proxy has no impact on the transport of media 257 streams in this case. Consequently, the same considerations as in 258 Section 2.1 apply with respect to the traversal of the NAT/FW. 260 3.2. HTTP proxy with NAT/Firewall open only for TCP traffic 262 As in Section 2.2 we assume that the NAT/FW is transparent only for 263 outgoing TCP traffic. The HTTP proxy has no impact on the transport 264 of media streams in this case. Consequently, the same considerations 265 as in Section 2.2 apply with respect to the traversal of the NAT/FW. 267 3.3. HTTP proxy with NAT/Firewall open only to proxy routed traffic 269 Different from the previous scenarios, we assume that the NAT/FW 270 accepts outgoing traffic only via a TCP connection that is initiated 271 from the HTTP proxy. Currently only the case of an explicit proxy is 272 considered here. 274 This scenario is the most complex and controversial as it requires 275 the WebRTC media to be tunneled through the proxy. However such 276 techniques are already specified in RFC's and deployed an example of 277 this is websockets [RFC6455] which uses the HTTP CONNECT mechanism in 278 the presense of HTTP Proxies. 280 This document discusses some alternative approaches to achieving 281 connectivity for WebRTC media in this environment but does not 282 currently make any firm recommendations as the alternatives are 283 mostly work in progress in other areas of the IETF. Therefore it is 284 not possible to make such a recommendation at this time. 286 4. Solutions for Further Study 288 The following sections outline and provide some analysis of various 289 solutions to the issues raised regarding WebRTC media traversing 290 firewalls and proxies. All of these potential solutions require 291 further analysis by the IETF RTCWEB working group and in some cases 292 may require work in other IETF working groups. 294 It is possible that due to different network environments that WebRTC 295 browsers may need to implement more than one solution. 297 NOTE - THIS ANALYSIS IS NOT COMPLETE. 299 4.1. HTTP CONNECT based mechanism 301 A WebRTC browser could make use of the HTTP CONNECT method [RFC2817] 302 and request that the HTTP proxy establishes a tunnel connection on 303 its behalf in order to get access to the TURN server. The HTTP 304 CONNECT request needs to convey the TURN Server URI or transport 305 address. As a result the HTTP Proxy will establish a TCP connection 306 to the TURN server and when successful the HTTP Proxy will answer the 307 HTTP CONNECT request with a 200OK response. In case of a transparent 308 proxy, the HTTP proxy will now switch into tunneling mode and will 309 transparently relay the traffic to the TURN server. 311 By using the HTTP CONNECT method, the TURN server only has to handle 312 a standard TCP connection. An update to the TURN protocol or the 313 TURN software is not needed. 315 Afterwards, the browser could upgrade the connection to use TLS, 316 forward STUN/TURN traffic via the HTTP proxy and use the TURN server 317 as media relay. Note that upgrading in this case is not to be 318 misunderstood as usage of the HTTP UPGRADE method as specified in 319 [RFC2817] as this would require the TURN server to support HTTP. The 320 following is a possible sequence of events: 322 o the browser opens a TCP connection to the HTTP proxy, 324 o the browser issues a HTTP CONNECT request to the HTTP proxy with 325 the TURN server address in the Request URI, for example 327 * CONNECT turn_server.example.com:5349 HTTP/1.1 Host: 328 turn_server.example.com:5349 330 o the HTTP proxy opens a TCP connection to the TURN server and 331 "bridges" the incoming and outgoing TCP connections together, 332 forming a virtual end-to-end TCP connection, 334 o the browser can do a TLS handshake over the virtual end-to-end TCP 335 connection with the TURN server. 337 Strictly speaking the TLS upgrade is not necessary, but using TLS 338 would also prevent the HTTP proxy from sniffing into the data stream 339 and provides the same flow as HTTPS and might improve 340 interoperability with proxy servers. The WebRTC application has the 341 ability to control whether TLS is used by the parameters it supplies 342 to the TURN URI (e.g. turns: vs. turn:), so the decision to access 343 the TURN server via TCP versus TLS could be left up to the 344 application or possibly the browser configuration script. 346 In contrast to using UDP or TCP for transporting the STUN messages, 347 the browser would now need to first establish a HTTP over TCP 348 connection to the HTTP proxy, upgrade to using TLS and then switch to 349 using this TLS connection for transport of STUN messages. 351 Further considerations apply to the default connection timeout of the 352 HTTP proxy connection to the TURN server and the timeout of the TURN 353 server allocation. Whereas [RFC5766] specifies a 10 minutes default 354 lifetime of the TURN allocation, typical proxy connection lifetimes 355 are in the range of 60 seconds if no activity is detected. Thus, if 356 the WebRTC client wants to pre-allocate TURN ressources it needs to 357 refresh TURN allocations more frequently in order to keep the TCP 358 connection to its TURN server alive. 360 4.2. ALPN - Use of Application Layer Protocol Negotiation 362 The application layer protocol negotiation (ALPN) 363 [draft-ietf-tls-applayerprotoneg] specifies a TLS extension which 364 permits the application layer to negotiate protocol selection within 365 the TLS handshake. This provides an explicit and visable indication 366 of the application layer protocol associated with the TLS connection 367 allowing the application protocol to be visable without relying on 368 the port number to identify the protocol. 370 [draft-ietf-tls-applayerprotoneg] could therefore be used to identify 371 that it is WebRTC media that is contained within the TLS connection. 373 ALPN is effectively an extension to the HTTP CONNECT mechanism 374 decribed in Section 4.1 since the establishment of the TLS connection 375 would require the use of this mechanism in the presence of a proxy as 376 described in [draft-ietf-httpbis-http2]. 378 4.3. TURN server connection via WebSocket 380 The WebRTC client could connect to a TURN server via WebSocket 381 [RFC6455] as described in [draft-chenxin-behave-turn-WebSocket]. 382 This might have benefits in very restrictive environments where HTTPS 383 is not permitted through the proxy. However, such environments are 384 also likely to deploy DPI boxes which would eventually complain 385 against usage of WebSocket or block WebRTC traffic based on other 386 heuristic means. It is also to be expected that an environment that 387 does not allow HTTPS will also forbid usage of WebSocket over TLS. 389 In addition, usage of TURN over WebSocket puts an additional burden 390 on existing TURN server implementation to support HTTP and WebSocket. 392 This is again effectively an extension to the HTTP CONNECT mechanism 393 decribed in Section 4.1 since the establishment of the webcoskets 394 connection would require the use of this mechanism in the presence of 395 a proxy as described in [draft-ietf-httpbis-http2]. Like the ALPN 396 approach the websockets approach also includes that the purpose of 397 the websockets connection is to transport WebRTC media. 399 4.4. HTTP Fallback for RTP Media Streams 401 As an alternative to using a TURN server 402 [draft-miniero-rtcweb-http-fallback] proposed to send RTP directly 403 over HTTP. This approach bears some similarities with TURN as it 404 also uses a RTP relay. However, it uses HTTP GET and POST requests 405 to receive and send RTP packets. 407 Despite a number of open issues, the proposal addreses some corner 408 cases. However, the expected benefit in form of an increased success 409 rate for establishment of a media stream seems rather small. 411 4.5. Port Control Protocol 413 As a further alternative, the Port Control Protocol (PCP) [RFC6887] 414 allows the client to communicate with the NAT/FW and negotiate how 415 incoming IPv6 or IPv4 packets are translated and forwarded. However, 416 to be successful such a solution would require the widespread 417 deployment and use of PCP enabled firewalls so this does not appear 418 to be a workable solution at least for early deployments of WebRTC. 420 4.6. Network Specific TURN Server 422 If a network specific TURN server under administrative control of the 423 organization is deployed it is desirable to reach this TURN server 424 via UDP. The TURN server could be specified in the proxy 425 configuration script, giving the browser the possibility to learn how 426 to access it. Then, when gathering candidates, this TURN server 427 would always be used such that the WebRTC client application could 428 get UDP traffic out to the internet. 430 Since the TURN server is under the same administrative control as the 431 NAT/FW then it can be assumed that the NAT/FW allows WebRTC media 432 that traverses the TURN server to traverse the NAT/FW. 434 The implementation of this solution in WebRTC is actually a 435 requirement specified in 436 [draft-ietf-rtcweb-use-cases-and-requirements]. 438 The implementation of this solution in WebRTC does not remove the 439 need for other solutions for the case when there is no such network 440 specific TURN server. 442 5. Requirements for RTCWEB-enabled browsers 444 THIS SECTION IS EVEN MORE WORK IN PROGRESS THAN PREVIOUS SECTIONS. 446 For the purpose of relaying WebRTC media streams or data channels a 447 browser needs to be able to 449 o connect to a TURN server via UDP, TCP and TLS, 451 o support a mechanism for connecting to a TURN server in the 452 presence of a firewall that only permits connections that orginate 453 from a HTTP Proxy. The mechanism is for further study. 455 o connect to the TURN server via application specified ports other 456 than the default STUN ports including the HTTP(s) ports, 458 o use the same proxy selection procedure for TURN as currently done 459 for HTTP (e.g. Web Proxy Autodiscovery Protocol (WPAD) and .pac- 460 files for Proxy-Auto-Config), 462 o use a preconfigured or standardized port range for UDP-based media 463 streams or data channels, 465 o learn from the proxy configuration script about the presence of a 466 local TURN server and use it for sending UDP traffic to the 467 internet, 469 o as an option and if needed, support ICE-TCP for TCP-based direct 470 media connection to the WebRTC peer. 472 6. Acknowledgements 474 The authors want to thank Heinrich Haager for all his input during 475 many valuable discussions. 477 Furthermore, the authors want to thank for comments and suggestions 478 received from Bernard Aboba, Xavier Marjou, Dan Wing, ... 480 7. IANA Considerations 482 This memo includes no request to IANA. 484 8. Security Considerations 486 In case of using HTTP CONNECT to a TURN server the security 487 consideration of [[draft-ietf-httpbis-p2-semantics], Section-4.3.6] 488 apply. It states that there "are significant risks in establishing a 489 tunnel to arbitrary servers, particularly when the destination is a 490 well-known or reserved TCP port that is not intended for Web traffic. 491 ... Proxies that support CONNECT SHOULD restrict its use to a limited 492 set of known ports or a configurable whitelist of safe request 493 targets." 495 Consequently when HTTP CONNECT is used to reach a TURN server, the 496 proxy administrator SHOULD configure a whitelist of trusted TURN 497 servers and/or a blacklist of TURN server known to be subject to 498 fraud or other undesired behavior. 500 With respect to the other discussed alternatives the security 501 considerations of the corresponding RFCs and Internet Drafts apply. 503 9. References 505 9.1. Normative References 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, March 1997. 510 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 511 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 512 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 514 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/ 515 1.1", RFC 2817, May 2000. 517 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 518 Jacobson, "RTP: A Transport Protocol for Real-Time 519 Applications", STD 64, RFC 3550, July 2003. 521 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 522 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 523 RFC 4787, January 2007. 525 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 526 (ICE): A Protocol for Network Address Translator (NAT) 527 Traversal for Offer/Answer Protocols", RFC 5245, April 528 2010. 530 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 531 Relays around NAT (TURN): Relay Extensions to Session 532 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 534 9.2. Informative References 536 [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays 537 around NAT (TURN) Extensions for TCP Allocations", RFC 538 6062, November 2010. 540 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 541 6455, December 2011. 543 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 544 "TCP Candidates with Interactive Connectivity 545 Establishment (ICE)", RFC 6544, March 2012. 547 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 548 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 549 2013. 551 [draft-chenxin-behave-turn-WebSocket] 552 Xin. Chen, "Traversal Using Relays around NAT (TURN) 553 Extensions for WebSocket Allocations", 2013, 554 . 557 [draft-ietf-httpbis-http2] 558 M. Belshe, R. Peon, M. Thomson, A. Melnikov, "Hypertext 559 Transfer Protocol version 2.0", 2013, 560 . 563 [draft-ietf-httpbis-p2-semantics] 564 R. Fielding, J. Reschke, "Hypertext Transfer Protocol 565 (HTTP/1.1): Semantics and Content", 2013, 566 . 569 [draft-ietf-rtcweb-data-channel] 570 R. Jesup, S. Loreto, M. Tuexen, "RTCWeb Data Channels", 571 2013, . 574 [draft-ietf-rtcweb-use-cases-and-requirements] 575 C. Holmberg, S. Hakansson, G. Eriksson, "Web Real-Time 576 Communication Use-cases and Requirements", 2013, 577 . 580 [draft-ietf-tls-applayerprotoneg] 581 S. Friedl, A. Popov, A. Langley, E. Stephan, "Transport 582 Layer Security (TLS) Application Layer Protocol 583 Negotiation Extension", 2013, . 586 [draft-miniero-rtcweb-http-fallback] 587 L. Miniero, "HTTP Fallback for RTP Media Streams", 2012, 588 . 591 Authors' Addresses 593 Thomas Stach 594 Unify 595 Dietrichgasse 27-29 596 Vienna 1030 597 AT 599 Email: thomas.stach@unify.com 601 Andrew Hutton 602 Unify 603 Technology Drive 604 Nottingham NG9 1LA 605 UK 607 Email: andrew.hutton@unify.com 608 Justin Uberti 609 Google 610 747 6th Ave S 611 Kirkland, WA 98033 612 US 614 Email: justin@uberti.name