draft-ietf-rtcweb-return-01.txt   draft-ietf-rtcweb-return-02.txt 
Network Working Group B. Schwartz Network Working Group B. Schwartz
Internet-Draft J. Uberti Internet-Draft J. Uberti
Intended status: Standards Track Google Intended status: Standards Track Google
Expires: July 29, 2016 January 26, 2016 Expires: September 28, 2017 March 27, 2017
Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in
WebRTC WebRTC
draft-ietf-rtcweb-return-01 draft-ietf-rtcweb-return-02
Abstract Abstract
In the context of WebRTC, the concept of a local TURN proxy has been In the context of WebRTC, the concept of a local TURN proxy has been
suggested, but not reviewed in detail. WebRTC applications are suggested, but not reviewed in detail. WebRTC applications are
already using TURN to enhance connectivity and privacy. This already using TURN to enhance connectivity and privacy. This
document explains how local TURN proxies and WebRTC applications can document explains how local TURN proxies and WebRTC applications can
work together. work together.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 29, 2016. This Internet-Draft will expire on September 28, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Visual Overview of RETURN . . . . . . . . . . . . . . . . . . 4 2. Visual Overview of RETURN . . . . . . . . . . . . . . . . . . 3
3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Connectivity . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Independent Path Control . . . . . . . . . . . . . . . . 9 3.2. Independent Path Control . . . . . . . . . . . . . . . . 9
4. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Virtual interface . . . . . . . . . . . . . . . . . . . . 10 4.2. Virtual interface . . . . . . . . . . . . . . . . . . . . 10
4.3. Proxy configuration leakiness . . . . . . . . . . . . . . 10 4.3. Proxy configuration leakiness . . . . . . . . . . . . . . 10
4.4. Sealed proxy rank . . . . . . . . . . . . . . . . . . . . 10 4.4. Sealed proxy rank . . . . . . . . . . . . . . . . . . . . 10
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. ICE candidates produced in the presence of a proxy . . . 11 5.1. ICE candidates produced in the presence of a proxy . . . 11
skipping to change at page 3, line 30 skipping to change at page 3, line 30
network operators may operate a TURN server for their network, which network operators may operate a TURN server for their network, which
can be discovered by clients using TURN Auto-Discovery can be discovered by clients using TURN Auto-Discovery
[I-D.ietf-tram-turn-server-discovery], or through a proprietary [I-D.ietf-tram-turn-server-discovery], or through a proprietary
mechanism. This TURN server may be placed inside the network, with a mechanism. This TURN server may be placed inside the network, with a
firewall configuration allowing it to communicate with the public firewall configuration allowing it to communicate with the public
internet, or it may be operated by a third party outside the network, internet, or it may be operated by a third party outside the network,
with a firewall configuration that allows hosts inside the network to with a firewall configuration that allows hosts inside the network to
communicate with it. Use of the specified TURN server may be the 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 only way for clients on the network to achieve a high quality WebRTC
experience. This scenario is required to be supported by the WebRTC experience. This scenario is required to be supported by the WebRTC
requirements document [I-D.ietf-rtcweb-use-cases-and-requirements] requirements document [RFC7478] Section 2.3.5.1.
Section 3.3.5.1.
When the application intends to use a TURN server for identity When the application intends to use a TURN server for identity
cloaking, and the enterprise network administrator intends to use a cloaking, and the enterprise network administrator intends to use a
TURN server for connectivity, there is a conflict. In current WebRTC TURN server for connectivity, there is a conflict. In current WebRTC
implementations, TURN can only be used on a single-hop basis in each implementations, TURN can only be used on a single-hop basis in each
candidate, but using only the enterprise's TURN server reveals candidate, but using only the enterprise's TURN server reveals
information about the user (e.g. organizational affiliation), and information about the user (e.g. organizational affiliation), and
using only the application's TURN server may be blocked by the using only the application's TURN server may be blocked by the
network administrator, or may require using TURN-TCP or TURN-TLS, network administrator, or may require using TURN-TCP or TURN-TLS,
resulting in a significant sacrifice in latency. resulting in a significant sacrifice in latency.
skipping to change at page 4, line 37 skipping to change at page 4, line 34
..... Non encapsulated ..... Non encapsulated
- - - TURN encapsulated - - - TURN encapsulated
|| Network edge || Network edge
Figure 1: Basic WebRTC ICE Candidates with TURN Server Figure 1: Basic WebRTC ICE Candidates with TURN Server
Figure 1 shows a browser located inside a home or enterprise network Figure 1 shows a browser located inside a home or enterprise network
which connects to the Internet through a Network Address Translator which connects to the Internet through a Network Address Translator
and Firewall (NAT/FW). A TURN server in the Internet cloud is also and Firewall (NAT/FW). A TURN server in the Internet cloud is also
shown, which is provided by the WebRTC application via the JavaScript shown, which is provided by the WebRTC application via the JavaScript
IceServers object. RTCIceServers object.
A WebRTC application can use a TURN server to provide NAT traversal, A WebRTC application can use a TURN server to provide NAT traversal,
but also to provide privacy, routing optimizations, logging, or but also to provide privacy, routing optimizations, logging, or
possibly other functionality. The application can accomplish this by possibly other functionality. The application can accomplish this by
forcing all traffic to flow through the TURN server using the forcing all traffic to flow through the TURN server using the
JavaScript RTCIceTransportPolicy object [I-D.ietf-rtcweb-jsep]. JavaScript RTCIceTransportPolicy object [I-D.ietf-rtcweb-jsep].
Since this TURN server is injected by the application, we will refer Since this TURN server is injected by the application, we will refer
to it as an Application TURN server. to it as an Application TURN server.
____________ inside network || outside network ____________ inside network || outside network
skipping to change at page 8, line 47 skipping to change at page 8, line 47
Figure 5: Similarity between HTTP/HTTPS Proxy and TURN Proxy Figure 5: Similarity between HTTP/HTTPS Proxy and TURN Proxy
3. Goals 3. Goals
These goals are requirements on this document (not on implementations These goals are requirements on this document (not on implementations
of the specification). of the specification).
3.1. Connectivity 3.1. Connectivity
As noted in [I-D.ietf-rtcweb-use-cases-and-requirements] As noted in [RFC7478] Section 2.3.5.1 and requirement F20, a WebRTC
Section 3.3.5.1 and requirement F20, a WebRTC browser endpoint MUST browser endpoint MUST be able to direct UDP connections through a
be able to direct UDP connections through a designated TURN server designated TURN server configured by enterprise policy (a "proxy").
configured by enterprise policy (a "proxy").
It MUST be possible to configure a WebRTC endpoint that supports It MUST be possible to configure a WebRTC endpoint that supports
proxies to achieve connectivity no worse than if the endpoint were proxies to achieve connectivity no worse than if the endpoint were
operating at the proxy's address. operating at the proxy's address.
For efficiency, network administrators SHOULD be able to prevent For efficiency, network administrators SHOULD be able to prevent
browsers from attempting to send traffic through routes that are browsers from attempting to send traffic through routes that are
already known to be blocked. already known to be blocked.
3.2. Independent Path Control 3.2. Independent Path Control
skipping to change at page 9, line 31 skipping to change at page 9, line 31
o monitoring the usage of UDP services, o monitoring the usage of UDP services,
o troubleshooting and debugging problematic services, o troubleshooting and debugging problematic services,
o logging connection metadata for legal or auditing reasons, o logging connection metadata for legal or auditing reasons,
o recording the entire contents of all connections, or o recording the entire contents of all connections, or
o providing partial IP address anonymization (as described in o providing partial IP address anonymization (as described in
[I-D.ietf-rtcweb-security] Section 4.2.4). [I-D.ietf-rtcweb-security] Section 4.2.4 and
[I-D.ietf-rtcweb-security-arch] Section 5.4).
4. Concepts 4. Concepts
To achieve our goals, we introduce the following new concepts: To achieve our goals, we introduce the following new concepts:
4.1. Proxy 4.1. Proxy
In this document a "proxy" is any TURN server that was provided by In this document a "proxy" is any TURN server that was provided by
any mechanism other than through the standard WebRTC-application ICE any mechanism other than through the standard WebRTC-application ICE
candidate provisioning API [I-D.ietf-rtcweb-jsep]. We call it a candidate provisioning API [I-D.ietf-rtcweb-jsep]. We call it a
"proxy" by analogy with SOCKS proxies and similar network services, "proxy" by analogy with SOCKS proxies and similar network services,
because it performs a similar function and can be configured in a because it performs a similar function and can be configured in a
similar fashion. similar fashion.
If a proxy is to be used, it will be the destination of traffic 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/ generated by the client. (There is no analogue to the transparent/
intercepting HTTP proxy configuration, which modifies traffic at the intercepting HTTP proxy configuration, which modifies traffic at the
network layer.) Mechanisms to configure a proxy include Auto- network layer.) Mechanisms to configure a proxy include Auto-
Discovery [I-D.ietf-tram-turn-server-discovery] and local policy Discovery [I-D.ietf-tram-turn-server-discovery] and local policy
([I-D.ietf-rtcweb-jsep], "ICE candidate policy"). ([I-D.ietf-rtcweb-jsep] Section 3.5.3, "ICE candidate policy").
In an application context, a proxy may be "active" (producing In an application context, a proxy may be "active" (producing
candidates) or "inactive" (not in use, having no effect on the candidates) or "inactive" (not in use, having no effect on the
context). context).
4.2. Virtual interface 4.2. Virtual interface
A typical WebRTC browser endpoint may have multiple network A typical WebRTC browser endpoint may have multiple network
interfaces available, such as wired ethernet, wireless ethernet, and interfaces available, such as wired ethernet, wireless ethernet, and
WAN. In this document, a "virtual interface" is a procedure for WAN. In this document, a "virtual interface" is a procedure for
skipping to change at page 12, line 15 skipping to change at page 12, line 15
5.5. Multiple physical interfaces 5.5. Multiple physical interfaces
Some operating systems allow the browser to use multiple interfaces Some operating systems allow the browser to use multiple interfaces
to contact a single remote IP address. To avoid producing an to contact a single remote IP address. To avoid producing an
excessive number of candidates, WebRTC endpoints MUST NOT use excessive number of candidates, WebRTC endpoints MUST NOT use
multiple physical interfaces to connect to a single proxy multiple physical interfaces to connect to a single proxy
simultaneously. (If this were violated, it could produce a number of simultaneously. (If this were violated, it could produce a number of
virtual interfaces equal to the product of the number of physical virtual interfaces equal to the product of the number of physical
interfaces and the number of active proxies.) interfaces and the number of active proxies.)
For strategies to choose the best interface for communication with a Mechanisms for configuring a RETURN proxy SHOULD allow configuring a
proxy, see [I-D.reddy-mmusic-ice-best-interface-pcp]. Similar proxy that only applies to connections made from a single physical
considerations apply when connecting to an application-specified TURN interface. This is useful to optimize efficiency in modes 2 and 3 of
server in the presence of physical and virtual interfaces. [I-D.ietf-rtcweb-ip-handling].
5.6. IPv4 and IPv6 5.6. IPv4 and IPv6
A proxy MAY have both an IPv4 and an IPv6 address (e.g. if the proxy 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 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, try both of these addresses, but MUST select one, preferring IPv6,
before allocating any remote addresses. This corresponds to the the before allocating any remote addresses. This corresponds to the the
Happy Eyeballs [RFC6555] procedure for dual-stack clients. Happy Eyeballs [RFC6555] procedure for dual-stack clients.
A proxy MAY provide both IPv4 and IPv6 remote addresses to clients A proxy MAY provide both IPv4 and IPv6 remote addresses to clients
skipping to change at page 16, line 36 skipping to change at page 16, line 36
endpoint does not reply with a positive indication of ICE consent, endpoint does not reply with a positive indication of ICE consent,
but no such restriction applies to other applications that access the but no such restriction applies to other applications that access the
TURN server. Administrators should take care to provide TURN access TURN server. Administrators should take care to provide TURN access
credentials only to the users who are authorized to have global UDP credentials only to the users who are authorized to have global UDP
network access. network access.
TURN proxies and application TURN servers can provide some privacy TURN proxies and application TURN servers can provide some privacy
protection by obscuring the identity of one peer from the other. protection by obscuring the identity of one peer from the other.
However, unencrypted TURN provides no additional privacy from an However, unencrypted TURN provides no additional privacy from an
observer who can monitor the link between the TURN client and server, observer who can monitor the link between the TURN client and server,
and even encrypted TURN ([I-D.ietf-tram-stun-dtls] Section 4.6) does and even encrypted TURN ([RFC7350] Section 4.6) does not provide
not provide significant privacy from an observer who sniff traffic on significant privacy from an observer who sniff traffic on both legs
both legs of the TURN connection, due to packet timing correlations. of the TURN connection, due to packet timing correlations.
8. IANA Considerations 8. IANA Considerations
This document requires no actions from IANA. This document requires no actions from IANA.
9. Acknowledgements 9. Acknowledgements
Thanks to Harald Alvestrand, Philipp Hancke, Tirumaleswar Reddy, Alan Thanks to Harald Alvestrand, Philipp Hancke, Tirumaleswar Reddy, Alan
Johnston, John Yoakum, and Cullen Jennings for suggestions to improve Johnston, John Yoakum, and Cullen Jennings for suggestions to improve
the content and presentation. Special thanks to Alan Johnston for the content and presentation. Special thanks to Alan Johnston for
contributing the visual overview in Section 2. contributing the visual overview in Section 2.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-rtcweb-jsep] [I-D.ietf-rtcweb-jsep]
Uberti, J. and C. Jennings, "Javascript Session Uberti, J., Jennings, C., and E. Rescorla, "Javascript
Establishment Protocol", draft-ietf-rtcweb-jsep-06 (work Session Establishment Protocol", draft-ietf-rtcweb-jsep-19
in progress), February 2014. (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 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and
L. Jones, "SOCKS Protocol Version 5", RFC 5766, March L. Jones, "SOCKS Protocol Version 5", RFC 1928,
1996. DOI 10.17487/RFC1928, March 1996,
<http://www.rfc-editor.org/info/rfc1928>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April Traversal for Offer/Answer Protocols", RFC 5245,
2010. DOI 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 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, "Traversal [RFC6156] Camarillo, G., Novo, O., and S. Perreault, Ed., "Traversal
Using Relays around NAT (TURN) Extension for IPv6", RFC Using Relays around NAT (TURN) Extension for IPv6",
6156, April 2011. 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 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012. Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
2012, <http://www.rfc-editor.org/info/rfc6555>.
10.2. Informative References 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.
[I-D.ietf-rtcweb-security] [I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for WebRTC", ietf- Rescorla, E., "Security Considerations for WebRTC", draft-
rtcweb-security-07 (work in progress), July 2014. ietf-rtcweb-security-08 (work in progress), February 2015.
[I-D.ietf-rtcweb-use-cases-and-requirements] [I-D.ietf-rtcweb-security-arch]
Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- Rescorla, E., "WebRTC Security Architecture", draft-ietf-
Time Communication Use-cases and Requirements", ietf- rtcweb-security-arch-12 (work in progress), June 2016.
rtcweb-use-cases-and-requirements-14 (work in progress),
February 2014.
[I-D.ietf-tram-stun-dtls] [RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport
Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport
Layer Security (DTLS) as Transport for Session Traversal Layer Security (DTLS) as Transport for Session Traversal
Utilities for NAT (STUN)", ietf-rtcweb-use-cases-and- Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350,
requirements-14 (work in progress), June 2014. August 2014, <http://www.rfc-editor.org/info/rfc7350>.
[I-D.ietf-tram-turn-server-discovery]
Patil, P., Reddy, T., and D. Wing, "TURN Server Auto
Discovery", draft-ietf-tram-turn-server-discovery-00 (work
in progress), July 2014.
[I-D.reddy-mmusic-ice-best-interface-pcp] [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
Reddy, T., Wing, D., VerSteeg, B., Penno, R., and V. Time Communication Use Cases and Requirements", RFC 7478,
Singh, "Improving ICE Interface Selection Using Port DOI 10.17487/RFC7478, March 2015,
Control Protocol (PCP) Flow Extension", draft-ietf-tram- <http://www.rfc-editor.org/info/rfc7478>.
turn-server-discovery-00 (work in progress), October 2013.
Authors' Addresses Authors' Addresses
Benjamin M. Schwartz Benjamin M. Schwartz
Google, Inc. Google, Inc.
111 8th Ave 111 8th Ave
New York, NY 10011 New York, NY 10011
USA USA
Email: bemasc@webrtc.org Email: bemasc@webrtc.org
 End of changes. 24 change blocks. 
54 lines changed or deleted 60 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/