draft-ietf-tram-turn-server-discovery-01.txt   draft-ietf-tram-turn-server-discovery-02.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: July 26, 2015 Cisco Expires: November 14, 2015 Cisco
January 22, 2015 May 13, 2015
TURN Server Auto Discovery TURN Server Auto Discovery
draft-ietf-tram-turn-server-discovery-01 draft-ietf-tram-turn-server-discovery-02
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 or the application or TURN service provider, and not the enterprise,
the ISP, 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
configuration. This document describes two such mechanisms for TURN configuration. This document describes three such mechanisms for
server discovery. TURN server discovery.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 26, 2015. This Internet-Draft will expire on November 14, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 17 skipping to change at page 2, line 17
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 . . . . . . . . . . . . . . . . . 4
4.1.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.2. IP Address . . . . . . . . . . . . . . . . . . . . . 5 4.1.2. From own Identity . . . . . . . . . . . . . . . . . . 5
4.1.3. From own Identity . . . . . . . . . . . . . . . . . . 5
4.2. Resolution . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Resolution . . . . . . . . . . . . . . . . . . . . . . . 5
4.2.1. SOA . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 6
5. Discovery using Anycast . . . . . . . . . . . . . . . . . . . 7 5.1. mDNS . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 7 6. Discovery using Anycast . . . . . . . . . . . . . . . . . . . 8
6.1. Mobility and Changing IP addresses . . . . . . . . . . . 7 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7.1. Mobility and Changing IP addresses . . . . . . . . . . . 9
7.1. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8.1. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Service Resolution . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8.2. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Service Resolution . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9.2. DNS Service Discovery . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.3. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Change History . . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 11
A.1. Change from draft-patil-tram-serv-disc-00 to -01 . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 12
A.1. Change from draft-patil-tram-serv-disc-00 to -01 . . . . 12
A.2. Change from draft-ietf-tram-turn-server-discovery-01 to
02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
TURN [RFC5766] is a protocol that is often used to improve the TURN [RFC5766] is a protocol that is often used to improve the
connectivity of Peer-to-Peer (P2P) applications (as defined in connectivity of Peer-to-Peer (P2P) applications (as defined in
section 2.7 of [RFC5128]). TURN allows a connection to be section 2.7 of [RFC5128]). TURN allows a connection to be
established when one or both sides are incapable of a direct P2P established when one or both sides are incapable of a direct P2P
connection. It is an important building block for interactive, real- connection. It is an important building block for interactive, real-
time communication using audio, video, collaboration etc. While TURN time communication using audio, video, collaboration etc. While TURN
services are extensively used today, the means to auto discover TURN services are extensively used today, the means to auto discover TURN
servers do not exist. TURN clients are usually explicitly configured servers do not exist. TURN clients are usually explicitly configured
with a well known TURN server. To allow TURN applications operate with a well known TURN server. To allow TURN applications operate
seamlessly across different types of networks and encourage the use seamlessly across different types of networks and encourage the use
of TURN without the need for manual configuration, it is important of TURN without the need for manual configuration, it is important
that there exists an auto discovery mechanism for TURN services. Web that there exists an auto discovery mechanism for TURN services. Web
Real-Time Communication (WebRTC) [I-D.ietf-rtcweb-overview] usages Real-Time Communication (WebRTC) [I-D.ietf-rtcweb-overview] usages
and related extensions, which are mostly based on web applications, and related extensions, which are mostly based on web applications,
need this immediately. need this immediately.
This document describes two discovery mechanisms. The reason for This document describes three discovery mechanisms. The reason for
providing two mechanisms is to maximize the opportunity for providing multiple mechanisms is to maximize the opportunity for
discovery, based on the network in the which the TURN client sees discovery, based on the network in the which the TURN client finds
itself. itself.
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.
o DNS Service Discovery
o A mechanism based on anycast address for TURN. o A mechanism based on anycast address for TURN.
In general, if a client wishes to communicate using one of its In general, if a client wishes to communicate using one of its
interfaces using a specific IP address family, it SHOULD query the interfaces using a specific IP address family, it SHOULD query the
TURN server(s) that has been discovered for that specific interface TURN server(s) that has been discovered for that specific interface
and address family. How to select an interface and IP address and address family. How to select an interface and IP address
family, is out of the scope of this document. family, is out of the scope of this document.
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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Discovery Procedure 3. Discovery Procedure
A TURN client that implements the auto discovery algorithm MUST A TURN client that implements the auto discovery algorithm uses the
proceed with discovery in the following order: following mechanisms for discovery:
1. Local Configuration : Local or manual configuration should be 1. Local Configuration : Local or manual configuration should be
tried first, as it may be an explicit preferred choice of a user. tried first, as it may be an explicit preferred choice of a user.
An implementation MAY give the user an opportunity (e.g., by An implementation MAY give the user an opportunity (e.g., by
means of configuration file options or menu items) to specify a means of configuration file options or menu items) to specify a
TURN server for every address family. TURN server for every address family.
2. Service Resolution : The TURN client attempts to perform TURN 2. Service Resolution : Service Resolution : The TURN client
service resolution using the DNS domain name that the host attempts to perform TURN service resolution using the host's DNS
belongs to OR the hosts' global IP address. The TURN client will domain.
attempt to do this for each combination of interface and address
family. The retrieved DNS domain names OR IP addresses are then
used for NAPTR lookups.
3. Anycast : Send TURN allocate request to the assigned TURN anycast 3. DNS Service Discovery (DNS SD)
4. 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.
While it is expected that Step-3 be performed if Step-2 fails, an Not all TURN servers may be discovered using NAPTR records or DNS SD;
implementation may choose to perform steps 2 and 3 in parallel. Similarly, not all TURN servers may support anycast. For best
results, a client MUST implement all discovery mechanisms described
above.
The document does not prescribe a strict order that a client must
follow for discovery. An implementation may choose to perform steps
2,3 and 4 in parallel for discovery OR choose to follow any desired
order and stop the discovery procedure if a mechanism succeeds.
On hosts with more than one interface or address family (IPv4/v6),
the TURN server discovery procedure has to be performed for each
combination of interface and address family. A client MAY optionaly
choose to perform the discovery procedure only for a desired
interface/address combination, if the client does not wish to
discover 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.
2. Retrieved DNS domain names are then used for S-NAPTR lookups as 2. Retrieved DNS domain names are then used for S-NAPTR lookups as
per [RFC5928]. Further DNS lookups may be necessary to determine per [RFC5928]. Further DNS lookups may be necessary to determine
TURN server IP address(es). TURN server IP address(es).
On hosts with more than one interface or address family (IPv4/v6),
the TURN server discovery procedure has to be run for each
combination of interface and address family.
4.1. Retrieving Domain Name 4.1. Retrieving Domain Name
The domain, in which the client is located, can be determined using A client has to determine the domain in which it is located. The
one of the techniques provided below. An implementation can choose following sections provide two possible mechanisms to learn the
to use any or all techniques. domain name, but other means of retrieving domain names may be used,
which are outside the scope of this document e.g. local
configuration.
Implementations may allow the user to specify a default name that is Implementations may allow the user to specify a default name that is
used if no specific name has been configured. Other means of used if no specific name has been configured.
retrieving domain names may be used, which are outside the scope of
this document e.g. local configuration.
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. [RFC5986] defines DHCP IPv4 and IPv6 access network using DHCP. [RFC5986] defines DHCP IPv4 and IPv6
access network domain name options to identify a domain name that is access network domain name options to identify a domain name that is
suitable for service discovery within the access network. [RFC2132] suitable for service discovery within the access network. [RFC2132]
defines the DHCP IPv4 domain name option. While this option is less defines the DHCP IPv4 domain name option. While this option is less
skipping to change at page 5, line 10 skipping to change at page 5, line 27
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
result can be retrieved it will be used as an input for S-NAPTR result can be retrieved it will be used as an input for S-NAPTR
resolution. resolution.
4.1.2. IP Address 4.1.2. From own Identity
Typically, but not necessarily, the DNS domain name is the domain
name in which the client is located, i.e., a PTR lookup on the
client's IP address (according to [RFC1035], Section 3.5 for IPv4 or
[RFC3596], Section 2.5 for IPv6) would yield a similar name.
However, due to the widespread use of Network Address Translation
(NAT), the client MAY need to determine its public IP address using
mechanisms described in [RFC7216].
4.1.3. From own Identity
A TURN client could also wish to extract the domain name from its own A TURN client could also wish to extract the domain name from its own
identity i.e canonical identifier used to reach the user. identity i.e canonical identifier used to reach the user.
Example Example
SIP : 'sip:alice@example.com' SIP : 'sip:alice@example.com'
JID : 'alice@example.com' JID : 'alice@example.com'
email : 'alice@example.com' email : 'alice@example.com'
skipping to change at page 6, line 31 skipping to change at page 6, line 35
+-------+----------+------------+------+ +-------+----------+------------+------+
If no TURN-specific S-NAPTR records can be retrieved, the discovery If no TURN-specific S-NAPTR records can be retrieved, the discovery
procedure fails for this domain name (and the corresponding interface procedure fails for this domain name (and the corresponding interface
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.).
4.2.1. SOA 5. DNS Service Discovery
If no TURN-specific S-NAPTR records can be retrieved using the DNS-based Service Discovery (DNS-SD) [RFC6763] and Multicast DNS
previous step, additional steps described in this section have to be (mDNS) [RFC6762] provide generic solutions for discovering services
followed. First, an SOA record for the "reverse zone" i.e., the zone available in a local network. DNS-SD/ mDNS define a set of naming
in the in-addr.arpa. or ip6.arpa. domain that contains the IP rules for certain DNS record types that they use for advertising and
address(s) in question, has to be retrieved. IP addresses can be discovering services. PTR records are used to enumerate service
determined, if not done already, as described in Section 4.1.2. 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.
A sample SOA record could be: Section 4.1 of [RFC6763] specifies that a service instance name in
DNS-SD has the following structure:
100.51.198.in-addr.arpa <Instance> . <Service> . <Domain>
IN SOA dns1.isp.example.net. hostmaster.isp.example.net. ( The <Domain> portion specifies the DNS sub-domain where the service
1 ; Serial instance is registered. It may be "local.", indicating the mDNS
604800 ; Refresh local domain, or it may be a conventional domain name such as
86400 ; Retry "example.com.". The <Service> portion of the TURN service instance
2419200 ; Expire name MUST be "_turnserver._udp", "_turnserver._tcp".
604800 ) ; Negative Cache TTL
If this lookup fails, the discovery procedure is aborted without a The <Instance> portion is a DNS label, containing UTF-8-encoded text,
result. 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.
Once the SOA record is available, the discovery procedure extracts For example, TURN server advertises the following DNS records :
the MNAME field, i.e., the responsible master name server from the
SOA record. An example MNAME could be: dns1.isp.example.net. Then,
an S-NAPTR lookup as specified in the previous step Section 4.2 is
performed on this MNAME to discover the TURN service. If no TURN-
specific S-NAPTR records can be retrieved, the discovery procedure
fails for this domain name (and the corresponding interface and IP
protocol version).
5. Discovery using Anycast _turnserver._udp.local. PTR example.com._turnserver._udp.local.
example.com._turnserver._udp.local. SRV 0 0 5030 example-turn-
server.local.
example-turn-server.local. A 192.168.1.2
In addition to the service instance name, IP address and the port
number, DNS-SD provides a way to publish other information pertinent
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
A TURN client tries to discover the TURN servers being advertised in
the site by multicasting a PTR query "_turnserver._udp.local." or
"_turnserver._tcp.local" or the TURN server can send out gratuitous
multicast DNS answer packets whenever it starts up, wakes from sleep,
or detects a chance in network configuration. TURN clients receive
these gratuitous packet and cache the information contained in it.
+------+ +-------------+
| TURN | | TURN Server |
|Client| | |
+------+ +-------------+
| |
| PTR query "_turnserver._udp.local." |
|--------------------------------------------->|
| PTR reply |
|<---------------------------------------------|
| SRV query |
|--------------------------------------------->|
| SRV reply |
|<---------------------------------------------|
| A/AAAA query reply |
|--------------------------------------------->|
| TURN Request |
|--------------------------------------------->|
| TURN Response |
|<---------------------------------------------|
Figure 1: TURN Server Discovery using mDNS
6. Discovery using Anycast
IP anycast is an elegant solution for TURN service discovery. A IP anycast is an elegant solution for TURN service discovery. A
packet sent to an anycast address is delivered to the "topologically packet sent to an anycast address is delivered to the "topologically
nearest" network interface with the anycast address. Using the TURN nearest" network interface with the anycast address. Using the TURN
anycast address, the only two things that need to be deployed in the anycast address, the only two things that need to be deployed in the
network are the two things that actually use TURN. network are the two things that actually use TURN.
When a client requires TURN services, it sends a TURN allocate When a client requires TURN services, it sends a TURN allocate
request to the assigned anycast address. The TURN anycast server request to the assigned anycast address. The TURN anycast server
responds with a 300 (Try Alternate) error as described in [RFC5766]; responds with a 300 (Try Alternate) error as described in [RFC5766];
The response contains the TURN unicast address in the ALTERNATE- The response contains the TURN unicast address in the ALTERNATE-
SERVER attribute. For subsequent communication with the TURN server, SERVER attribute. For subsequent communication with the TURN server,
the client uses the responding server's unicast address. This has to the client uses the responding server's unicast address. This has to
be done because two packets addressed to an anycast address may reach be done because two packets addressed to an anycast address may reach
two different anycast servers. The client, thus, also needs to two different anycast servers. The client, thus, also needs to
ensure that the initial request fits in a single packet. An ensure that the initial request fits in a single packet. An
implementation may choose to send out every new request to the implementation may choose to send out every new request to the
anycast address to learn the closest TURN server each time. anycast address to learn the closest TURN server each time.
6. Deployment Considerations 7. Deployment Considerations
7.1. Mobility and Changing IP addresses
6.1. Mobility and Changing IP addresses
A change of IP address on an interface may invalidate the result of A change of IP address on an interface may invalidate the result of
the TURN server discovery procedure. For instance, if the IP address the TURN server discovery procedure. For instance, if the IP address
assigned to a mobile host changes due to host mobility, it may be assigned to a mobile host changes due to host mobility, it may be
required to re-run the TURN server discovery procedure without required to re-run the TURN server discovery procedure without
relying on earlier gained information. New requests should be made relying on earlier gained information. New requests should be made
to the newly learned TURN servers learned after TURN discovery re- to the newly learned TURN servers learned after TURN discovery re-
run. However, if an earlier learned TURN server is still accessible run. However, if an earlier learned TURN server is still accessible
using the new IP address, procedures described for mobility using using the new IP address, procedures described for mobility using
TURN defined in [I-D.wing-mmusic-ice-mobility] can be used for TURN defined in [I-D.wing-tram-turn-mobility] can be used for ongoing
ongoing streams. streams.
7. IANA Considerations 8. IANA Considerations
7.1. Anycast 8.1. Anycast
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/>
8. Security Considerations 9. Security Considerations
In general, it is recommended that a TURN client authenticate with In general, it is recommended that a TURN client authenticate with
the TURN server to identify a rouge server. [RFC7350] can be the TURN server to identify a rouge server. [RFC7350] can be
potentially used by a client to validate a previously unknown server. potentially used by a client to validate a previously unknown server.
8.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.
An attacker who can control the domain name can also control the An attacker who can control the domain name can also control the
final result. Because more than one method can be used to determine final result. Because more than one method can be used to determine
skipping to change at page 8, line 47 skipping to change at page 10, line 11
If DHCP is used, the integrity of DHCP options is limited by the If DHCP is used, the integrity of DHCP options is limited by the
security of the channel over which they are provided. Physical security of the channel over which they are provided. Physical
security and separation of DHCP messages from other packets are security and separation of DHCP messages from other packets are
commonplace methods that can reduce the possibility of attack within commonplace methods that can reduce the possibility of attack within
an access network; alternatively, DHCP authentication [RFC3188] can an access network; alternatively, DHCP authentication [RFC3188] can
provide a degree of protection against modification. When using DHCP provide a degree of protection against modification. When using DHCP
discovery, clients are encouraged to use unicast DHCP INFORM queries discovery, clients are encouraged to use unicast DHCP INFORM queries
instead of broadcast queries which are more easily spoofed in instead of broadcast queries which are more easily spoofed in
insecure networks. insecure networks.
8.2. Anycast 9.2. DNS Service Discovery
Since DNS-SD is just a specification for how to name and use records
in the existing DNS system, it has no specific additional security
requirements over and above those that already apply to DNS queries
and DNS updates. For DNS queries, DNS Security Extensions (DNSSEC)
[RFC4033] should be used where the authenticity of information is
important. For DNS updates, secure updates [RFC2136][RFC3007] should
generally be used to control which clients have permission to update
DNS records.
For mDNS, in addition to what has been described above, a principal
security threat is a security threat inherent to IP multicast routing
and any application that runs on it. A rogue system can advertise
that it is a TURN server. Discovery of such rogue systems as TURN
servers, in itself, is not a security threat if there is a means for
the TURN client to authenticate and authorize the discovered TURN
servers.
9.3. Anycast
In a network without any TURN server that is aware of the TURN In a network without any TURN server that is aware of the TURN
anycast address, outgoing TURN requests could leak out onto the anycast address, outgoing TURN requests could leak out onto the
external Internet, possibly revealing information. external Internet, possibly revealing information.
Using an IANA-assigned well-known TURN anycast address enables border Using an IANA-assigned well-known TURN anycast address enables border
gateways to block such outgoing packets. In the default-free zone, gateways to block such outgoing packets. In the default-free zone,
routers should be configured to drop such packets. Such routers should be configured to drop such packets. Such
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.
9. Acknowledgements 10. Acknowledgements
Discovery using Service Resolution described in Section 4 of this The authors would like to thank Simon Perrault, Paul Kyzivat and Troy
document was derived from similar techniques described in ALTO Server Shields for their review and valuable comments. Thanks to Adam Roach
Discovery [RFC7286] and [I-D.kist-alto-3pdisc]. for his detailed review and suggesting DNS Service Discovery as an
additional discovery mechanism.
10. References 11. References
10.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, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596, "DNS Extensions to Support IP Version 6", RFC 3596,
October 2003. October 2003.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[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, April 2010.
[RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT
(TURN) Resolution Mechanism", RFC 5928, August 2010. (TURN) Resolution Mechanism", RFC 5928, August 2010.
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", RFC 5986, September Location Information Server (LIS)", RFC 5986, September
2010. 2010.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
February 2013.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013.
[RFC7216] Thomson, M. and R. Bellis, "Location Information Server [RFC7216] Thomson, M. and R. Bellis, "Location Information Server
(LIS) Discovery Using IP Addresses and Reverse DNS", RFC (LIS) Discovery Using IP Addresses and Reverse DNS", RFC
7216, April 2014. 7216, April 2014.
[RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport [RFC7350] 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)", RFC 7350, August 2014. Utilities for NAT (STUN)", RFC 7350, August 2014.
10.2. Informative References 11.2. Informative References
[I-D.ietf-rtcweb-overview] [I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-13 Browser-based Applications", draft-ietf-rtcweb-overview-13
(work in progress), November 2014. (work in progress), November 2014.
[I-D.kist-alto-3pdisc] [I-D.kist-alto-3pdisc]
Kiesel, S., Krause, K., and M. Stiemerling, "Third-Party Kiesel, S., Krause, K., and M. Stiemerling, "Third-Party
ALTO Server Discovery (3pdisc)", draft-kist-alto-3pdisc-05 ALTO Server Discovery (3pdisc)", draft-kist-alto-3pdisc-05
(work in progress), January 2014. (work in progress), January 2014.
[I-D.wing-mmusic-ice-mobility] [I-D.wing-tram-turn-mobility]
Wing, D., Reddy, T., Patil, P., and P. Martinsen, Wing, D., Patil, P., Reddy, T., and P. Martinsen,
"Mobility with ICE (MICE)", draft-wing-mmusic-ice- "Mobility with TURN", draft-wing-tram-turn-mobility-03
mobility-07 (work in progress), June 2014. (work in progress), May 2015.
[RFC3188] Hakala, J., "Using National Bibliography Numbers as [RFC3188] Hakala, J., "Using National Bibliography Numbers as
Uniform Resource Names", RFC 3188, October 2001. Uniform Resource Names", RFC 3188, October 2001.
[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, March 2008. Translators (NATs)", RFC 5128, March 2008.
[RFC7286] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and [RFC7286] Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and
H. Song, "Application-Layer Traffic Optimization (ALTO) H. Song, "Application-Layer Traffic Optimization (ALTO)
skipping to change at page 11, line 5 skipping to change at page 13, line 5
A.1. Change from draft-patil-tram-serv-disc-00 to -01 A.1. Change from draft-patil-tram-serv-disc-00 to -01
o Added IP address (Section 4.1.2) and Own identity (4.1.3) as new o Added IP address (Section 4.1.2) and Own identity (4.1.3) as new
means to obtain domain names means to obtain domain names
o New Section 4.2.1 SOA (inspired by draft-kist-alto-3pdisc) o New Section 4.2.1 SOA (inspired by draft-kist-alto-3pdisc)
o 300 (Try Alternate) response for Anycast o 300 (Try Alternate) response for Anycast
A.2. Change from draft-ietf-tram-turn-server-discovery-01 to 02
o Removed sections that describe reverse IP lookup
o Added DNS Service Discovery as an additional discovery mechanism
Authors' Addresses Authors' Addresses
Prashanth Patil Prashanth Patil
Cisco Systems, Inc. Cisco Systems, Inc.
Bangalore Bangalore
India India
Email: praspati@cisco.com Email: praspati@cisco.com
Tirumaleswar Reddy Tirumaleswar Reddy
 End of changes. 41 change blocks. 
109 lines changed or deleted 204 lines changed or added

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