draft-ietf-tram-turn-server-discovery-08.txt   draft-ietf-tram-turn-server-discovery-09.txt 
TRAM P. Patil TRAM P. Patil
Internet-Draft T. Reddy Internet-Draft T. Reddy
Intended status: Standards Track D. Wing Intended status: Standards Track D. Wing
Expires: January 27, 2017 Cisco Expires: February 24, 2017 Cisco
July 26, 2016 August 23, 2016
TURN Server Auto Discovery TURN Server Auto Discovery
draft-ietf-tram-turn-server-discovery-08 draft-ietf-tram-turn-server-discovery-09
Abstract Abstract
Current Traversal Using Relays around NAT (TURN) server discovery Current Traversal Using Relays around NAT (TURN) server discovery
mechanisms are relatively static and limited to explicit mechanisms are relatively static and limited to explicit
configuration. These are usually under the administrative control of configuration. These are usually under the administrative control of
the application or TURN service provider, and not the enterprise, the application or TURN service provider, and not the enterprise,
ISP, or the network in which the client is located. Enterprises and ISP, or the network in which the client is located. Enterprises and
ISPs wishing to provide their own TURN servers need auto discovery ISPs wishing to provide their own TURN servers need auto discovery
mechanisms that a TURN client could use with no or minimal mechanisms that a TURN client could use with no or minimal
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 January 27, 2017. This Internet-Draft will expire on February 24, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 21 skipping to change at page 2, line 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Discovery Procedure . . . . . . . . . . . . . . . . . . . . . 3 3. Discovery Procedure . . . . . . . . . . . . . . . . . . . . . 3
4. Discovery using Service Resolution . . . . . . . . . . . . . 4 4. Discovery using Service Resolution . . . . . . . . . . . . . 4
4.1. Retrieving Domain Name . . . . . . . . . . . . . . . . . 5 4.1. Retrieving Domain Name . . . . . . . . . . . . . . . . . 5
4.1.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.2. From own Identity . . . . . . . . . . . . . . . . . . 5 4.1.2. From own Identity . . . . . . . . . . . . . . . . . . 5
4.2. Resolution . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Resolution . . . . . . . . . . . . . . . . . . . . . . . 6
5. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 7 5. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 7
5.1. mDNS . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. mDNS . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Discovery using Anycast . . . . . . . . . . . . . . . . . . . 8 6. Discovery using Anycast . . . . . . . . . . . . . . . . . . . 8
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 9 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 8
7.1. Mobility and Changing IP addresses . . . . . . . . . . . 9 7.1. Mobility and Changing IP addresses . . . . . . . . . . . 9
7.2. Recursively Encapsulated TURN . . . . . . . . . . . . . . 9 7.2. Recursively Encapsulated TURN . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.1. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9.1. Service Resolution . . . . . . . . . . . . . . . . . . . 11 9.1. Service Resolution . . . . . . . . . . . . . . . . . . . 10
9.2. DNS Service Discovery . . . . . . . . . . . . . . . . . . 11 9.2. DNS Service Discovery . . . . . . . . . . . . . . . . . . 11
9.3. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.3. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 14 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 14
A.1. Change from draft-patil-tram-serv-disc-00 to -01 . . . . 14 A.1. Change from draft-patil-tram-serv-disc-00 to -01 . . . . 14
A.2. Change from draft-ietf-tram-turn-server-discovery-01 to A.2. Change from draft-ietf-tram-turn-server-discovery-01 to
02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
skipping to change at page 3, line 13 skipping to change at page 3, line 13
time communication using audio, video, collaboration etc. time communication using audio, video, collaboration etc.
While TURN services are extensively used today, the means to auto While TURN services are extensively used today, the means to auto
discover TURN servers do not exist. TURN clients are usually discover TURN servers do not exist. TURN clients are usually
explicitly configured with a well known TURN server. To allow TURN explicitly configured with a well known TURN server. To allow TURN
applications to operate seamlessly across different types of networks applications to operate seamlessly across different types of networks
and encourage the use of TURN without the need for manual and encourage the use of TURN without the need for manual
configuration, it is important that there exists an auto discovery configuration, it is important that there exists an auto discovery
mechanism for TURN services. Web Real-Time Communication (WebRTC) mechanism for TURN services. Web Real-Time Communication (WebRTC)
[I-D.ietf-rtcweb-overview] usages and related extensions, which are [I-D.ietf-rtcweb-overview] usages and related extensions, which are
mostly based on web applications, need this immediately. mostly based on web applications, need TURN server discovery
mechanisms.
This document describes three discovery mechanisms, so as to maximize This document describes three discovery mechanisms, so as to maximize
opportunity for discovery, based on the network in which the TURN opportunity for discovery, based on the network in which the TURN
client finds itself. The three discovery mechanisms are: client finds itself. The three discovery mechanisms are:
o A resolution mechanism based on straightforward Naming Authority o A resolution mechanism based on straightforward Naming Authority
Pointer (S-NAPTR) resource records in the Domain Name System Pointer (S-NAPTR) resource records in the Domain Name System
(DNS). [RFC5928] describes details on retrieving a list of server (DNS). [RFC5928] describes details on retrieving a list of server
transport addresses from DNS that can be used to create a TURN transport addresses from DNS that can be used to create a TURN
allocation. allocation.
skipping to change at page 3, line 45 skipping to change at page 3, line 46
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
3. Discovery Procedure 3. Discovery Procedure
TURN clients, by default, discover TURN server(s) by means of local TURN clients, by default, discover TURN server(s) by means of local
or manual TURN configuration i.e., TURN servers configured at the or manual TURN configuration (i.e., TURN servers configured at the
system level. For example, in case of Web Real-Time Communication system level). For example, in case of Web Real-Time Communication
(WebRTC) [I-D.ietf-rtcweb-overview] usages and related extensions, (WebRTC) [I-D.ietf-rtcweb-overview] usages and related extensions,
which are based on web applications, a Java Script specified TURN which are based on web applications, a Java Script specified TURN
server MUST be considered as local configuration. An implementation server MUST be considered as local configuration. An implementation
MAY give the user an opportunity (e.g., by means of configuration MAY give the user an opportunity (e.g., by means of configuration
file options or menu items) to specify a TURN server for each address file options or menu items) to specify a TURN server for each address
family. A client can choose auto-discovery in the absence of local family. A client can choose auto-discovery in the absence of local
configuration, if local configuration doesn't work or on top of local configuration, if local configuration doesn't work or in addition to
configuration. This document does not offer a recommendation on local configuration. This document does not offer a recommendation
server selection. on server selection.
A TURN client that implements the auto discovery algorithm, to A TURN client that implements the auto discovery algorithm, to
discover TURN servers in the attached network, uses the following discover TURN servers in the attached network, uses the following
mechanisms for discovery: mechanisms for discovery:
1. Service Resolution : The TURN client attempts to perform TURN o Service Resolution : The TURN client attempts to perform TURN
service resolution using the host's DNS domain. service resolution using the host's DNS domain.
2. DNS SD: DNS Service Discovery. o DNS SD: DNS Service Discovery.
3. Anycast : Send TURN allocate request to the assigned TURN anycast o Anycast : Send TURN allocate request to the assigned TURN anycast
request for each combination of interface and address family. request for each combination of interface and address family.
Not all TURN servers may be discovered using NAPTR records or DNS SD; Not all TURN servers may be discovered using NAPTR records or DNS SD;
Similarly, not all TURN servers may support anycast. For best Similarly, not all TURN servers may support anycast. For best
results, a client SHOULD implement all discovery mechanisms described results, a client SHOULD implement all discovery mechanisms described
above. above.
The document does not prescribe a strict order that a client must The document does not prescribe a strict order that a client must
follow for discovery. An implementation may choose to perform all follow for discovery. An implementation may choose to perform all
the above steps in parallel for discovery OR choose to follow any the above steps in parallel for discovery OR choose to follow any
desired order and stop the discovery procedure if a mechanism desired order and stop the discovery procedure if a mechanism
skipping to change at page 5, line 24 skipping to change at page 5, line 24
used if no specific name has been configured. used if no specific name has been configured.
4.1.1. DHCP 4.1.1. DHCP
DHCP can be used to determine the domain name related to an DHCP can be used to determine the domain name related to an
interface's point of network attachment. Network operators may interface's point of network attachment. Network operators may
provide the domain name to be used for service discovery within an provide the domain name to be used for service discovery within an
access network using DHCP. Sections 3.2 and 3.3 of [RFC5986] define access network using DHCP. Sections 3.2 and 3.3 of [RFC5986] define
DHCP IPv4 and IPv6 access network domain name options to identify a DHCP IPv4 and IPv6 access network domain name options to identify a
domain name that is suitable for service discovery within the access domain name that is suitable for service discovery within the access
network. [RFC2132] defines the DHCP IPv4 domain name option; While network. [RFC2132] defines the DHCP IPv4 domain name option; while
this option is less suitable, it may still be useful if the options this option is less suitable, it may still be useful if the options
defined in [RFC5986] are not available. defined in [RFC5986] are not available.
For IPv6, the TURN server discovery procedure MUST try to retrieve For IPv6, the TURN server discovery procedure MUST try to retrieve
DHCP option 57 (OPTION_V6_ACCESS_DOMAIN). If no such option can be DHCP option 57 (OPTION_V6_ACCESS_DOMAIN). If no such option can be
retrieved, the procedure fails for this interface. For IPv4, the retrieved, the procedure fails for this interface. For IPv4, the
TURN server discovery procedure MUST try to retrieve DHCP option 213 TURN server discovery procedure MUST try to retrieve DHCP option 213
(OPTION_V4_ACCESS_DOMAIN). If no such option can be retrieved, the (OPTION_V4_ACCESS_DOMAIN). If no such option can be retrieved, the
procedure SHOULD try to retrieve option 15 (Domain Name). If neither procedure SHOULD try to retrieve option 15 (Domain Name). If neither
option can be retrieved the procedure fails for this interface. If a option can be retrieved the procedure fails for this interface. If a
skipping to change at page 5, line 47 skipping to change at page 5, line 47
4.1.2. From own Identity 4.1.2. From own Identity
For a TURN client with an understanding of the protocol mechanics of For a TURN client with an understanding of the protocol mechanics of
calling applications, the client may wish to extract the domain name calling applications, the client may wish to extract the domain name
from its own identity i.e canonical identifier used to reach the from its own identity i.e canonical identifier used to reach the
user. user.
Example Example
SIP : 'sip:alice@example.com' SIP : 'sip:alice@example.com'
JID : 'alice@example.com' Bare JID : 'alice@example.com'
email : 'alice@example.com' email : 'alice@example.com'
'example.com' is retrieved from the above examples. 'example.com' is retrieved from the above examples.
The means to extract the domain name may be different based on the The means to extract the domain name may be different based on the
type of identifier and is outside the scope of this document. type of identifier and is outside the scope of this document.
4.2. Resolution 4.2. Resolution
Once the TURN discovery procedure has retrieved domain names, the Once the TURN discovery procedure has retrieved domain names, the
resolution mechanism described in [RFC5928] is followed. An S-NAPTR resolution mechanism described in [RFC5928] is followed. An S-NAPTR
lookup with 'RELAY' application service and the desired protocol tag lookup with 'RELAY' application service and the desired protocol tag
is made to obtain information necessary to connect to the is made to obtain information necessary to connect to the
authoritative TURN server within the given domain. authoritative TURN server within the given domain.
In the example below, for domain 'example.net', the resolution In the example below, for domain 'example.net', the resolution
algorithm will result in IP address, port, and protocol tuples as algorithm will result in IP address, port, and protocol tuples as
follows: follows:
example.net. example.net.
IN NAPTR 100 10 "" RELAY:turn.udp "" example.net. IN NAPTR 100 10 "" RELAY:turn.udp "" example.net.
example.net. example.net.
IN NAPTR 100 10 S RELAY:turn.udp "" _turn._udp.example.net. IN NAPTR 100 10 S RELAY:turn.udp "" _turn._udp.example.net.
_turn._udp.example.net. _turn._udp.example.net.
IN SRV 0 0 3478 a.example.net. IN SRV 0 0 3478 a.example.net.
a.example.net. a.example.net.
IN A 192.0.2.1 IN A 192.0.2.1
IN AAAA 2001:db8:8:4::2 IN AAAA 2001:db8:8:4::2
+-------+----------+------------------+------+ +-------+----------+------------------+------+
| Order | Protocol | IP address | Port | | Order | Protocol | IP address | Port |
+-------+----------+------------------+------+ +-------+----------+------------------+------+
| 1 | UDP | 192.0.2.1 | 3478 | | 1 | UDP | 192.0.2.1 | 3478 |
+-------+----------+------------------+------+ +-------+----------+------------------+------+
| 2 | UDP | 2001:db8:8:4::2 | 3478 | | 2 | UDP | 2001:db8:8:4::2 | 3478 |
+-------+----------+------------------+------+ +-------+----------+------------------+------+
If no TURN-specific S-NAPTR records can be retrieved, the discovery If no TURN-specific S-NAPTR records can be retrieved, the discovery
skipping to change at page 7, line 9 skipping to change at page 7, line 9
and IP protocol version). If more domain names are known, the and IP protocol version). If more domain names are known, the
discovery procedure may perform the corresponding S-NAPTR lookups discovery procedure may perform the corresponding S-NAPTR lookups
immediately. However, before retrying a lookup that has failed, a immediately. However, before retrying a lookup that has failed, a
client MUST wait a time period that is appropriate for the client MUST wait a time period that is appropriate for the
encountered error (NXDOMAIN, timeout, etc.). encountered error (NXDOMAIN, timeout, etc.).
5. DNS Service Discovery 5. DNS Service Discovery
DNS-based Service Discovery (DNS-SD) [RFC6763] and Multicast DNS DNS-based Service Discovery (DNS-SD) [RFC6763] and Multicast DNS
(mDNS) [RFC6762] provide generic solutions for discovering services (mDNS) [RFC6762] provide generic solutions for discovering services
available in a local network. DNS-SD/ mDNS define a set of naming available in a local network. DNS-SD/mDNS define a set of naming
rules for certain DNS record types that they use for advertising and rules for certain DNS record types that they use for advertising and
discovering services. PTR records are used to enumerate service discovering services.
instances of a given service type. A service instance name is mapped
to a host name and a port number using a SRV record. If a service
instance has more information to advertise than the host name and
port number contained in its SRV record, the additional information
is carried in a TXT record.
Section 4.1 of [RFC6763] specifies that a service instance name in Section 4.1 of [RFC6763] specifies that a service instance name in
DNS-SD has the following structure: DNS-SD has the following structure:
<Instance> . <Service> . <Domain> <Instance> . <Service> . <Domain>
The <Domain> portion specifies the DNS sub-domain where the service The <Domain> portion specifies the DNS sub-domain where the service
instance is registered. It may be "local.", indicating the mDNS instance is registered. It may be "local.", indicating the mDNS
local domain, or it may be a conventional domain name such as local domain, or it may be a conventional domain name such as
"example.com.". The <Service> portion of the TURN service instance "example.com.". The <Service> portion of the TURN service instance
name MUST be "_turnserver._udp", "_turnserver._tcp". name MUST be "_turn._udp" or "_turn._tcp" or "_turns._udp" or
"_turns._tcp".
The <Instance> portion is a DNS label, containing UTF-8-encoded text
[RFC5198], limited to 63 octets in length. It is meant to be a user-
friendly description of the service instance, suitable for a menu-
like user interface display. Thus it can contain any characters
including spaces, punctuation, and non-Latin characters as long as
they can be encoded in UTF-8.
For example, TURN server advertises the following DNS records :
_turnserver._udp.local. PTR example.com._turnserver._udp.local. For example, the following DNS records would be used for a TURN
server with instance name "exampleco TURN Server" providing TURN
service over UDP on port 5030:
example.com._turnserver._udp.local. SRV 0 0 5030 example-turn- _turn._udp.local.
server.local. PTR "exampleco TURN Server"._turn._udp.local.
example-turn-server.local. A 198.51.100.2 "exampleco TURN Server"._turn._udp.local.
SRV 0 0 5030 example-turn-server.local.
example-turn-server.local. AAAA 2001:db8:8:4::2 example-turn-server.local.
A 198.51.100.2
In addition to the service instance name, IP address and the port example-turn-server.local.
number, DNS-SD provides a way to publish other information pertinent AAAA 2001:db8:8:4::2
to the service being advertised. The additional data can be stored
as name/value attributes in a TXT record with the same name as the
SRV record for the service. Each name/value pair within the TXT
record is preceded by a single length byte, thereby limiting the
length of the pair to 255 bytes (See Section 6 of [RFC6763] and
Section 3.3.14 of [RFC1035] for details).
5.1. mDNS 5.1. mDNS
A TURN client tries to discover the TURN servers being advertised in A TURN client tries to discover the TURN servers being advertised in
the site by multicasting a PTR query "_turnserver._udp.local." or the site by multicasting a PTR query "_turn._udp.local." or
"_turnserver._tcp.local" or the TURN server can send out gratuitous "_turn._tcp.local" or "_turns._udp.local." or "_turns._tcp.local" or
multicast DNS answer packets whenever it starts up, wakes from sleep, the TURN server can send out gratuitous multicast DNS answer packets
or detects a chance in network configuration. TURN clients receive whenever it starts up, wakes from sleep, or detects a chance in
these gratuitous packet and cache the information contained in it. network configuration. TURN clients receive these gratuitous packet
and cache the information contained in it.
+------+ +-------------+ +------+ +-------------+
| TURN | | TURN Server | | TURN | | TURN Server |
|Client| | | |Client| | |
+------+ +-------------+ +------+ +-------------+
| | | |
| PTR query "_turnserver._udp.local." | | PTR query "_turn._udp.local." |
|--------------------------------------------->| |--------------------------------------------->|
| PTR reply | | PTR reply |
|<---------------------------------------------| |<---------------------------------------------|
| SRV query | | SRV query |
|--------------------------------------------->| |--------------------------------------------->|
| SRV reply | | SRV reply |
|<---------------------------------------------| |<---------------------------------------------|
| A/AAAA query reply | | A/AAAA query reply |
|--------------------------------------------->| |--------------------------------------------->|
| TURN Request | | TURN Request |
skipping to change at page 9, line 46 skipping to change at page 9, line 38
IANA should allocate an IPv4 and an IPv6 well-known TURN anycast IANA should allocate an IPv4 and an IPv6 well-known TURN anycast
address. 192.0.0.0/24 and 2001:0000::/48 are reserved for IETF address. 192.0.0.0/24 and 2001:0000::/48 are reserved for IETF
Protocol Assignments, as listed at Protocol Assignments, as listed at
<http://www.iana.org/assignments/iana-ipv4-special-registry/> and <http://www.iana.org/assignments/iana-ipv4-special-registry/> and
<http://www.iana.org/assignments/iana-ipv6-special-registry/> <http://www.iana.org/assignments/iana-ipv6-special-registry/>
9. Security Considerations 9. Security Considerations
Use of STUN authentication is OPTIONAL for TURN servers provided by Use of Session Traversal Utilities for NAT (STUN) [RFC5389]
the local network or by the access network. A network provided TURN authentication is OPTIONAL for TURN servers provided by the local
server MAY be configured to accept Allocation requests without STUN network or by the access network. A network provided TURN server MAY
be configured to accept Allocation requests without STUN
authentication, and a TURN client MAY be configured to accept authentication, and a TURN client MAY be configured to accept
Allocation success responses without STUN authentication from a Allocation success responses without STUN authentication from a
network provided TURN server. In order to protect against man-in- network provided TURN server. In order to protect against man-in-
the-middle attacks when accepting a TURN allocation response without the-middle attacks when accepting a TURN allocation response without
STUN authentication, it is RECOMMENDED that the TURN client use one STUN authentication, it is RECOMMENDED that the TURN client use one
of the following techniques with (D)TLS to validate the TURN server: of the following techniques with (D)TLS to validate the TURN server:
o For certificate-based authentication, a pre-populated trust anchor o For certificate-based authentication, a pre-populated trust anchor
store [RFC6024] allows a TURN client to perform path validation store [RFC6024] allows a TURN client to perform path validation
for the server certificate obtained during the (D)TLS handshake. for the server certificate obtained during the (D)TLS handshake.
skipping to change at page 10, line 38 skipping to change at page 10, line 32
use auto-discovered TURN servers for sessions with 'strict privacy' use auto-discovered TURN servers for sessions with 'strict privacy'
requirements, the user needs to be able to define privacy criteria requirements, the user needs to be able to define privacy criteria
(e.g. a trusted list of servers, networks, or domains) that are (e.g. a trusted list of servers, networks, or domains) that are
considered acceptable for such traffic. Any discovered TURN server considered acceptable for such traffic. Any discovered TURN server
outside the criteria is considered untrusted and is not used for outside the criteria is considered untrusted and is not used for
privacy sensitive communication. privacy sensitive communication.
In some auto-discovery scenarios, it might not be possible for the In some auto-discovery scenarios, it might not be possible for the
TURN client to use (D)TLS authentication to validate the TURN server. TURN client to use (D)TLS authentication to validate the TURN server.
However, fall-back to clear text in such cases could leave the TURN However, fall-back to clear text in such cases could leave the TURN
client open to on-path injection of spoofed TURN messages. For this client open to on-path injection of spoofed TURN messages. Instead,
reason, it is beneficial for the TURN client to make use of a TURN client SHOULD fall-back to encryption-only (D)TLS when (D)TLS
'opportunistic privacy', analogous to SMTP opportunistic encryption authentication is not available. Another reason to fall-back to
[RFC7435], where one does not require privacy but one desires privacy encryption-only is for privacy, which is analogous to SMTP
when possible. In this scenario, a TURN client attempts (D)TLS with opportunistic encryption [RFC7435] where one does not require privacy
authentication and encryption, falling back to encryption-only if the but one desires privacy when possible.
TURN server cannot be authenticated via (D)TLS. If the TURN server
does not support unauthenticated (D)TLS, it could fall back to clear It is suggested that a TURN client attempt (D)TLS with authentication
text, but fallback to clear text is NOT RECOMMENDED because it makes and encryption, falling back to encryption-only if the TURN server
the client more susceptible to man-in-the-middle attacks and on-path cannot be authenticated via (D)TLS. The TURN server could fall back
packet injection. A TURN client SHOULD fall-back to encryption-only to clear text if it does not support unauthenticated (D)TLS, but
(D)TLS when (D)TLS authentication is not available in order to fallback to clear text is NOT RECOMMENDED because it makes the client
protect against on-path attackers who might attempt to inject fake more susceptible to man-in-the-middle attacks and on-path packet
TURN messages. injection.
9.1. Service Resolution 9.1. Service Resolution
The primary attack against the methods described in this document is The primary attack against the methods described in this document is
one that would lead to impersonation of a TURN server. An attacker one that would lead to impersonation of a TURN server. An attacker
could attempt to compromise the S-NAPTR resolution. Security could attempt to compromise the S-NAPTR resolution. Security
considerations described in [RFC5928] are applicable here as well. considerations described in [RFC5928] are applicable here as well.
In addition to considerations related to S-NAPTR, it is important to In addition to considerations related to S-NAPTR, it is important to
recognize that the output of this is entirely dependent on its input. recognize that the output of this is entirely dependent on its input.
skipping to change at page 12, line 18 skipping to change at page 12, line 12
configuration can occur naturally via BGP messages advertising that configuration can occur naturally via BGP messages advertising that
no route exists to said address. no route exists to said address.
Sensitive clients that do not wish to leak information about their Sensitive clients that do not wish to leak information about their
presence can set an IP TTL on their TURN requests that limits how far presence can set an IP TTL on their TURN requests that limits how far
they can travel into the public Internet. they can travel into the public Internet.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Simon Perrault, Paul Kyzivat, Troy The authors would like to thank Simon Perrault, Paul Kyzivat, Troy
Shields, Eduardo Gueiros, Ted Hardie, Bernard Aboba, Karl Stahl and Shields, Eduardo Gueiros, Ted Hardie, Bernard Aboba, Karl Stahl,
Brandon Williams for their review and valuable comments. Thanks to Brian Weis, Ralph Dromes and Brandon Williams for their review and
Adam Roach for his detailed review and suggesting DNS Service valuable comments. Thanks to Adam Roach for his detailed review and
Discovery as an additional discovery mechanism. suggesting DNS Service Discovery as an additional discovery
mechanism.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 13, line 9 skipping to change at page 13, line 5
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>. <http://www.rfc-editor.org/info/rfc4033>.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
<http://www.rfc-editor.org/info/rfc5198>. <http://www.rfc-editor.org/info/rfc5198>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008,
<http://www.rfc-editor.org/info/rfc5389>.
[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, Traversal Utilities for NAT (STUN)", RFC 5766,
DOI 10.17487/RFC5766, April 2010, DOI 10.17487/RFC5766, April 2010,
<http://www.rfc-editor.org/info/rfc5766>. <http://www.rfc-editor.org/info/rfc5766>.
[RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT
(TURN) Resolution Mechanism", RFC 5928, (TURN) Resolution Mechanism", RFC 5928,
DOI 10.17487/RFC5928, August 2010, DOI 10.17487/RFC5928, August 2010,
<http://www.rfc-editor.org/info/rfc5928>. <http://www.rfc-editor.org/info/rfc5928>.
skipping to change at page 13, line 46 skipping to change at page 13, line 47
Alvestrand, H., "Overview: Real Time Protocols for Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-15 Browser-based Applications", draft-ietf-rtcweb-overview-15
(work in progress), January 2016. (work in progress), January 2016.
[I-D.ietf-rtcweb-return] [I-D.ietf-rtcweb-return]
Schwartz, B. and J. Uberti, "Recursively Encapsulated TURN Schwartz, B. and J. Uberti, "Recursively Encapsulated TURN
(RETURN) for Connectivity and Privacy in WebRTC", draft- (RETURN) for Connectivity and Privacy in WebRTC", draft-
ietf-rtcweb-return-01 (work in progress), January 2016. ietf-rtcweb-return-01 (work in progress), January 2016.
[I-D.ietf-tram-turn-mobility] [I-D.ietf-tram-turn-mobility]
Wing, D., Patil, P., Reddy, T., and P. Martinsen, Reddy, T., Wing, D., Patil, P., and P. Martinsen,
"Mobility with TURN", draft-ietf-tram-turn-mobility-02 "Mobility with TURN", draft-ietf-tram-turn-mobility-05
(work in progress), April 2016. (work in progress), August 2016.
[RFC3188] Hakala, J., "Using National Bibliography Numbers as [RFC3188] Hakala, J., "Using National Bibliography Numbers as
Uniform Resource Names", RFC 3188, DOI 10.17487/RFC3188, Uniform Resource Names", RFC 3188, DOI 10.17487/RFC3188,
October 2001, <http://www.rfc-editor.org/info/rfc3188>. October 2001, <http://www.rfc-editor.org/info/rfc3188>.
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-
Peer (P2P) Communication across Network Address Peer (P2P) Communication across Network Address
Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March
2008, <http://www.rfc-editor.org/info/rfc5128>. 2008, <http://www.rfc-editor.org/info/rfc5128>.
 End of changes. 31 change blocks. 
85 lines changed or deleted 79 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/