Internet Engineering Task Force T. Stach, Ed. Internet-Draft A. Hutton Intended status: Informational Siemens Enterprise Communications Expires: March 24, 2014 J. Uberti Google September 20, 2013 RTCWEB Considerations for NATs, Firewalls and HTTP proxies draft-hutton-rtcweb-nat-firewall-considerations-02 Abstract This document describes mechanism to enable media stream establishment for Real-Time Communication in WEB-browsers (WebRTC) in the presence of network address translators, firewalls and HTTP proxies. HTTP proxy and firewall deployed in many private network domains introduce obstacles to the successful establishment of media stream via WebRTC. This document examines some of these deployment scenarios and develops requirements on the web browsers designed to provide the best possible chance of media connectivity between WebRTC peers. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 24, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Stach, et al. Expires March 24, 2014 [Page 1] Internet-Draft RTCWEB NAT-FW September 2013 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Considerations for NATs/Firewalls independent of HTTP proxies 4 2.1. NAT/Firewall open for outgoing UDP and TCP traffic . . . 4 2.2. NAT/Firewall open only for TCP traffic . . . . . . . . . 4 2.3. NAT/Firewall open only for TCP on restricted ports . . . 5 3. Considerations for NATs/Firewalls in presence of HTTP proxies 6 3.1. HTTP proxy with NAT/Firewall open for outgoing UDP and TCP traffic . . . . . . . . . . . . . . 6 3.2. HTTP proxy with NAT/Firewall open only for TCP traffic . 6 3.3. HTTP proxy assisted TURN server connection . . . . . . . 6 3.3.1. TURN server connection via TCP . . . . . . . . . . . 6 3.3.2. TURN server connection via UDP . . . . . . . . . . . 8 4. Other Approaches . . . . . . . . . . . . . . . . . . . . . . 8 4.1. TURN server connection via WebSocket . . . . . . . . . . 8 4.2. Port Control Protocol . . . . . . . . . . . . . . . . . . 9 4.3. HTTP Fallback for RTP Media Streams . . . . . . . . . . . 9 5. Requirements for RTCWEB-enabled browsers . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction WebRTC is a web-based technique for direct interactive rich communication using audio, video, and data between two peer browsers. Many organizations, e.g. an enterprise, a public service agency or a university, deploy Network Address Translators (NAT) and firewalls (FW) at the border to the public internet. WebRTC relies on ICE [RFC5245] in order to establish a media path between two WebRTC peers in the presence of such NATs/FWs. When WebRTC is deployed by the corporate IT department one can assume that the corporate IT configures the corporate NATs, Firewalls, DPI Stach, et al. Expires March 24, 2014 [Page 2] Internet-Draft RTCWEB NAT-FW September 2013 units, TURN servers accordingly. If so desired by the organization WebRTC media streams can then be established to WebRTC peers outside of the organization subject to the applied policies. In order to cater for NAT/FWs with address and port dependent mapping characteristics [RFC4787], the peers will introduce a TURN server [RFC5766] in the public internet as a media relay. Such a TURN server could be deployed by the organization wanting to assert policy on WebRTC traffic. However, there are also environments that are not prepared for WebRTC and have NAT/FW deployed that prevent the media stream establishment although such blocking is not intentional. These environments include e.g. internet cafes or hotels offering their customers access to the web and have opened the well-known HTTP(S) ports but nothing else. In such an environment ICE will fail to establish connectivity. Re-configuration of the NAT/FW is also often impracticable or not possible. In such an environment a WebRTC user may easily reach its WebRTC server possibly via an HTTP proxy and start establishing a WEBTRTC session, but will become frustrated when a media connection cannot be established. A corresponding use case and its requirements relating to WebRTC NAT/FW traversal can be found in [draft-ietf-rtcweb-use-cases-and-requirements]. The TURN server in the public internet is not sufficient to establish connectivity for RTP-based media [RFC3550] and the WebRTC data channel [draft-ietf-rtcweb-data-channel] towards external WebRTC peers since the FW policies include blocking of all UDP based traffic and allowing only traffic to the TCP ports 80/443 with the intent to support HTTP(S) [RFC2616]. We explicitly don't address even more restricted environments, that deploy HTTP traffic validation. This could e.g. be done by means of DPI validation or traffic pattern analysis to determine the contents of the packets that the traffic is, in fact, HTTP or HTTPS-looking or by an HTTP proxy that breaks into the TLS exchange and looks for HTTP in the traffic. However we want to address the case when access to the World Wide Web from inside an organization is only possible via a transparent HTTP Proxy that just tunnels traffic after e.g. enforcing an acceptable use policy. This document examines impact of NAT/FW policies in Section 2. Additional impacts due to the presence of a HTTP proxy are examined in Section 3. 1.1. Requirements Language Stach, et al. Expires March 24, 2014 [Page 3] Internet-Draft RTCWEB NAT-FW September 2013 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Considerations for NATs/Firewalls independent of HTTP proxies This section covers aspects of how NAT/FW characteristic influence the establishment of a media stream. Additional aspects introduced by the presence of a HTTP proxy are covered in Section 3. If the NATs serving caller and callee both show port and address dependent mapping behavior the need for a TURN server arises in order to establish connectivity for media streams. The TURN server will relay the RTP packet to the WebRTC peer using UDP. How the RTP packets can be transported from the WebRTC client within the private network to the TURN server depends on what the firewall will let pass through. Other types of NATs do not require using the TURN relay. Nevertheless, the FW rules and policies still affect how media streams can be established. 2.1. NAT/Firewall open for outgoing UDP and TCP traffic This scenario assumes that the NAT/FW is transparent for all outgoing traffic independent of using UDP or TCP as transport protocol. This case is used as starting point for introduction of more restrictive firewall policies. It presents the least critical example with respect to the establishment of the media streams. The TURN server can be reached directly from within the private network via the NAT/FW and the ICE procedures will reveal that media can be sent via the TURN server. The TURN client will send its media to the allocated resources at the TURN server via UDP. Dependent on the port range that is used for WebRTC media streams, the same statement would be true if the NAT/Firewall would allow UDP traffic for a restricted UDP port range only. 2.2. NAT/Firewall open only for TCP traffic This scenario assumes that the NAT/FW is transparent for outgoing traffic only using TCP as transport protocol. Theoretically, this gives two options for media stream establishment dependent on the NAT's mapping characteristics. Either transporting RTP over TCP directly to the peer or contacting a TURN server via TCP that then relays RTP. Stach, et al. Expires March 24, 2014 [Page 4] Internet-Draft RTCWEB NAT-FW September 2013 In the first case the browser does not use any TURN server to get through its NAT/FW. However, the browser needs to use ICE-TCP [RFC6544] and provide active, passive and/or simultaneous-open TCP candidates. Assuming the peer also provides TCP candidates, a connectivity check for a TCP connection between the two peers should be successful. In the second case the browser contacts the TURN server via TCP for allocation of an UDP-based relay address at the TURN server. The ICE procedures will reveal that RTP media can be sent via the TURN relay using the TCP connection between TURN client and TURN server. The TURN server would then relay the RTP packets using UDP, as well as other UDP-based protocols. ICE-TCP is not needed in this context. Note that the second case is not to be confused with TURN/TCP [RFC6062], which deals with how to establish a TCP connection from a TURN server to the peer. For this document we assume that the TURN server can reach the peer always via UDP, possibly via a second TURN server, in case the WebRTC peer is located in a similar environment as described in this section. We don't see a need to support TURN/TCP since all WebRTC media is transported over UDP. For the same reason we also prefer using TCP just as transport to the TURN server over using the ICE-TCP with an end-to-end TCP connection 2.3. NAT/Firewall open only for TCP on restricted ports In this case the firewall blocks all outgoing traffic except for TCP traffic to specific ports, for example port 80 (HTTP) for HTTP or 443 for HTTPS(HTTPS). A TURN server listening to its default ports (3478 for TCP/UDP, 5349 for TLS) would not be reachable in this case. However, the TURN server can still be reached when it is configured to listen to e.g. the HTTP(S) ports. Open issue: Although [draft-ietf-rtcweb-use-cases-and-requirements] considers only a restriction to HTTP(S) similar consideration apply to other ports or port ranges. A change to req F37 to "The browser must be able to send streams and data to a peer in the presence of FWs that only allows traffic via a HTTP Proxy." has been agreed and will be in the next update does this solve the issue. In addition the browser needs to be configured to contact the TURN server over the HTTP(S) ports and/or the WebRTC client has to tell the browser accordingly. Stach, et al. Expires March 24, 2014 [Page 5] Internet-Draft RTCWEB NAT-FW September 2013 3. Considerations for NATs/Firewalls in presence of HTTP proxies This section considers a scenario where all HTTP(S) traffic is routed via an HTTP proxy. We assume that the HTTP proxy is tranparent and just tunnels traffic after e.g. enforcing an acceptable use policy with respect to domains that are allowed to be reached. We don't consider cases where the HTTP proxy is used to deploy HTTP traffic validation. This includes DPI validation that the traffic is, in fact, HTTP or HTTPS-looking or a HTTP proxy that breaks into the TLS exchange and looks for HTTP in the traffic. Note: If both WebRTC clients are located behind the same HTTP proxy, we, of course, assume that ICE would give us a direct media connection within the private network. We don't consider this case in detail within this document. 3.1. HTTP proxy with NAT/Firewall open for outgoing UDP and TCP traffic As in Section 2.1 we assume that the NAT/FW is transparent for all outgoing traffic independent of using UDP or TCP as transport protocol. The HTTP proxy has no impact on the transport of media streams in this case. Consequently, the same considerations as in Section 2.1 apply with respect to the traversal of the NAT/FW. 3.2. HTTP proxy with NAT/Firewall open only for TCP traffic As in Section 2.2 we assume that the NAT/FW is transparent only for outgoing TCP traffic. The HTTP proxy has no impact on the transport of media streams in this case. Consequently, the same considerations as in Section 2.2 apply with respect to the traversal of the NAT/FW. 3.3. HTTP proxy assisted TURN server connection 3.3.1. TURN server connection via TCP Different from the previous scenarios, we assume that the NAT/FW accepts outgoing traffic only via a TCP connection that is initiated from the HTTP proxy. Consequently, a browser would have to use the HTTP CONNECT method [RFC2817] and request that the HTTP proxy establishes a tunnel connection on its behalf in order to get access to the TURN server. The HTTP CONNECT request needs to convey the TURN Server URI or transport address. As a result the HTTP Proxy will establish a TCP connection to the TURN server and when successful the HTTP Proxy will answer the HTTP CONNECT request with a 200OK response. In case of a transparent proxy, the HTTP proxy will now switch into tunneling mode and will transparently relay the traffic to the TURN server. Stach, et al. Expires March 24, 2014 [Page 6] Internet-Draft RTCWEB NAT-FW September 2013 We want to emphasize that by using the HTTP CONNECT method, the TURN server only has to handle a standard TCP connection. An update to the TURN protocol or the TURN software is not needed. Open Issue: This assumes that the HTTP Proxy can handle establishing the TCP connection to the STUN ports 3478/5349. The syntax of the Request-URI certainly allows this, but is this also supported in the major HTTP proxy implementations? Section 4.3.6 of [draft-ietf-httpbis-p2-semantics] describes tunneling to ports other than 80/443 and the corresponding security impacts. Afterwards, the browser could upgrade the connection to use TLS, forward STUN/TURN traffic via the HTTP proxy and use the TURN server as media relay. Note that upgrading in this case is not to be misunderstood as usage of the HTTP UPGRADE method as specified in [RFC2817] as this would require the TURN server to support HTTP. We rather envisage the following sequence: o the browser opens a TCP connection to the HTTP proxy, o the browser issues a HTTP CONNECT request to the HTTP proxy with the TURN server address in the Request URI, for example CONNECT turn_server.example.com:5349 HTTP/1.1 Host: turn_server.example.com:5349 o the HTTP proxy opens a TCP connection to the TURN server and "bridges" the incoming and outgoing TCP connections together, forming a virtual end-to-end TCP connection, o the browser can do a TLS handshake over the virtual end-to-end TCP connection with the TURN server. If it is not possible to use HTTP CONNECT in this way it will not be possible to establish connectivity between the WebRTC peers and the ICE connectivity checks will fail. Strictly speaking the TLS upgrade is not necessary, but using TLS would also prevent the HTTP proxy from sniffing into the data stream and provides the same flow as HTTPS and might improve interoperability with proxy servers. Some tests (done a while ago) indicated that there are proxies performing Deep Packet inspection (DPI) that expect to see at least a TLS handshake and, possibly, valid TLS records. The application has the ability to control whether TLS is used by the parameters it supplies to the TURN URI (e.g. turns: vs. turn:), so the decision to access the TURN server via TCP versus TLS could be left up to the application or possibly the browser configuration script. Stach, et al. Expires March 24, 2014 [Page 7] Internet-Draft RTCWEB NAT-FW September 2013 In contrast to using UDP or TCP for transporting the STUN messages, the browser would now need to first establish a HTTP over TCP connection to the HTTP proxy, upgrade to using TLS and then switch to using this TLS connection for transport of STUN messages. It is also desirable that the browser detects the need to connect to the TURN server through a HTTP proxy automatically in order to achieve seamless deployment and interoperability. The browser should use the same proxy selection procedure for TURN as currently done for HTTP. The user or network administrator should not be required to change browser or proxy script configuration. Further considerations apply to the default connection timeout of the HTTP proxy connection to the TURN server and the timeout of the TURN server allocation. Whereas [RFC5766] specifies a 10 minutes default lifetime of the TURN allocation, typical proxy connection lifetimes are in the range of 60 seconds if no activity is detected. Thus, if the WebRTC client wants to pre-allocate TURN ressources it needs to refresh TURN allocations more frequently in order to keep the TCP connection to its TURN server alive. 3.3.2. TURN server connection via UDP If a local TURN server under administrative control of the organization is deployed it is desirable to reach this TURN server via UDP. The TURN server could be specified in the proxy configuration script, giving the browser the possibility to learn how to access it. Then, when gathering candidates, this TURN server would always be used such that the WebRTC client application could get UDP traffic out to the internet. 4. Other Approaches 4.1. TURN server connection via WebSocket The WebRTC client could connect to a TURN server via WebSocket [RFC6455] as described in [draft-chenxin-behave-turn-WebSocket]. This might have benefits in very restrictive environments where HTTPS is not permitted through the proxy. However, such environments are also likely to deploy DPI boxes which would eventually complain against usage of WebSocket or block WebRTC traffic based on other heuristic means. It is also to be expected that an environment that does not allow HTTPS will also forbid usage of WebSocket over TLS. In addition, usage of TURN over WebSocket puts an additional burden on existing TURN server implementation to support HTTP and WebSocket. The resulting benefit seems rather small, thus TURN over WebSocket is left for further study. Stach, et al. Expires March 24, 2014 [Page 8] Internet-Draft RTCWEB NAT-FW September 2013 4.2. Port Control Protocol As a further alternative, the Port Control Protocol (PCP) [RFC6887] allows to configure how incoming IPv6 or IPv4 packets are translated and forwarded by a NAT/FW. However, this document does not examine benefits of PCP for the management of the local NAT/FW, but leaves this for further study until PCP is deployed more widely. 4.3. HTTP Fallback for RTP Media Streams As an alternative to using a TURN server it was proposed to send RTP directly over HTTP [draft-miniero-rtcweb-http-fallback]. This approach bears some similarities with TURN as it also uses a RTP relay. However, it uses HTTP GET and POST requests to receive and send RTP packets. Despite a number of open issues, the proposal addreses some corner cases. However, the expected benefit in form of an increased success rate for establishment of a media stream seems rather small, thus HTTP fallback is left for further study. 5. Requirements for RTCWEB-enabled browsers For the purpose of relaying WebRTC media streams or data channels a browser needs to be able to o connect to a TURN server via UDP, TCP and TLS, o support the HTTP CONNECT method and request that a proxy establish a tunneled TCP connection to a TURN server on its behalf, o connect to a TURN server through this HTTP proxy-tunnelled TCP connection, o connect to the TURN server via application specified ports other than the default STUN ports including the HTTP(s) ports, Open issue: Do we want to allow the TURN server to relay data received via the HTTP(S) ports? Is this a change to the TURN protocol, that needs work to be done in the BEHAVE WG? o upgrade the HTTP proxy-tunneled connection to the TURN server to use TLS, o use the same proxy selection procedure for TURN as currently done for HTTP (e.g. Web Proxy Autodiscovery Protocol (WPAD) and .pac- files for Proxy-Auto-Config), Stach, et al. Expires March 24, 2014 [Page 9] Internet-Draft RTCWEB NAT-FW September 2013 o switch the usage of the HTTP proxy-tunneled connection with the TURN server from HTTP to STUN/TURN, Note: Usually, the browser would send further HTTP requests over HTTP proxy-tunneled connection. Here, the connection in just established using HTTP CONNECT, but afterwards used for STUN/TURN messages. o use a preconfigured or standardized port range for UDP-based media streams or data channels, o learn from the proxy configuration script about the presence of a local TURN server and use it for sending UDP traffic to the internet, o as an option and if needed, support ICE-TCP for TCP-based direct media connection to the WebRTC peer. 6. Acknowledgements The authors want to thank Heinrich Haager for all his input during many valuable discussions. Furthermore, the authors want to thank for comments and suggestions received from Bernard Aboba, Xavier Marjou, Dan Wing, ... 7. IANA Considerations This memo includes no request to IANA. 8. Security Considerations TBD 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/ 1.1", RFC 2817, May 2000. Stach, et al. Expires March 24, 2014 [Page 10] Internet-Draft RTCWEB NAT-FW September 2013 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 9.2. Informative References [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", RFC 6062, November 2010. [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011. [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, March 2012. [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013. [draft-chenxin-behave-turn-WebSocket] Xin. Chen , "Traversal Using Relays around NAT (TURN) Extensions for WebSocket Allocations ", 2013, . [draft-ietf-httpbis-p2-semantics] R. Fielding, J. Reschke , "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content ", 2013, . [draft-ietf-rtcweb-data-channel] Stach, et al. Expires March 24, 2014 [Page 11] Internet-Draft RTCWEB NAT-FW September 2013 R. Jesup, S. Loreto, M. Tuexen , "RTCWeb Data Channels ", 2013, . [draft-ietf-rtcweb-use-cases-and-requirements] C. Holmberg, S. Hakansson, G. Eriksson , "Web Real-Time Communication Use-cases and Requirements ", 2013, . [draft-miniero-rtcweb-http-fallback] L. Miniero , "HTTP Fallback for RTP Media Streams ", 2012, . Authors' Addresses Thomas Stach (editor) Siemens Enterprise Communications Dietrichgasse 27-29 Vienna 1030 AT Email: thomas.stach@siemens-enterprise.com Andrew Hutton Siemens Enterprise Communications Technology Drive Nottingham NG9 1LA UK Email: andrew.hutton@siemens-enterprise.com Justin Uberti Google 747 6th Ave S Kirkland, WA 98033 US Email: justin@uberti.name Stach, et al. Expires March 24, 2014 [Page 12]