One document matched: draft-hutton-rtcweb-nat-firewall-considerations-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC2817 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2817.xml">
<!ENTITY RFC3550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY RFC4787 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4787.xml">
<!ENTITY RFC5245 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5245.xml">
<!ENTITY RFC5766 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5766.xml">
<!ENTITY RFC6062 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6062.xml">
<!ENTITY RFC6455 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6455.xml">
<!ENTITY RFC6544 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6544.xml">
<!ENTITY RFC6887 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6887.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e., [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-hutton-rtcweb-nat-firewall-considerations-03" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="RTCWEB NAT-FW">RTCWEB Considerations for NATs, Firewalls and HTTP proxies </title>
<author fullname="Thomas Stach" initials="T."
surname="Stach">
<organization>Unify</organization>
<address>
<postal>
<street>Dietrichgasse 27-29</street>
<city>Vienna</city>
<region></region>
<code>1030</code>
<country>AT</country>
</postal>
<email>thomas.stach@unify.com</email>
</address>
</author>
<author fullname="Andrew Hutton" initials="A."
surname="Hutton">
<organization>Unify</organization>
<address>
<postal>
<street>Technology Drive</street>
<city>Nottingham</city>
<region></region>
<code>NG9 1LA</code>
<country>UK</country>
</postal>
<email>andrew.hutton@unify.com</email>
</address>
</author>
<author fullname="Justin Uberti" initials="J."
surname="Uberti">
<organization>Google</organization>
<address>
<postal>
<street>747 6th Ave S</street>
<city>Kirkland</city>
<region>WA</region>
<code>98033</code>
<country>US</country>
</postal>
<email>justin@uberti.name</email>
</address>
</author>
<date year="2014" />
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>RTCWEB, NAT, Firewall, HTTP proxy</keyword>
<abstract>
<t>
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
specifies requirements on WebRTC enabled web browsers designed to provide the best possible chance of
media connectivity between WebRTC peers.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
WebRTC is a web-based technique for direct interactive rich communication using
audio, video, and data between two peer browsers.
</t>
<t>
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 <xref target="RFC5245"></xref> in order to establish
a media path between two WebRTC peers in the presence of such NATs/FWs.
</t>
<t>
When WebRTC is deployed by the corporate IT department one can assume that
the corporate IT configures the corporate NATs, Firewalls, DPI 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
<xref target="RFC4787"></xref>,
the peers will introduce a TURN server
<xref target="RFC5766"></xref>
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.
</t>
<t>
However, there are also environments that are not prepared for WebRTC and have NAT/FW deployed
that prevent 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.
</t>
<t>
In such an environment a WebRTC user may easily reach its WebRTC server possibly
via an HTTP proxy and start establishing a WebRTC 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
<xref target="draft-ietf-rtcweb-use-cases-and-requirements"></xref>.
</t>
<t>
The TURN server in the
public internet is not sufficient to establish connectivity for RTP-based media
<xref target="RFC3550"></xref>
and the WebRTC data channel
<xref target="draft-ietf-rtcweb-data-channel"></xref>
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) <xref target="RFC2616"/>.
</t>
<t>
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.
</t>
<t>
This document examines impact of NAT/FW policies in
<xref target="pure_FW"></xref>.
Additional impacts due to the presence of a HTTP proxy are examined in
<xref target="proxy_FW"></xref>.
</t>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section anchor="pure_FW" title="Considerations for NATs/Firewalls independent of HTTP proxies">
<t>
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 <xref target="proxy_FW"/>.
</t>
<t>
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.
</t>
<t>
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.
</t>
<section anchor="pure_FW_tcp_udp" title="NAT/Firewall open for outgoing UDP and TCP traffic">
<t>
This scenario assumes that the NAT/FW is transparent for all outgoing
traffic independent of using UDP or TCP as the 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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section anchor="pure_FW_tcp" title="NAT/Firewall open only for TCP traffic">
<t>
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.
</t>
<t>
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 <xref target="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.
</t>
<t>
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.
</t>
<t>
Note that the second case is not to be confused with using TURN to request a "TCP Allocation" as described in <xref target="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.
</t>
<t>
We don't see a need to request TCP allocations at the TURN server since it is preferable that WebRTC media is transported over UDP as far as possible.
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 </t>
</section>
<section anchor="pure_FW_http" title="NAT/Firewall open only for TCP on restricted ports">
<t>
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.
</t>
<t>
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 provide this information to browser.
</t>
</section>
</section>
<section anchor="proxy_FW" title="Considerations for NATs/Firewalls in presence of HTTP proxies">
<t>
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.
</t>
<t>
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.
</t>
<section anchor="proxy_FW_tcp_udp" title="HTTP proxy with NAT/Firewall open for
outgoing UDP and TCP traffic">
<t>
As in
<xref target="pure_FW_tcp_udp"/>
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
<xref target="pure_FW_tcp_udp"/>
apply with respect to the traversal of the NAT/FW.
</t>
</section>
<section anchor="proxy_FW_tcp" title="HTTP proxy with NAT/Firewall open only for TCP traffic">
<t>
As in
<xref target="pure_FW_tcp"/>
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
<xref target="pure_FW_tcp"/>
apply with respect to the traversal of the NAT/FW.
</t>
</section>
<section anchor="proxy_relay" title="HTTP proxy with NAT/Firewall open only to proxy routed traffic">
<t>
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. Currently only the case of an explicit proxy is considered here.
</t>
<t>
This scenario is the most complex and controversial as it requires the WebRTC media to be tunneled through the proxy. However such
techniques are already specified in RFC's and deployed an example of this is websockets <xref target="RFC6455"></xref> which uses
the HTTP CONNECT mechanism in the presense of HTTP Proxies.
</t>
<t>
This document discusses some alternative approaches to achieving connectivity for WebRTC media in this environment but does not
currently make any firm recommendations as the alternatives are mostly work in progress in other areas of the IETF. Therefore
it is not possible to make such a recommendation at this time.
</t>
</section>
</section>
<section anchor="solution_overview" title="Solutions for Further Study">
<t>
The following sections outline and provide some analysis of various solutions to the issues raised regarding WebRTC media
traversing firewalls and proxies. All of these potential solutions require further analysis by the IETF RTCWEB working group
and in some cases may require work in other IETF working groups.
</t>
<t>
It is possible that due to different network environments that WebRTC browsers may need to implement more than one solution.
</t>
<t>
NOTE - THIS ANALYSIS IS NOT COMPLETE.
</t>
<section anchor="http_connect" title="HTTP CONNECT based mechanism">
<t>
A WebRTC browser could make use of the HTTP CONNECT method
<xref target="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.
</t>
<t>
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.
</t>
<t>
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 <xref target="RFC2817"/>
as this would require the TURN server to support HTTP.
The following is a possible sequence of events:
</t>
<t><list style="symbols">
<t>the browser opens a TCP connection to the HTTP proxy,
</t>
<t>the browser issues a HTTP CONNECT request to the HTTP proxy with
the TURN server address in the Request URI, for example
<list><t>
CONNECT turn_server.example.com:5349 HTTP/1.1
Host: turn_server.example.com:5349
</t></list>
</t>
<t>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,
</t>
<t>the browser can do a TLS handshake over the virtual end-to-end TCP connection
with the TURN server.
</t>
</list> </t>
<t>
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.
The WebRTC 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.
</t>
<t>
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.
</t>
<t>
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
<xref target="RFC5766"></xref> 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.
</t>
</section>
<section anchor="ALPN" title="ALPN - Use of Application Layer Protocol Negotiation">
<t>
The application layer protocol negotiation (ALPN) <xref target="draft-ietf-tls-applayerprotoneg"></xref> specifies a TLS extension which permits the application
layer to negotiate protocol selection within the TLS handshake. This provides an explicit and visable indication of the application layer protocol associated with the
TLS connection allowing the application protocol to be visable without relying on the port number to identify the protocol.
</t>
<t>
<xref target="draft-ietf-tls-applayerprotoneg"></xref> could therefore be used to identify that it is WebRTC media that is contained within the TLS
connection.
</t>
<t>
ALPN is effectively an extension to the HTTP CONNECT mechanism decribed in <xref target="http_connect"/> since the establishment
of the TLS connection would require the use of this mechanism in the presence of a proxy as described in <xref target="draft-ietf-httpbis-http2"/>.
</t>
</section>
<section anchor="proxy_relay_ws" title="TURN server connection via WebSocket">
<t>
The WebRTC client could connect to a TURN server via WebSocket
<xref target="RFC6455"></xref>
as described in
<xref target="draft-chenxin-behave-turn-WebSocket"></xref>.
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.
</t>
<t>
In addition, usage of TURN over WebSocket puts an additional burden on existing
TURN server implementation to support HTTP and WebSocket.
</t>
<t>
This is again effectively an extension to the HTTP CONNECT mechanism decribed in <xref target="http_connect"/> since the establishment
of the webcoskets connection would require the use of this mechanism in the presence of a proxy as described in <xref target="draft-ietf-httpbis-http2"/>.
Like the ALPN approach the websockets approach also includes that the purpose of the websockets connection is to transport WebRTC media.
</t>
</section>
<section anchor="RTPoverHTTP" title="HTTP Fallback for RTP Media Streams">
<t>
As an alternative to using a TURN server <xref target="draft-miniero-rtcweb-http-fallback"></xref> proposed
to send RTP directly over HTTP.
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.
</t>
<t>
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.
</t>
</section>
<section anchor="PCP" title="Port Control Protocol">
<t>
As a further alternative, the Port Control Protocol (PCP) <xref target="RFC6887"></xref>
allows the client to communicate with the NAT/FW and negotiate how incoming IPv6 or IPv4 packets are translated and forwarded.
However, to be successful such a solution would require the widespread deployment and use of PCP enabled firewalls so this does not appear to
be a workable solution at least for early deployments of WebRTC.
</t>
</section>
<section anchor="proxy_relay_tcp" title="Network Specific TURN Server">
<t>
If a network specific 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.
</t>
<t>
Since the TURN server is under the same administrative control as the NAT/FW then it can be assumed that the NAT/FW allows WebRTC media
that traverses the TURN server to traverse the NAT/FW.
</t>
<t>
The implementation of this solution in WebRTC is actually a requirement specified in <xref target="draft-ietf-rtcweb-use-cases-and-requirements"></xref>.
</t>
<t>
The implementation of this solution in WebRTC does not remove the need for other solutions for the case when there is no such network specific TURN server.
</t>
</section>
</section>
<section anchor="Requirements" title="Requirements for RTCWEB-enabled browsers">
<t>THIS SECTION IS EVEN MORE WORK IN PROGRESS THAN PREVIOUS SECTIONS.
</t>
<t>
For the purpose of relaying WebRTC media streams or data channels a browser needs to be able to
</t>
<t><list style="symbols">
<t>
connect to a TURN server via UDP, TCP and TLS,
</t>
<t>
support a mechanism for connecting to a TURN server in the presence of a firewall that only
permits connections that orginate from a HTTP Proxy. The mechanism is for further study.
</t>
<t>
connect to the TURN server via application specified ports other than the default STUN ports
including the HTTP(s) ports,
</t>
<t>
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),
</t>
<t>
use a preconfigured or standardized port range for UDP-based media streams or data channels,
</t>
<t>
learn from the proxy configuration script about the presence of a local TURN server and
use it for sending UDP traffic to the internet,
</t>
<t>
as an option and if needed, support ICE-TCP for TCP-based direct media connection to the WebRTC peer.
</t>
</list></t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
The authors want to thank Heinrich Haager for all his input during many valuable discussions.
</t>
<t>
Furthermore, the authors want to thank for comments and suggestions received from
Bernard Aboba, Xavier Marjou, Dan Wing, ...
<!-- Harald Alvestrand,
Cameron Byrne,
Gustavo Garcia,
Markus Isomaki,
Hadriel Kaplan,
Reinaldo Penno,
Roy Radhika,
Uwe Rauschenbach and Tirumaleswar Reddy.-->
</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
In case of using HTTP CONNECT to a TURN server the security consideration of [<xref target="draft-ietf-httpbis-p2-semantics"></xref>, Section-4.3.6] apply. It states that there "are significant risks in establishing a tunnel to arbitrary servers, particularly when the destination is a well-known or reserved TCP port that is not intended for Web traffic. ... Proxies that support CONNECT SHOULD restrict its use to a limited set of known ports or a configurable whitelist of safe request targets."
</t>
<t>
Consequently when HTTP CONNECT is used to reach a TURN server, the proxy administrator SHOULD configure a whitelist of trusted TURN servers and/or a blacklist of TURN server known to be subject to fraud or other undesired behavior.
</t>
<t>
With respect to the other discussed alternatives the security considerations of the corresponding RFCs and Internet Drafts apply.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC2616;
&RFC2817;
&RFC3550;
&RFC4787;
&RFC5245;
&RFC5766;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC6062;
&RFC6455;
&RFC6544;
&RFC6887;
<!-- A reference written by an organization not a person. -->
<reference anchor="draft-ietf-tls-applayerprotoneg"
target="http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg">
<front>
<title>
Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension
</title>
<author>
<organization>
S. Friedl, A. Popov, A. Langley, E. Stephan
</organization>
</author>
<date year="2013" />
</front>
</reference>
<reference anchor="draft-ietf-rtcweb-use-cases-and-requirements"
target="http://tools.ietf.org/html/draft-ietf-WebRTC-use-cases-and-requirements">
<front>
<title>
Web Real-Time Communication Use-cases and Requirements
</title>
<author>
<organization>
C. Holmberg, S. Hakansson, G. Eriksson
</organization>
</author>
<date year="2013" />
</front>
</reference>
<reference anchor="draft-ietf-rtcweb-data-channel"
target="http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel">
<front>
<title>
RTCWeb Data Channels
</title>
<author>
<organization>
R. Jesup, S. Loreto, M. Tuexen
</organization>
</author>
<date year="2013" />
</front>
</reference>
<reference anchor="draft-chenxin-behave-turn-WebSocket"
target="http://tools.ietf.org/html/draft-chenxin-behave-turn-WebSocket">
<front>
<title>
Traversal Using Relays around NAT (TURN) Extensions for WebSocket Allocations
</title>
<author>
<organization>
Xin. Chen
</organization>
</author>
<date year="2013" />
</front>
</reference>
<reference anchor="draft-miniero-rtcweb-http-fallback"
target="http://tools.ietf.org/html/draft-miniero-rtcweb-http-fallback">
<front>
<title>
HTTP Fallback for RTP Media Streams
</title>
<author>
<organization>
L. Miniero
</organization>
</author>
<date year="2012" />
</front>
</reference>
<reference anchor="draft-ietf-httpbis-p2-semantics"
target="http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-25#section-4.3.6">
<front>
<title>
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
</title>
<author>
<organization>
R. Fielding, J. Reschke
</organization>
</author>
<date year="2013" />
</front>
</reference>
<reference anchor="draft-ietf-httpbis-http2"
target="http://tools.ietf.org/html/draft-ietf-httpbis-http2-09#section-8.3">
<front>
<title>
Hypertext Transfer Protocol version 2.0
</title>
<author>
<organization>
M. Belshe, R. Peon, M. Thomson, A. Melnikov
</organization>
</author>
<date year="2013" />
</front>
</reference>
</references>
<!--
<section anchor="app-additional" title="Additional Stuff">
<t>This becomes an Appendix.</t>
</section>
Change Log
-->
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 19:30:00 |