One document matched: draft-hutton-rtcweb-nat-firewall-considerations-00.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 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 RFC6544 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6544.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-00" 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." role="editor"
surname="Stach">
<organization>Siemens Enterprise Communications</organization>
<address>
<postal>
<street>Dietrichgasse 27-29</street>
<city>Vienna</city>
<region></region>
<code>1030</code>
<country>AT</country>
</postal>
<email>thomas.stach@siemens-enterprise.com</email>
</address>
</author>
<author fullname="Andrew Hutton" initials="A."
surname="Hutton">
<organization>Siemens Enterprise Communications</organization>
<address>
<postal>
<street>Technology Drive</street>
<city>Nottingham</city>
<region></region>
<code>NG9 1LA</code>
<country>UK</country>
</postal>
<email>andrew.hutton@siemens-enterprise.com</email>
</address>
</author>
<author fullname="Justin Uberti" initials="J."
surname="Uberti">
<organization>Google</organization>
<address>
<postal>
<street>5 Cambridge Center</street>
<city>Cambridge</city>
<region>MA</region>
<code>02142</code>
<country>US</country>
</postal>
<email>justin@uberti.name</email>
</address>
</author>
<date year="2013" />
<!-- 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 in the presence of NATs, firewalls and HTTP proxies.
HTTP proxy and firewall policies applied in many private network domains introduce obstacles to the successful establishment of media stream via RTCWEB.
This document examines some of these policies and
develops requirements on the web browsers designed to provide the best possible chance of
media connectivity between RTCWEB peers.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Many organizations, e.g. an enterprise, a public service agency or a university, deploy
NATs and firewalls at the border to the public internet.
RTCWEB relies on ICE <xref target="RFC5245"></xref> in order to establish
a media path between two RTCWEB peers in the presence of such NATs/FWs.
As last resort in order to cater for NAT/FWs with address and port dependent filtering characteristics
<xref target="RFC4787"></xref>,
the peers will introduce a TURN server
<xref target="RFC5766"></xref>
in the public internet as a media relay.
Aspects of TURN server deployment in the RTCWEB environment are also considered in
<xref target="draft-ietf-rtcweb-use-cases-and-requirements"></xref>
</t>
<t>
If an organization wants to support RTCWEB such a TURN server may be located in the DMZ of the private network of that organization where it is still under administrative control.
</t>
<t>
In certain environments with very restrictive FW policies a TURN server in the
public internet may not be sufficient to establish connectivity towards the RTCWEB peer for RTP-based media
<xref target="RFC3550"></xref>.
Such policies can include blocking of all UDP based traffic and allowing only HTTP(S) traffic to the TCP ports 80/443.
In addition access to the World Wide Web from inside an organization is often only possible via a HTTP proxy.
</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 establishement 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 NAT shows port and address dependent filtering behavior there is 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 RTCWEB peer using UDP.
How the RTP packets are sent from the RTCWEB 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="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 transport protocol.
This case is used as starting point for introduction of a more restrictive firewall.
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 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 RTCWEB media streams, the same statement would be true if the NAT/Firewall would allow UDP traffic for that ports only.
</t>
</section>
<section anchor="pure_FW_tcp" title="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.
This gives two options for media stream establishment dependent on the NAT's filering
characteristics. Either transport RTP over TCP or contacting the TURN server via TCP.
</t>
<t>In the first case the browser needs use ICE-TCP <xref target="RFC6544"/>
and could launch a successful connectivity check directly to the remote endpoint.
</t>
<t>In the second case the browser needs to contact 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.
</t>
<t>
The TURN server would then relay the RTP packets using UDP.
ICE-TCP <xref target="RFC6544"/> is not needed in this context.
</t>
</section>
<section anchor="pure_FW_http" title="Firewall open only for TCP-based HTTP(s) traffic">
<t>
In this case the firewall blocks all outgoing traffic except for TCP traffic to port 80 for HTTP or 443 for HTTPS.
A TURN server listening to its default ports (3478 for TCP/UDP, 5349 for TLS) would not be reachable in this case.
</t>
<t>
However, the TURN server could still be reached when it is configured to listen to the HTTP(S) ports as well.
In addition the RTCWEB clients need to be configured to contact the TURN server over the HTTP(S) ports.
</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.
Note: If both RTCWEB clients are located behind the same HTTP proxies,
we, of course, assume that ICE would give us a direct media connection within the private network.
We consider this case as out of the scope of 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.
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
Consequently, the same consideration 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 assisted TURN server connection">
<section anchor="proxy_relay_turn" title="TURN server connection via TCP">
<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.
Consequently, a RTCWEB client would have to use the HTTP CONNECT method in order to get access to
the TURN server via the HTTP proxy.
The HTTP CONNECT request needs to convey the TURN Server URI or transport address.
Afterwards, the RTCWEB client could upgrade the connection to use TLS,
forward STUN/TURN traffic via the HTTP proxy and use the TURN server as media relay.
</t>
<t>
If it is not possible to use HTTP CONNECT in this way, WebRTC will not work.
We consider this case as out of the scope of this document.
</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.
Some tests (done a while ago) indicated that there are DPI proxies that expect to see
at least a SSL handshake and, possibly, valid SSL records.
The application has the ability to control whether SSL is used by the parameters it
supplies to the TURN URI (e.g. turns: vs turn:), so the decision
to do TURN/TCP to port 443 versus TURN/TLS to port 443 could be left up to the application.
</t>
<t>
In contrast to using UDP or TCP for transport of 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.
</t>
</section>
<section anchor="proxy_relay_tcp" title="TURN server connection via UDP">
<t>
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 the
RTCWWEB client application could get UDP traffic out to the internet.
</t>
</section>
</section>
</section>
<section anchor="Requirements" title="Requirements for RTCWEB-enabled browsers">
<t>
For the purpose of relaying RTCWEB media streams or data channels a browser needs to be able to
</t>
<t>
- connect to a TURN server via UDP, TCP and TLS
for the purpose of relaying RTCWEB media streams or data channels
</t>
<t>
- connect to a TURN server via a HTTP proxy using the HTTP connect method
</t>
<t>
- connect to a TURN server via the HTTP(s) ports 80/443 instead of the default STUN ports 3478/5349.
</t>
<t>
- upgrade the HTTP proxy-relayed connection to the TURN server to use TLS
</t>
<t>
- use the same proxy selection procedure for TURN as currently done for HTTP
</t>
<t>
- switch the usage of the HTTP proxy-relayed connection with the TURN server from
HTTP to STUN/TURN in order to relay media streams or data channels.
</t>
<t>
- to use a preconfigured or standardized port range for UPD-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>
- support ICE-TCP for TCP-based direct media connection to the RTCWEB peer.
</t>
<!--</list>-->
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
The authors want to thank Heinrich Haager for all his input during many valuable discussions.
</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>
TBD
</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;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC3550;
&RFC4787;
&RFC5245;
&RFC5766;
<!--
&RFC6062;
-->
&RFC6544;
<!-- A reference written by an organization not a person. -->
<reference anchor="draft-ietf-rtcweb-use-cases-and-requirements"
target="http://tools.ietf.org/html/draft-ietf-rtcweb-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="2012" />
</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-24 02:38:13 |