Internet DRAFT - draft-ietf-rtcweb-return
draft-ietf-rtcweb-return
Network Working Group B. Schwartz
Internet-Draft J. Uberti
Intended status: Standards Track Google
Expires: September 28, 2017 March 27, 2017
Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in
WebRTC
draft-ietf-rtcweb-return-02
Abstract
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.
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 September 28, 2017.
Copyright Notice
Copyright (c) 2017 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
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
Schwartz & Uberti Expires September 28, 2017 [Page 1]
Internet-Draft RETURN March 2017
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Visual Overview of RETURN . . . . . . . . . . . . . . . . . . 3
3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Independent Path Control . . . . . . . . . . . . . . . . 9
4. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Virtual interface . . . . . . . . . . . . . . . . . . . . 10
4.3. Proxy configuration leakiness . . . . . . . . . . . . . . 10
4.4. Sealed proxy rank . . . . . . . . . . . . . . . . . . . . 10
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. ICE candidates produced in the presence of a proxy . . . 11
5.2. Leaky proxy configuration . . . . . . . . . . . . . . . . 11
5.3. Sealed proxy configuration . . . . . . . . . . . . . . . 11
5.4. Proxy rank . . . . . . . . . . . . . . . . . . . . . . . 11
5.5. Multiple physical interfaces . . . . . . . . . . . . . . 12
5.6. IPv4 and IPv6 . . . . . . . . . . . . . . . . . . . . . . 12
5.7. Unspecified leakiness . . . . . . . . . . . . . . . . . . 12
5.8. Interaction with SOCKS5-UDP . . . . . . . . . . . . . . . 12
5.9. Encapsulation overhead, fragmentation, and Path MTU . . . 13
5.10. Interaction with alternate TURN server fallback . . . . . 13
5.11. Reusing the same TURN server . . . . . . . . . . . . . . 13
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Firewalled enterprise network with a basic application . 14
6.2. Conflicting proxies configured by Auto-Discovery and
local policy . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
TURN [RFC5766] 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 [RFC5766], 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
Schwartz & Uberti Expires September 28, 2017 [Page 2]
Internet-Draft RETURN March 2017
it, or to obscure the identity of the participants by concealing
their IP addresses from one another.
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.
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
[I-D.ietf-tram-turn-server-discovery], 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 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 [RFC7478] Section 2.3.5.1.
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.
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.
2. Visual Overview of RETURN
Schwartz & Uberti Expires September 28, 2017 [Page 3]
Internet-Draft RETURN March 2017
____________ 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
Figure 1: Basic WebRTC ICE Candidates with TURN Server
Figure 1 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
RTCIceServers object.
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 [I-D.ietf-rtcweb-jsep].
Since this TURN server is injected by the application, we will refer
to it as an Application TURN server.
Schwartz & Uberti Expires September 28, 2017 [Page 4]
Internet-Draft RETURN March 2017
____________ 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
Figure 2: WebRTC ICE Candidates with DMZ TURN Server
Figure 2 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.
Figure 2 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.
Schwartz & Uberti Expires September 28, 2017 [Page 5]
Internet-Draft RETURN March 2017
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
Figure 3: WebRTC ICE Candidates with Application and Border TURN
Servers
In Figure 3, 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.
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 Figure 4.
Schwartz & Uberti Expires September 28, 2017 [Page 6]
Internet-Draft RETURN March 2017
____________ 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
Figure 4: WebRTC ICE Candidates with Application TURN and Border TURN
Proxy Servers
The Browser in Figure 4 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 Figure 5), 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).
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.
Only the browser needs to implement the RETURN behavior - both the
Border TURN Proxy and Application TURN servers' TURN protocol usage
is unchanged.
Note that this arrangement preserves the end-to-end security and
privacy features of WebRTC media flows. The ability to steer the
Schwartz & Uberti Expires September 28, 2017 [Page 7]
Internet-Draft RETURN March 2017
media flows through multiple TURN servers while still allowing
end-to-end encryption and authentication is a key benefit of
RETURN.
____________ 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
Figure 5: Similarity between HTTP/HTTPS Proxy and TURN Proxy
3. Goals
These goals are requirements on this document (not on implementations
of the specification).
3.1. Connectivity
As noted in [RFC7478] Section 2.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").
Schwartz & Uberti Expires September 28, 2017 [Page 8]
Internet-Draft RETURN March 2017
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.
For efficiency, network administrators SHOULD be able to prevent
browsers from attempting to send traffic through routes that are
already known to be blocked.
3.2. Independent Path Control
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
o improving quality of service by tunneling packets through a
network that is faster than the public internet,
o monitoring the usage of UDP services,
o troubleshooting and debugging problematic services,
o logging connection metadata for legal or auditing reasons,
o recording the entire contents of all connections, or
o providing partial IP address anonymization (as described in
[I-D.ietf-rtcweb-security] Section 4.2.4 and
[I-D.ietf-rtcweb-security-arch] Section 5.4).
4. Concepts
To achieve our goals, we introduce the following new concepts:
4.1. Proxy
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 [I-D.ietf-rtcweb-jsep]. 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.
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 [I-D.ietf-tram-turn-server-discovery] and local policy
([I-D.ietf-rtcweb-jsep] Section 3.5.3, "ICE candidate policy").
Schwartz & Uberti Expires September 28, 2017 [Page 9]
Internet-Draft RETURN March 2017
In an application context, a proxy may be "active" (producing
candidates) or "inactive" (not in use, having no effect on the
context).
4.2. Virtual interface
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).
4.3. Proxy configuration leakiness
"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 ([I-D.ietf-rtcweb-jsep], "ICE candidate
policy") or other mechanisms.
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.
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.
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.
4.4. Sealed proxy rank
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.
Schwartz & Uberti Expires September 28, 2017 [Page 10]
Internet-Draft RETURN March 2017
5. Requirements
5.1. ICE candidates produced in the presence of a proxy
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.
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.
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 [RFC5245]
Section 4.1.2.2, "the local preference for host candidates from a VPN
interface SHOULD have a priority of 0").
5.2. Leaky proxy configuration
If the active proxy for an application is leaky, the browser should
undertake the standard ICE candidate discovery mechanism [RFC5245] on
the available physical and virtual interfaces.
5.3. Sealed proxy configuration
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.
5.4. Proxy rank
Any browser mechanism for specifying a proxy SHOULD allow the caller
to indicate a higher rank than the proxy provided by Auto-Discovery
[I-D.ietf-tram-turn-server-discovery].
Schwartz & Uberti Expires September 28, 2017 [Page 11]
Internet-Draft RETURN March 2017
5.5. Multiple physical interfaces
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.)
Mechanisms for configuring a RETURN proxy SHOULD allow configuring a
proxy that only applies to connections made from a single physical
interface. This is useful to optimize efficiency in modes 2 and 3 of
[I-D.ietf-rtcweb-ip-handling].
5.6. IPv4 and IPv6
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
Happy Eyeballs [RFC6555] procedure for dual-stack clients.
A proxy MAY provide both IPv4 and IPv6 remote addresses to clients
[RFC6156]. 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.
5.7. Unspecified leakiness
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.
5.8. Interaction with SOCKS5-UDP
The SOCKS5 proxy standard [RFC1928] 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.
Schwartz & Uberti Expires September 28, 2017 [Page 12]
Internet-Draft RETURN March 2017
5.9. Encapsulation overhead, fragmentation, and Path MTU
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.
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.
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.
5.10. Interaction with alternate TURN server fallback
As per [RFC5766], 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 [RFC5766]. 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.
5.11. Reusing the same TURN server
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.
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,
Schwartz & Uberti Expires September 28, 2017 [Page 13]
Internet-Draft RETURN March 2017
a RETURN client MUST connect to the server twice, even when this
appears redundant, to ensure correct session attribution.
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.
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.
6. Examples
6.1. Firewalled enterprise network with a basic application
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
[I-D.ietf-tram-turn-server-discovery]. The proxy leakiness of the
TURN server is unspecified, so the browser treats it as leaky.
The application specifies a STUN and TURN server on the public net.
In accordance with the ICE candidate gathering algorithm RFC 5245
[RFC5245], it receives a set of candidates like:
1. A host candidate acquired from one interface.
* e.g. candidate:1610808681 1 udp 2122194687 [internal ip addr
for interface 0] 63555 typ host generation 0
2. A host candidate acquired from a different interface.
* e.g. candidate:1610808681 1 udp 2122194687 [internal ip addr
for interface 1] 54253 typ host generation 0
3. The proxy, as a host candidate.
* e.g. candidate:3458234523 1 udp 24584191 [public ip addr for
the proxy] 54606 typ host generation 0
Schwartz & Uberti Expires September 28, 2017 [Page 14]
Internet-Draft RETURN March 2017
4. The virtual interface also generates a STUN candidate, but it is
eliminated because it is redundant with the host candidate, as
noted in [RFC5245] Sec 4.1.2..
5. The application-provided TURN server as seen through the virtual
interface. (Traffic through this candidate is recursively
encapsulated.)
* 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
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.
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.
6.2. Conflicting proxies configured by Auto-Discovery and local policy
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.
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.
There MUST NOT be any candidate that uses both proxies. Multiple
configured proxies are not chained recursively.
If the locally configured proxy is "sealed", then the browser MUST
produce only candidates from the virtual interface associated with
that proxy.
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.
Schwartz & Uberti Expires September 28, 2017 [Page 15]
Internet-Draft RETURN March 2017
7. Security Considerations
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.
This document describes web browser behaviors that, if implemented
correctly, allow users to achieve greater identity-confidentiality
during WebRTC calls under certain configurations.
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.
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 ([RFC7350] 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.
8. IANA Considerations
This document requires no actions from IANA.
9. Acknowledgements
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 Section 2.
Schwartz & Uberti Expires September 28, 2017 [Page 16]
Internet-Draft RETURN March 2017
10. References
10.1. Normative References
[I-D.ietf-rtcweb-jsep]
Uberti, J., Jennings, C., and E. Rescorla, "Javascript
Session Establishment Protocol", draft-ietf-rtcweb-jsep-19
(work in progress), March 2017.
[I-D.ietf-tram-turn-server-discovery]
Patil, P., Reddy, T., and D. Wing, "TURN Server Auto
Discovery", draft-ietf-tram-turn-server-discovery-12 (work
in progress), January 2017.
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
L. Jones, "SOCKS Protocol Version 5", RFC 1928,
DOI 10.17487/RFC1928, March 1996,
<http://www.rfc-editor.org/info/rfc1928>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>.
[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,
DOI 10.17487/RFC5766, April 2010,
<http://www.rfc-editor.org/info/rfc5766>.
[RFC6156] Camarillo, G., Novo, O., and S. Perreault, Ed., "Traversal
Using Relays around NAT (TURN) Extension for IPv6",
RFC 6156, DOI 10.17487/RFC6156, April 2011,
<http://www.rfc-editor.org/info/rfc6156>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
2012, <http://www.rfc-editor.org/info/rfc6555>.
10.2. Informative References
[I-D.ietf-rtcweb-ip-handling]
Uberti, J. and G. Shieh, "WebRTC IP Address Handling
Requirements", draft-ietf-rtcweb-ip-handling-03 (work in
progress), January 2017.
Schwartz & Uberti Expires September 28, 2017 [Page 17]
Internet-Draft RETURN March 2017
[I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for WebRTC", draft-
ietf-rtcweb-security-08 (work in progress), February 2015.
[I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-12 (work in progress), June 2016.
[RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport
Layer Security (DTLS) as Transport for Session Traversal
Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350,
August 2014, <http://www.rfc-editor.org/info/rfc7350>.
[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
Time Communication Use Cases and Requirements", RFC 7478,
DOI 10.17487/RFC7478, March 2015,
<http://www.rfc-editor.org/info/rfc7478>.
Authors' Addresses
Benjamin M. Schwartz
Google, Inc.
111 8th Ave
New York, NY 10011
USA
Email: bemasc@webrtc.org
Justin Uberti
Google, Inc.
747 6th Street South
Kirkland, WA 98033
USA
Email: justin@uberti.name
Schwartz & Uberti Expires September 28, 2017 [Page 18]
