One document matched: draft-schwartz-rtcweb-return-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace="yes" ?>
<?rfc rfcedstyle="no" ?>
<?rfc tocdepth="4"?>
<rfc category="std" docName="draft-schwartz-rtcweb-return-06" ipr="trust200902">
<front>
<title abbrev="RETURN">
Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in
WebRTC
</title>
<author fullname="Benjamin M. Schwartz" initials="B. M." surname="Schwartz">
<organization abbrev="Google">Google, Inc.</organization>
<address>
<postal>
<street>111 8th Ave</street>
<city>New York</city>
<region>NY</region>
<code>10011</code>
<country>USA</country>
</postal>
<email>bemasc@webrtc.org</email>
</address>
</author>
<author fullname="Justin Uberti" initials="J." surname="Uberti">
<organization abbrev="Google">Google, Inc.</organization>
<address>
<postal>
<street>747 6th Street South</street>
<city>Kirkland</city>
<region>WA</region>
<code>98033</code>
<country>USA</country>
</postal>
<email>justin@uberti.name</email>
</address>
</author>
<date day="7" month="April" year="2015" />
<area>RAI</area>
<abstract>
<t>In the context of WebRTC, the concept of a local TURN proxy has been
suggested, but not reviewed in detail. WebRTC applications are already
using TURN to enhance connectivity and privacy. This document explains how
local TURN proxies and WebRTC applications can work together.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>TURN <xref target="RFC5766"></xref> is a protocol for communication
between a client and a TURN server, in order to route UDP traffic to and
from one or more peers. As noted in <xref target="RFC5766"></xref>, the
TURN relay server “typically sits in the public Internet”. In
a WebRTC context, if a TURN server is to be used, it is typically provided
by the application, either to provide connectivity between users whose NATs
would otherwise prevent it, or to obscure the identity of the participants
by concealing their IP addresses from one another.</t>
<t>In many enterprises, direct UDP transmissions are not permitted between
clients on the internal networks and external IP addresses, so media must
flow over TCP. To enable WebRTC services in such a situation, clients
must use TURN-TCP, or TURN-TLS. These configurations are not ideal: they
send all traffic over TCP, which leads to higher latency than would
otherwise be necessary, and they force the application provider to operate
a TURN server because WebRTC endpoints behind NAT cannot typically act as
TCP servers. These configurations may result in especially bad behaviors
when operating through TCP or HTTP proxies that were not designed to carry
real-time media streams.</t>
<t>To avoid forcing WebRTC media streams through a TCP stage, enterprise
network operators may operate a TURN server for their network, which can
be discovered by clients using TURN Auto-Discovery
<xref target="I-D.ietf-tram-turn-server-discovery"></xref>, or through a
proprietary mechanism. This TURN server may be placed inside the network,
with a firewall configuration allowing it to communicate with the public
internet, or it may be operated by the a third party outside the network,
with a firewall configuration that allows hosts inside the network. to
communicate with it. Use of the specified TURN server may be the only
way for clients on the network to achieve a high quality WebRTC
experience. This scenario is required to be supported by the WebRTC
requirements document
<xref target="I-D.ietf-rtcweb-use-cases-and-requirements"></xref> Section
3.3.5.1.</t>
<t>When the application intends to use a TURN server for identity
cloaking, and the enterprise network administrator intends to use a TURN
server for connectivity, there is a conflict. In current WebRTC
implementations, TURN can only be used on a single-hop basis in each
candidate,
but using only the enterprise's TURN server reveals information about the
user (e.g. organizational affiliation), and using only the application's
TURN server may be blocked by the network administrator, or may require
using TURN-TCP or TURN-TLS, resulting in a significant sacrifice in
latency.</t>
<t>To resolve this conflict, we introduce Recursively Encapsulated TURN,
a procedure that allows a WebRTC endpoint to route traffic through
multiple TURN servers, and get improved connectivity and privacy in
return.</t>
</section>
<section title="Visual Overview of RETURN" anchor="visual_overview">
<figure anchor="app_turn_figure"
title="Basic WebRTC ICE Candidates with TURN Server">
<artwork><![CDATA[
____________ inside network || outside network
/ \ || NAT/FW
| host O ________||________
| | / || \
| srflx|.............|..................O ___________
| | | || | / \
| relay|- - - - - - -|- - - - - - - - - |- - -|- - - - - -O
| | | || | | |
| | | || | | |
| | | || | | |
| | | || | | |
| | | || | \___________/
| | | || |
| | | || | Application TURN
| | | || | server in cloud
\____________/ \________||________/
||
Browser ||
||
KEY O Candidate
..... Non encapsulated
- - - TURN encapsulated
|| Network edge
]]></artwork></figure>
<t><xref target="app_turn_figure" /> shows a browser located
inside a home or enterprise network which connects to the Internet
through a Network Address Translator and Firewall (NAT/FW). A
TURN server in the Internet cloud is also shown, which is provided
by the WebRTC application via the JavaScript IceServers object.</t>
<t>A WebRTC application can use a TURN server to provide NAT traversal,
but also to provide privacy, routing optimizations, logging, or
possibly other functionality. The application can accomplish this by
forcing all traffic to flow through the TURN server using the JavaScript
RTCIceTransportPolicy object <xref target="I-D.ietf-rtcweb-jsep"/>.
Since this TURN server is injected by the application, we will refer to
it as an Application TURN server.</t>
<figure anchor="ent_turn_figure"
title="WebRTC ICE Candidates with DMZ TURN Server">
<artwork><![CDATA[
____________ inside network || outside network
/ \ || NAT/FW
| host O ________||________
| | / || \
| srflx|.............|..................O
| | | || |
| | | || |
| | | _____||_____ |
| | | / || \ |
| (border)|- - - - - - -| -|- - - - - - O |
| | | | || | |
| | | | || | |
| | | | || | |
| | | | || | |
| | | \_____||_____/ |
\____________/ \________||________/
||
Browser Border TURN ||
server in DMZ ||
KEY O Candidate
..... Non encapsulated
- - - TURN encapsulated
|| Network edge
]]></artwork>
</figure>
<t><xref target="ent_turn_figure" /> shows a TURN server co-resident with
the NAT/FW, i.e. in the DMZ of the FW. This TURN server might be used by an
enterprise, ISP, or home network to enable WebRTC media flows that would
otherwise be blocked by the firewall, or to improve quality of service on
flows that pass through this TURN server. This TURN server is not part of
a particular application, and is managed as part of the border control
system, so we call it a Border TURN Server.</t>
<t><xref target="ent_turn_figure" /> shows the port allocated on this TURN
server as "(border)", not any particular candidate type, to distinguish it
from the other ports, which have been represented as ICE candidates in
accordance with the WebRTC specifications. This case is different, because
unlike an Application TURN server, there is not yet any specification for
how WebRTC should interact with a Border TURN server. Under what conditions
should WebRTC allocate a port on a Border TURN server? How should WebRTC
represent that port as an ICE candidate? This draft serves to answer these
two questions.</t>
<figure anchor="app_proxy_figure"
title="WebRTC ICE Candidates with Application and Border TURN Servers">
<artwork><![CDATA[
inside network || outside network
____________ || NAT/FW
/ \ ________||________
| | / || \
| | | || |
| host O.............X || |
| | | || |
| srflx|.............X..................O ___________
| | | || | / \
| relay|- - - - - - -X- - - - - - - - - |- - -|- - - - - -O
| | | _____||_____ | | |
| | | / || \ | | |
| (border)|- - - - - - -|- |- - - - - - O | | |
| | | | || | | \___________/
| | | | || | |
| | | | || | | Application TURN
| | | | || | | server
| | | \_____||_____/ |
\____________/ \________||________/
||
Browser Border TURN ||
server ||
KEY O Candidate
..... Non encapsulated
- - - TURN encapsulated
|| Network edge
X Firewall block
]]></artwork>
</figure>
<t>In <xref target="app_proxy_figure" />, there is both an
Application TURN server and a Border TURN server. The Firewall
is blocking UDP traffic except for UDP traffic to/from the Border
TURN server, so only the "(border)" port allocation will work. However,
there is no specified way for WebRTC to use this port as a candidate.
Moreover, this port on its own would not be sufficient to satisfy
the user's needs.
Both TURN servers provide important functionality, so we need a
way for WebRTC to select a candidate that uses both TURN servers.</t>
<t>The solution proposed in this draft is for the browser to implement
RETURN, which provides a candidate that traverses both TURN servers,
as shown in <xref target="return_figure"/>.</t>
<figure anchor="return_figure"
title="WebRTC ICE Candidates with Application TURN and Border TURN Proxy Servers">
<artwork><![CDATA[
____________ inside network || outside network
/ \ || NAT/FW
| host O ________||________
| | / || \
| srflx|.............|..................O ___________
| | | || | / \
| relay|- - - - - - -|- - - - - - - - - |- - -|- - - - - -O
| | | _____||_____ | | |
| | | / || \ | | |
| relay2|-------------|--|------------| -|- - -|- - - - - -O
| | | | || | | \___________/
| srflx2|- - - - - - -|- |- - - - - - O |
| | | | || | | Application TURN
| host2 |- - - - - - -|- |- - - - - - O | server
| | | \_____||_____/ |
\____________/ \________||________/
||
Browser Border TURN Proxy ||
server ||
KEY O Candidate
..... Non encapsulated
- - - TURN encapsulated
----- Double TURN encapsulated
|| Network edge
]]></artwork>
</figure>
<t>The Browser in <xref target="return_figure" /> implements
RETURN, so it allocates a port on the Border TURN server, now
referred to as a Border TURN Proxy by analogy to an HTTP
CONNECT or SOCKS Proxy (see <xref target="http_proxy_figure" />),
and then runs STUN and TURN over this allocation, resulting
in three candidates: relay2, srflx2, and host2. The relay2
candidate causes traffic to flow through both TURN servers by
encapsulating TURN within TURN - hence the name Recursively
Encapsulated TURN (RETURN).</t>
<t>The host2 and srflx2 candidates are probably identical, so
one will be dropped by ICE. If the NAT/FW blocks UDP and the
application uses only relay candidates, then the relay2
candidate will be selected. Otherwise, the other candidates will
be used, in accordance with the usual ICE procedure.</t>
<t>Only the browser needs to implement the RETURN behavior -
both the Border TURN Proxy and Application TURN servers' TURN
protocol usage is unchanged.</t>
<t><list><t>
Note that this arrangement preserves the end-to-end security
and privacy features of WebRTC media flows. The ability to
steer the media flows through multiple TURN servers while still
allowing end-to-end encryption and authentication is a key
benefit of RETURN.
</t></list></t>
<figure anchor="http_proxy_figure"
title="Similarity between HTTP/HTTPS Proxy and TURN Proxy">
<artwork><![CDATA[
____________ inside network || outside network
/ \ || NAT/FW
| | ________||________
| | / _____||_____ \
| | | / || \ |
| | | | || | |
| | | | || | |
| Web Traffic|=============|==|============H |
| | | | || | |
| | HTTP/ | | || | |
| | HTTPS | \_____||_____/ |
| | Proxy | || |
| | | _____||_____ |
| | | / || \ |
| | | | || | |
| | | | || | |
|WebRTC Media|- - - - - - -|- |- - - - - - O |
| | | | || | |
| | | | || | |
| | TURN | \_____||_____/ |
\____________/ Proxy \________||________/
||
Browser ||
||
KEY O TURN Proxy Candidate
H HTTP/HTTPS Proxy Address
- - - TURN encapsulated
===== HTTP/HTTPS web traffic
|| Network edge
]]></artwork>
</figure>
</section>
<section title="Goals">
<t>These goals are requirements on this document (not on implementations
of the specification).</t>
<section title="Connectivity">
<t>As noted in
<xref target="I-D.ietf-rtcweb-use-cases-and-requirements"></xref>
Section 3.3.5.1 and requirement F20, a WebRTC browser endpoint MUST be
able to direct UDP
connections through a designated TURN server configured by enterprise
policy (a “proxy”).</t>
<t>It MUST be possible to configure a WebRTC endpoint that supports
proxies to achieve connectivity no worse than if the endpoint were
operating at the proxy's address.</t>
<t>For efficiency, network administrators SHOULD be able to prevent
browsers from attempting to send traffic through routes that are already
known to be blocked.</t>
</section>
<section title="Independent Path Control">
<t>Both network administrators and application developers may wish to
direct all their UDP flows through a particular TURN server. There are
many goals that might motivate such a choice, including
<list style="symbols">
<t>improving quality of service by tunneling packets through a network
that is faster than the public internet,</t>
<t>monitoring the usage of UDP services,</t>
<t>troubleshooting and debugging problematic services,</t>
<t>logging connection metadata for legal or auditing reasons,</t>
<t>recording the entire contents of all connections, or</t>
<t>providing partial IP address anonymization (as described in
<xref target="I-D.ietf-rtcweb-security"></xref> Section 4.2.4).</t>
</list>
</t>
</section>
</section>
<section title="Concepts">
<t>To achieve our goals, we introduce the following new concepts:</t>
<section title="Proxy">
<t>In this document a “proxy” is any TURN server that was
provided by any mechanism other than through the standard
WebRTC-application ICE candidate provisioning API
<xref target="I-D.ietf-rtcweb-jsep"></xref>. We call it a "proxy" by
analogy with SOCKS proxies and similar network services, because it
performs a similar function and can be configured in a similar
fashion.</t>
<t>If a proxy is to be used,
it will be the destination of traffic generated by the client. (There is
no analogue to the transparent/intercepting HTTP proxy configuration,
which modifies traffic at the network layer.) Mechanisms to configure a
proxy include Auto-Discovery
<xref target="I-D.ietf-tram-turn-server-discovery"></xref> and local
policy (<xref target="I-D.ietf-rtcweb-jsep"></xref>, "ICE candidate
policy").</t>
<t>In an application context, a proxy may be “active”
(producing candidates) or “inactive” (not in use, having no
effect on the context).</t>
</section>
<section title="Virtual interface">
<t>A typical WebRTC browser endpoint may have multiple network
interfaces available, such as wired ethernet, wireless ethernet, and
WAN. In this document, a “virtual interface” is a procedure
for generating ICE candidates that are not simply generated by a
particular physical interface. A virtual interface can produce
“host”, “server-reflexive”,
and “relay” candidates, but may be restricted to only some
type of candidate (e.g. UDP-only).</t>
</section>
<section title="Proxy configuration leakiness">
<t>“Leakiness” is an attribute of a proxy configuration.
This document defines two values for the “leakiness” of a
proxy configuration: “leaky” and “sealed”. Proxy
configuration, including leakiness, may be set by local policy
(<xref target="I-D.ietf-rtcweb-jsep"></xref>,
“ICE candidate policy”) or other mechanisms.</t>
<t>A leaky configuration adds a proxy and also allows the browser to use
routes that transit directly via the endpoint's physical interfaces (not
through the proxy). In a leaky configuration, setting a proxy augments
the available set of ICE candidates. Multiple leaky-configuration
proxies may therefore be active simultaneously.</t>
<t>A sealed proxy configuration requires the browser to route all WebRTC
traffic through the proxy, eliminating all ICE candidates that do not go
through the proxy. Only one sealed proxy may be active at a time.</t>
<t>Leaky proxy configurations allow more efficient routes to be selected.
For example, two peers on the same LAN can connect directly (peer to
peer) if a leaky proxy is enabled, but must "hairpin" through the TURN
proxy if the configuration is sealed. However, sealed proxy
configurations can be faster to connect, especially if many of the
peer-to-peer routes that ICE will try first are blocked by the network's
firewall policies.</t>
</section>
<section title="Sealed proxy rank">
<t>In some configurations, an endpoint may be subject to multiple sealed
proxy settings at the same time. In that case, one of those settings
will have highest rank, and it will be the active proxy. In a given
application context (e.g. a webpage), there is at most one active sealed
proxy. This document does not specify a representation for rank.</t>
</section>
</section>
<section title="Requirements">
<section title="ICE candidates produced in the presence of a proxy">
<t>When a proxy is configured, by Auto-Discovery or a proprietary means,
the browser MUST NOT report a “relay” candidate representing
the proxy. Instead, the browser MUST connect to
the proxy and then, if the connection is successful, treat the TURN
tunnel as a UDP-only virtual interface.</t>
<t>For a virtual interface representing a TURN proxy, this means that
the browser MUST report the public-facing IP address and port acquired
through TURN as a “host” candidate, the browser MUST perform
STUN through the TURN proxy (if STUN is configured), and it MUST perform
TURN by recursive encapsulation through the TURN proxy, resulting in
TURN candidates whose “raddr” and “rport”
attributes match the acquired public-facing IP address and port on the
proxy.</t>
<t>Because the virtual interface has some additional overhead due to
indirection, it SHOULD have lower priority than the physical interfaces
if physical interfaces are also active. Specifically, even host
candidates generated by a virtual interface SHOULD have priority 0 when
physical interfaces are active (similar to
<xref target="RFC5245"></xref> Section 4.1.2.2, “the local
preference for host candidates from a VPN interface SHOULD have a
priority of 0”).</t>
</section>
<section title="Leaky proxy configuration">
<t>If the active proxy for an application is leaky, the browser should
undertake the standard ICE candidate discovery mechanism
<xref target="RFC5245"></xref> on the available physical and virtual
interfaces.</t>
</section>
<section title="Sealed proxy configuration">
<t>If the active proxy for an application is sealed, the browser MUST
NOT gather or produce any candidates on physical interfaces. The WebRTC
implementation MUST direct its traffic from those interfaces only to the
proxy, and perform ICE candidate discovery only on the single virtual
interface representing the active proxy.</t>
</section>
<section title="Proxy rank">
<t>Any browser mechanism for specifying a proxy SHOULD allow the caller
to indicate a higher rank than the proxy provided by Auto-Discovery
<xref target="I-D.ietf-tram-turn-server-discovery"></xref>.</t>
</section>
<section title="Multiple physical interfaces">
<t>Some operating systems allow the browser to use multiple interfaces
to contact a single remote IP address. To avoid producing an excessive
number of candidates, WebRTC endpoints MUST NOT use multiple physical
interfaces to connect to a single proxy simultaneously. (If this were
violated, it could produce a number of virtual interfaces equal to the
product of the number of physical interfaces and the number of active
proxies.)</t>
<t>For strategies to choose the best interface for communication with a
proxy, see
<xref target="I-D.reddy-mmusic-ice-best-interface-pcp"></xref>. Similar
considerations apply when connecting to an application-specified TURN
server in the presence of physical and virtual interfaces.</t>
</section>
<section title="IPv4 and IPv6">
<t>A proxy MAY have both an IPv4 and an IPv6 address (e.g. if the proxy
is specified by DNS and has both A and AAAA records). The client MAY
try both of these addresses, but MUST select one, preferring IPv6,
before allocating any remote addresses. This corresponds to the
the <xref target="RFC6555">Happy Eyeballs</xref> procedure for
dual-stack clients.</t>
<t>A proxy MAY provide both IPv4 and IPv6 remote addresses to clients
<xref target="RFC6156"></xref>. A client SHOULD request both address
families. If both requests are granted, the client SHOULD treat the two
addresses as host candidates on a dual-stack virtual interface.
</t>
</section>
<section title="Unspecified leakiness">
<t>If a proxy configuration mechanism does not specify leakiness,
browsers SHOULD treat the proxy as leaky. This is similar to current
WebRTC implementations' behavior in the presence of SOCKS and HTTP
proxies: the candidate allocation code continues to generate UDP
candidates that do not transit through the proxy.</t>
</section>
<section title="Interaction with SOCKS5-UDP">
<t>The <xref target="RFC1928">SOCKS5 proxy standard</xref> permits
compliant SOCKS proxies to support UDP traffic. However, most
implementations of SOCKS5 today do not support UDP. Accordingly, WebRTC
browsers MUST by default (i.e. unless deliberately configured otherwise)
treat SOCKS5 proxies as leaky and having lower rank than any configured
TURN proxies.</t>
</section>
<section title="Encapsulation overhead, fragmentation, and Path MTU">
<t>Encapsulating a link in TURN adds overhead on the path between the
client and the TURN server, because each packet must be wrapped in a
TURN message. This overhead is sometimes doubled in RETURN proxying.
To avoid excessive overhead, client implementations SHOULD use
ChannelBind and ChannelData messages to connect and send data through
proxies and application TURN servers when possible. Clients MAY buffer
messages to be sent until the ChannelBind command completes (requiring
one round trip to the proxy), or they MAY use CreatePermission and Send
messages for the first few packets to reduce startup latency at the cost
of higher overhead.</t>
<t>Adding overhead to packets on a link decreases the effective
Maximum Transmissible Unit on that link. Accordingly, clients that
support proxying MUST NOT rely on the effective MTU complying with the
Internet Protocol's minimum MTU requirement.</t>
<t>ChannelData messages have constant overheard, enabling consistent
effective PMTU, but Send messages do not necessarily have constant
overhead. TURN messages may be fragmented and reassembled if they are not
marked with the Don't Fragment (DF) IP bit or the DONT-FRAGMENT TURN
attribute. Client implementors should keep this in mind, especially if
they choose to implement PMTU discovery through the proxy.</t>
</section>
<section title="Interaction with alternate TURN server fallback">
<t>As per <xref target="RFC5766"></xref>, a TURN server MAY respond to
an Allocate request with an error code of 300 and an ALTERNATE-SERVER
indication. When connecting to proxies or application TURN servers,
clients SHOULD attempt to connect to the specified alternate server in
accordance with <xref target="RFC5766"></xref>. The client MUST route
a connection to the alternate server through the proxy if and only if
the original connection attempt was routed through the proxy.</t>
</section>
<section title="Reusing the same TURN server">
<t>It is possible that the same TURN server may appear more than once
in the network path. For example, if both endpoints configure the
same sealed proxy, then each peer will only provide candidates on this
proxy. This is not a problem, and will work as expected.</t>
<t>It is also possible that the same TURN server could be used by both
the enterprise and the application. It might appear attractive to
connect to this server only once, rathering connecting to it through
itself, in order to avoid imposing unnecessary server load. However,
a RETURN client MUST connect to the server twice, even when this
appears redundant, to ensure correct session attribution.</t>
<t>For example, consider a TURN service operator that issues different
authentication credentials to different customers, and then allows each
customer to observe the source and destination IP addresses used with
their credentials. Suppose the application and enterprise both have
accounts on this service: the application uses it to prevent the
enterprise from learning its peers' IP addresses, and the enterprise uses
it to prevent the application from learning its employees' IP addresses.
If the client only connects to the service once, then either the enterprise
or the application will learn IP address information (via the TURN
provider's metadata reporting) that was meant to be kept secret.</t>
<t>As a result of this requirement, it is possible for the same TURN
server to appear up to four times in a RETURN network path: once as each
peer's application's TURN server, and once as each peer's sealed proxy.</t>
</section>
</section>
<section title="Examples">
<section title="Firewalled enterprise network with a basic application">
<t>In this example, an enterprise network is configured with a firewall
that blocks all UDP traffic, and a TURN server is advertised for
Auto-Discovery in accordance with
<xref target="I-D.ietf-tram-turn-server-discovery"></xref>.
The proxy leakiness of the TURN server is unspecified, so the browser
treats it as leaky.</t>
<t>The application specifies a STUN and TURN server on the public net.
In accordance with the ICE candidate gathering algorithm
<xref target="RFC5245">RFC 5245</xref>, it receives a set of candidates
like:
<list style="numbers">
<t>A host candidate acquired from one interface.
<list style="symbols">
<t>e.g. candidate:1610808681 1 udp 2122194687 [internal ip addr
for interface 0] 63555 typ host generation 0</t>
</list></t>
<t>A host candidate acquired from a different interface.
<list style="symbols">
<t>e.g. candidate:1610808681 1 udp 2122194687 [internal ip addr
for interface 1] 54253 typ host generation 0</t>
</list></t>
<t>The proxy, as a host candidate.
<list style="symbols">
<t>e.g. candidate:3458234523 1 udp 24584191 [public ip addr for
the proxy] 54606 typ host generation 0</t>
</list></t>
<t>The virtual interface also generates a STUN candidate, but it is
eliminated because it is redundant with the host candidate, as noted
in <xref target="RFC5245"></xref> Sec 4.1.2..</t>
<t>The application-provided TURN server as seen through the virtual
interface. (Traffic through this candidate is recursively
encapsulated.)
<list style="symbols">
<t>e.g. candidate:702786350 1 udp 24583935 [public ip addr of the
application TURN server] 52631 typ relay raddr [public ip addr for
the proxy] rport 54606 generation 0</t>
</list></t>
</list>
There are no STUN or TURN candidates on the physical interfaces, because
the application-specified STUN and TURN servers are not reachable
through the firewall.</t>
<t>If the remote peer is within the same network, it may be possible to
establish a direct connection using both peers' host candidates. If the
network prevents this kind of direct connection, the path will instead
take a “hairpin” route through the enterprise's proxy, using
one peer's physical “host” candidate and the other's virtual
“host” candidate, or (if that is also disallowed by the
network configuration) a “double hairpin” using both
endpoints' virtual “host” candidates.</t>
</section>
<section title="Conflicting proxies configured by Auto-Discovery and local
policy">
<t>Consider an enterprise network with TURN and HTTP proxies advertised
for Auto-Discovery with unspecified leakiness (thus defaulting to
leaky). The browser endpoint configures an additional TURN proxy by a
proprietary local mechanism.</t>
<t>If the locally configured proxy is leaky, then the browser MUST
produce candidates representing any physical interfaces (including
SSLTCP routes through the HTTP proxy), plus candidates for both UDP-only
virtual interfaces created by the two TURN servers.</t>
<t>There MUST NOT be any candidate that uses both proxies. Multiple
configured proxies are not chained recursively.</t>
<t>If the locally configured proxy is “sealed”, then the
browser MUST produce only candidates from the virtual interface
associated with that proxy.</t>
<t>If both proxies are configured for “sealed” use, then the
browser MUST produce only candidates from the virtual interface
associated with the proxy with higher rank.</t>
</section>
</section>
<section title="Security Considerations">
<t>A RETURN proxy can capture, block, and otherwise interfere with all of
its clients' WebRTC network activity. Therefore, browsers and other WebRTC
endpoints MUST NOT use RETURN proxies that are provided by untrusted
sources. For example, endpoints MUST NOT implement a configuration based
on unauthenticated network multicast (e.g. mDNS) unless the endpoint will
only be used on networks where all other users are fully trusted to
intercept all WebRTC traffic. In contrast, endpoints MAY implement
mechanisms to configure RETURN proxies by system-wide policy, which can only
be modified by trusted system administrators.</t>
<t>This document describes web browser behaviors that, if implemented
correctly, allow users to achieve greater identity-confidentiality during
WebRTC calls under certain configurations.</t>
<t>If a site administrator offers the site's users a TURN proxy, websites
running in the users' browsers will be able to initiate a UDP-based WebRTC
connection to any UDP transport address via the proxy. Websites'
connections will quickly terminate if the remote endpoint does not reply
with a positive indication of ICE consent, but no such restriction applies
to other applications that access the TURN server. Administrators should
take care to provide TURN access credentials only to the users who are
authorized to have global UDP network access.</t>
<t>TURN proxies and application TURN servers can provide some privacy
protection by obscuring the identity of one peer from the other.
However, unencrypted TURN provides no additional privacy from an observer
who can monitor the link between the TURN client and server, and even
encrypted TURN (<xref target="I-D.ietf-tram-stun-dtls"></xref> Section
4.6) does not provide significant privacy from an observer who sniff
traffic on both legs of the TURN connection, due to packet timing
correlations.</t>
</section>
<section title="IANA Considerations">
<t>This document requires no actions from IANA.</t>
</section>
<section title="Acknowledgements">
<t>Thanks to Harald Alvestrand, Philipp Hancke, Tirumaleswar Reddy, Alan
Johnston, John Yoakum, and Cullen Jennings for suggestions to improve the
content and presentation. Special thanks to Alan Johnston for
contributing the visual overview in <xref target="visual_overview"/>.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC5245">
<front>
<title>Interactive Connectivity Establishment (ICE): A Protocol for
Network Address Translator (NAT) Traversal for Offer/Answer
Protocols</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization>jdrosen.net</organization>
</author>
<date month="April" year="2010" />
</front>
<seriesInfo name="RFC" value="5245" />
<format target="http://www.rfc-editor.org/rfc/rfc5245.txt" type="TXT" />
</reference>
<reference anchor="RFC5766">
<front>
<title>Traversal Using Relays around NAT (TURN): Relay Extensions to
Session Traversal Utilities for NAT (STUN)</title>
<author fullname="Rohan Mahy" initials="R." surname="Mahy">
<organization></organization>
</author>
<author fullname="Philip Matthews" initials="P." surname="Matthews">
<organization>Alcatel-Lucent</organization>
</author>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization>jdrosen.net</organization>
</author>
<date month="April" year="2010" />
</front>
<seriesInfo name="RFC" value="5766" />
<format target="http://www.rfc-editor.org/rfc/rfc5245.txt" type="TXT" />
</reference>
<reference anchor="RFC1928">
<front>
<title>SOCKS Protocol Version 5</title>
<author fullname="Marcus Leech" initials="M." surname="Leech">
<organization>Bell-Northern Research Ltd</organization>
</author>
<author initials="M." surname="Ganis">
<organization>International Business Machines</organization>
</author>
<author initials="Y." surname="Lee">
<organization>NEC Systems Laboratory</organization>
</author>
<author initials="R." surname="Kuris">
<organization>Unify Corporation</organization>
</author>
<author initials="D." surname="Koblas">
<organization></organization>
</author>
<author initials="L." surname="Jones">
<organization>Hewlett-Packard Company</organization>
</author>
<date month="March" year="1996" />
</front>
<seriesInfo name="RFC" value="5766" />
<format octets="285120"
target="http://www.rfc-editor.org/rfc/rfc1928.txt" type="TXT" />
</reference>
<reference anchor="RFC6156">
<front>
<title>Traversal Using Relays around NAT (TURN) Extension for
IPv6</title>
<author fullname="Gonzalo Camarillo" initials="G."
surname="Camarillo">
<organization>Ericsson</organization>
</author>
<author fullname="Oscar Novo" initials="O." surname="Novo">
<organization>Ericsson</organization>
</author>
<author fullname="Simon Perreault" initials="S." surname="Perreault">
<organization>Viagenie</organization>
</author>
<date month="April" year="2011" />
</front>
<seriesInfo name="RFC" value="6156" />
<format target="http://www.rfc-editor.org/rfc/rfc6156.txt" type="TXT" />
</reference>
<reference anchor="RFC6555">
<front>
<title>Happy Eyeballs: Success with Dual-Stack Hosts</title>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization>Cisco Systems, Inc.</organization>
</author>
<author fullname="Andrew Yourtchenko" initials="A."
surname="Yourtchenko">
<organization>Cisco Systems, Inc.</organization>
</author>
<date month="April" year="2012" />
</front>
<seriesInfo name="RFC" value="6555" />
<format target="http://www.rfc-editor.org/rfc/rfc6555.txt" type="TXT" />
</reference>
<reference anchor="I-D.ietf-rtcweb-jsep">
<front>
<title>Javascript Session Establishment Protocol</title>
<author fullname="Justin Uberti" initials="J" surname="Uberti">
<organization></organization>
</author>
<author fullname="Cullen Jennings" initials="C" surname="Jennings">
<organization></organization>
</author>
<date day="13" month="February" year="2014" />
<abstract>
<t>This document describes the mechanisms for allowing a Javascript
application to control the signaling plane of a multimedia session
via the interface specified in the W3C RTCPeerConnection API, and
discusses how this relates to existing signaling protocols.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-rtcweb-jsep-06" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-jsep-06.txt"
type="TXT" />
</reference>
</references>
<references title="Informative References">
<reference anchor="I-D.ietf-tram-turn-server-discovery">
<front>
<title>TURN Server Auto Discovery</title>
<author fullname="Prashanth Patil" initials="P" surname="Patil">
<organization>Cisco Systems, Inc.</organization>
</author>
<author fullname="Tirumaleswar Reddy" initials="T" surname="Reddy">
<organization>Cisco Systems, Inc.</organization>
</author>
<author fullname="Dan Wing" initials="D" surname="Wing">
<organization>Cisco Systems, Inc.</organization>
</author>
<date day="24" month="July" year="2014" />
<abstract>
<t>Current Traversal Using Relays around NAT (TURN) server discovery
mechanisms are relatively static and limited to explicit
configuration. These are usually under the administrative control
of the application or TURN service provider, and not the enterprise
or the ISP, the network in which the client is located. Enterprises
and ISPs wishing to provide their own TURN servers need auto
discovery mechanisms that a TURN client could use with no or minimal
configuration. This document describes two such mechanisms for TURN
server discovery.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-tram-turn-server-discovery-00" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-tram-turn-server-discovery-00.txt"
type="TXT" />
</reference>
<reference anchor="I-D.reddy-mmusic-ice-best-interface-pcp">
<front>
<title>Improving ICE Interface Selection Using Port Control Protocol
(PCP) Flow Extension</title>
<author fullname="Tirumaleswar Reddy" initials="T" surname="Reddy">
<organization>Cisco Systems, Inc.</organization>
</author>
<author fullname="Dan Wing" initials="D" surname="Wing">
<organization>Cisco Systems, Inc.</organization>
</author>
<author fullname="Bill VerSteeg" initials="B" surname="VerSteeg">
<organization>Cisco Systems, Inc.</organization>
</author>
<author fullname="Reinaldo Penno" initials="R" surname="Penno">
<organization>Cisco Systems, Inc.</organization>
</author>
<author fullname="Varun Singh" initials="V" surname="Singh">
<organization>Aalto University</organization>
</author>
<date day="10" month="October" year="2013" />
<abstract>
<t>A host with multiple interfaces needs to choose the best
interface for communication. Oftentimes, this decision is based on
a static configuration and does not consider the link
characteristics of that interface, which may affect the user
experience.</t>
<t>This document describes a mechanism for an endpoint to query the
link characteristics from the access router (the router at the other
end of the endpoint's access link) using a Port Control Protocol
(PCP) Flow Extension. This information influences endpoint's
Interactive Connectivity Establishment (ICE) candidate selection
algorithm.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-tram-turn-server-discovery-00" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-tram-turn-server-discovery-00.txt"
type="TXT" />
</reference>
<reference anchor="I-D.ietf-rtcweb-use-cases-and-requirements">
<front>
<title>Web Real-Time Communication Use-cases and Requirements</title>
<author fullname="Christer Holmberg" initials="C" surname="Holmberg">
<organization>Ericsson</organization>
</author>
<author fullname="Stefan Hakansson" initials="S" surname="Hakansson">
<organization>Ericsson</organization>
</author>
<author fullname="Goran AP Eriksson" initials="G" surname="Eriksson">
<organization>Ericsson</organization>
</author>
<date day="12" month="February" year="2014" />
<abstract>
<t>This document describes web based real-time communication
use-cases. Requirements on the browser functionality are derived
from the use-cases.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="ietf-rtcweb-use-cases-and-requirements-14" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-use-cases-and-requirements-14.txt"
type="TXT" />
</reference>
<reference anchor="I-D.ietf-tram-stun-dtls">
<front>
<title>Datagram Transport Layer Security (DTLS) as Transport for
Session Traversal Utilities for NAT (STUN)</title>
<author fullname="Marc Petit-Huguenin" initials="M"
surname="Petit-Huguenin">
<organization>Jive Communications</organization>
</author>
<author fullname="Gonzalo Salgueiro" initials="G" surname="Salgueiro">
<organization>Cisco Systems</organization>
</author>
<date day="27" month="June" year="2014" />
<abstract>
<t>This document specifies the usage of Datagram Transport Layer
Security (DTLS) as a transport protocol for Session Traversal
Utilities for NAT (STUN). It provides guidances on when and how to
use DTLS with the currently standardized STUN Usages. It also
specifies modifications to the STUN URIs and TURN URIs and to the
TURN resolution mechanism to facilitate the resolution of STUN URIs
and TURN URIs into the IP address and port of STUN and TURN servers
supporting DTLS as a transport protocol. This document updates RFC
5389 and RFC 5928.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="ietf-rtcweb-use-cases-and-requirements-14" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-use-cases-and-requirements-14.txt"
type="TXT" />
</reference>
<reference anchor="I-D.ietf-rtcweb-security">
<front>
<title>Security Considerations for WebRTC</title>
<author fullname="Eric Rescorla" initials="E" surname="Rescorla">
<organization>RTFM, Inc.</organization>
</author>
<date day="4" month="July" year="2014" />
<abstract>
<t>The Real-Time Communications on the Web (RTCWEB) working group is
tasked with standardizing protocols for real-time communications
between Web browsers, generally called "WebRTC". The major use cases
for WebRTC technology are real-time audio and/or video calls, Web
conferencing, and direct data transfer. Unlike most conventional
real-time systems (e.g., SIP-based soft phones) WebRTC communications
are directly controlled by a Web server, which poses new security
challenges. For instance, a Web browser might expose a JavaScript
API which allows a server to place a video call. Unrestricted access
to such an API would allow any site which a user visited to "bug" a
user's computer, capturing any activity which passed in front of
their camera. This document defines the WebRTC threat model and
analyzes the security threats of WebRTC in that model.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="ietf-rtcweb-security-07" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-rtcweb-security-07.txt"
type="TXT" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:19:43 |