draft-ietf-tram-turn-server-discovery-07.txt   draft-ietf-tram-turn-server-discovery-08.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: October 20, 2016 Cisco Expires: January 27, 2017 Cisco
April 18, 2016 July 26, 2016
TURN Server Auto Discovery TURN Server Auto Discovery
draft-ietf-tram-turn-server-discovery-07 draft-ietf-tram-turn-server-discovery-08
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 October 20, 2016. This Internet-Draft will expire on January 27, 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 16 skipping to change at page 2, line 16
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. 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 . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Resolution . . . . . . . . . . . . . . . . . . . . . . . 6
5. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 6 5. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 7
5.1. mDNS . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. mDNS . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Discovery using Anycast . . . . . . . . . . . . . . . . . . . 8 6. Discovery using Anycast . . . . . . . . . . . . . . . . . . . 8
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 9 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . 10 9.1. Service Resolution . . . . . . . . . . . . . . . . . . . 11
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 44 skipping to change at page 3, line 44
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
A TURN client that implements the auto discovery algorithm uses the TURN clients, by default, discover TURN server(s) by means of local
following mechanisms for discovery: or manual TURN configuration i.e., TURN servers configured at the
system level. For example, in case of Web Real-Time Communication
(WebRTC) [I-D.ietf-rtcweb-overview] usages and related extensions,
which are based on web applications, a Java Script specified TURN
server MUST be considered as local configuration. An implementation
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
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. This document does not offer a recommendation on
server selection.
1. Local Configuration : Local or manual TURN configuration i.e., A TURN client that implements the auto discovery algorithm, to
TURN servers configured at the system level. For example, in discover TURN servers in the attached network, uses the following
case of Web Real-Time Communication (WebRTC) mechanisms for discovery:
[I-D.ietf-rtcweb-overview] usages and related extensions, which
are based on web applications, a Java Script specified TURN
server MUST be considered as local configuration. An
implementation 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 family.
2. Service Resolution : The TURN client attempts to perform TURN 1. 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.
3. DNS SD: DNS Service Discovery. 2. DNS SD: DNS Service Discovery.
4. Anycast : Send TURN allocate request to the assigned TURN anycast 3. 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
succeeds. succeeds.
On hosts with more than one interface or address family (IPv4/v6), On hosts with more than one interface or address family (IPv4/v6),
the TURN server discovery procedure has to be performed for each the TURN server discovery procedure has to be performed for each
combination of interface and address family. A client MAY optionaly combination of interface and address family. A client MAY optionally
choose to perform the discovery procedure only for a desired choose to perform the discovery procedure only for a desired
interface/address combination if the client does not wish to discover interface/address combination if the client does not wish to discover
a TURN server for all combinations of interface and address family. a TURN server for all combinations of interface and address family.
4. Discovery using Service Resolution 4. Discovery using Service Resolution
This mechanism is performed in two steps: This mechanism is performed in two steps:
1. A DNS domain name is retrieved for each combination of interface 1. A DNS domain name is retrieved for each combination of interface
and address family. and address family.
skipping to change at page 10, line 39 skipping to change at page 10, line 45
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. For this
reason, it is beneficial for the TURN client to make use of reason, it is beneficial for the TURN client to make use of
'opportunistic privacy', analogous to SMTP opportunistic encryption 'opportunistic privacy', analogous to SMTP opportunistic encryption
[RFC7435], where one does not require privacy but one desires privacy [RFC7435], where one does not require privacy but one desires privacy
when possible. In this scenario, a TURN client attempts (D)TLS with when possible. In this scenario, a TURN client attempts (D)TLS with
authentication and encryption, falling back to encryption-only if the authentication and encryption, falling back to encryption-only if the
TURN server cannot be authenticated via (D)TLS. If the TURN server TURN server cannot be authenticated via (D)TLS. If the TURN server
does not support unauthenticated (D)TLS, then the client falls back does not support unauthenticated (D)TLS, it could fall back to clear
to clear text. Fallback to clear text is NOT RECOMMENDED because it text, but fallback to clear text is NOT RECOMMENDED because it makes
makes the client more susceptible to man-in-the-middle attacks and the client more susceptible to man-in-the-middle attacks and on-path
on-path packet injection. A TURN client SHOULD fall-back to packet injection. A TURN client SHOULD fall-back to encryption-only
encryption-only (D)TLS when (D)TLS authentication is not available in (D)TLS when (D)TLS authentication is not available in order to
order to protect against on-path attackers who might attempt to protect against on-path attackers who might attempt to inject fake
inject fake TURN messages. TURN messages.
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.
 End of changes. 13 change blocks. 
31 lines changed or deleted 35 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/