TRAM                                                            P. Patil
Internet-Draft                                                  T. Reddy
Intended status: Standards Track                                 D. Wing
Expires: July 26, November 14, 2015                                         Cisco
                                                        January 22,
                                                            May 13, 2015

                       TURN Server Auto Discovery


   Current Traversal Using Relays around NAT (TURN) server discovery
   mechanisms are relatively static and limited to explicit
   configuration.  These are usually under the administrative control of
   the application or TURN service provider, and not the enterprise or
   the enterprise,
   ISP, or the network in which the client is located.  Enterprises and
   ISPs wishing to provide their own TURN servers need auto discovery
   mechanisms that a TURN client could use with no or minimal
   configuration.  This document describes two three such mechanisms for
   TURN server discovery.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 26, November 14, 2015.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Discovery Procedure . . . . . . . . . . . . . . . . . . . . .   3
   4.  Discovery using Service Resolution  . . . . . . . . . . . . .   4
     4.1.  Retrieving Domain Name  . . . . . . . . . . . . . . . . .   4
       4.1.1.  DHCP  . . . . . . . . . . . . . . . . . . . . . . . .   4   5
       4.1.2.  IP Address  From own Identity . . . . . . . . . . . . . . . . . .   5
     4.2.  Resolution  . . .   5
       4.1.3.  From own Identity . . . . . . . . . . . . . . . . . .   5
     4.2.  Resolution . .   5
   5.  DNS Service Discovery . . . . . . . . . . . . . . . . . . . .   6
     5.1.  mDNS  .   5
       4.2.1.  SOA . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.   7
   6.  Discovery using Anycast . . . . . . . . . . . . . . . . . . .   7
   6.   8
   7.  Deployment Considerations . . . . . . . . . . . . . . . . . .   7
     6.1.   8
     7.1.  Mobility and Changing IP addresses  . . . . . . . . . . .   7
   7.   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     7.1.   9
     8.1.  Anycast . . . . . . . . . . . . . . . . . . . . . . . . .   8
   8.   9
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
     8.1.   9
     9.1.  Service Resolution  . . . . . . . . . . . . . . . . . . .   8
     8.2.   9
     9.2.  DNS Service Discovery . . . . . . . . . . . . . . . . . .  10
     9.3.  Anycast . . . . . . . . . . . . . . . . . . . . . . . . .   8
   9.  10
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   10.  10
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     10.1.  11
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     10.2.  11
     11.2.  Informative References . . . . . . . . . . . . . . . . .  10  12
   Appendix A.  Change History . . . . . . . . . . . . . . . . . . .  10  12
     A.1.  Change from draft-patil-tram-serv-disc-00 to -01  . . . .  10  12
     A.2.  Change from draft-ietf-tram-turn-server-discovery-01 to
           02  . . . . . . . . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11  13

1.  Introduction

   TURN [RFC5766] is a protocol that is often used to improve the
   connectivity of Peer-to-Peer (P2P) applications (as defined in
   section 2.7 of [RFC5128]).  TURN allows a connection to be
   established when one or both sides are incapable of a direct P2P
   connection.  It is an important building block for interactive, real-
   time communication using audio, video, collaboration etc.  While TURN
   services are extensively used today, the means to auto discover TURN
   servers do not exist.  TURN clients are usually explicitly configured
   with a well known TURN server.  To allow TURN applications operate
   seamlessly across different types of networks and encourage the use
   of TURN without the need for manual configuration, it is important
   that there exists an auto discovery mechanism for TURN services.  Web
   Real-Time Communication (WebRTC) [I-D.ietf-rtcweb-overview] usages
   and related extensions, which are mostly based on web applications,
   need this immediately.

   This document describes two three discovery mechanisms.  The reason for
   providing two multiple mechanisms is to maximize the opportunity for
   discovery, based on the network in the which the TURN client sees finds

   o  A resolution mechanism based on straightforward Naming Authority
      Pointer (S-NAPTR) resource records in the Domain Name System
      (DNS).  [RFC5928] describes details on retrieving a list of server
      transport addresses from DNS that can be used to create a TURN

   o  DNS Service Discovery

   o  A mechanism based on anycast address for TURN.

   In general, if a client wishes to communicate using one of its
   interfaces using a specific IP address family, it SHOULD query the
   TURN server(s) that has been discovered for that specific interface
   and address family.  How to select an interface and IP address
   family, is out of the scope of this document.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

3.  Discovery Procedure

   A TURN client that implements the auto discovery algorithm MUST
   proceed with discovery in uses the
   following order: mechanisms for discovery:

   1.  Local Configuration : Local or manual configuration should be
       tried first, as it may be an explicit preferred choice of a user.
       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 every address family.

   2.  Service Resolution : Service Resolution : The TURN client
       attempts to perform TURN service resolution using the host's DNS domain name that the host
       belongs to OR the hosts' global IP address.  The TURN client will
       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.  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.

   While it is expected that Step-3

   Not all TURN servers may be performed if Step-2 fails, an discovered using NAPTR records or DNS SD;
   Similarly, not all TURN servers may support anycast.  For best
   results, a client MUST implement all discovery mechanisms described

   The document does not prescribe a strict order that a client must
   follow for discovery.  An implementation may choose to perform steps 2
   2,3 and 3 in parallel.

4.  Discovery using Service Resolution

   This mechanism is performed 4 in two steps:

   1.  A DNS domain name is retrieved parallel for each 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

4.  Discovery using Service Resolution

   This mechanism is performed in two steps:

   1.  A DNS domain name is retrieved for each combination of interface
   and address family.

   2.  Retrieved DNS domain names are then used for S-NAPTR lookups as
   per [RFC5928].  Further DNS lookups may be necessary to determine
   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

   The domain,

   A client has to determine the domain in which the client it is located, can be determined using
   one located.  The
   following sections provide two possible mechanisms to learn the
   domain name, but other means of retrieving domain names may be used,
   which are outside the techniques provided below.  An implementation can choose
   to use any or all techniques. scope of this document e.g. local

   Implementations may allow the user to specify a default name that is
   used if no specific name has been configured.  Other means of
   retrieving domain names may be used, which are outside the scope of
   this document e.g. local configuration.

4.1.1.  DHCP

   DHCP can be used to determine the domain name related to an
   interface's point of network attachment.  Network operators may
   provide the domain name to be used for service discovery within an
   access network using DHCP.  [RFC5986] defines DHCP IPv4 and IPv6
   access network domain name options to identify a domain name that is
   suitable for service discovery within the access network.  [RFC2132]
   defines the DHCP IPv4 domain name option.  While this option is less
   suitable, it still may be useful if the option defined in [RFC5986]
   is not available.

   For IPv6, the TURN server discovery procedure MUST try to retrieve
   DHCP option 57 (OPTION_V6_ACCESS_DOMAIN).  If no such option can be
   retrieved, the procedure fails for this interface.  For IPv4, the
   TURN server discovery procedure MUST try to retrieve DHCP option 213
   (OPTION_V4_ACCESS_DOMAIN).  If no such option can be retrieved, the
   procedure SHOULD try to retrieve option 15 (Domain Name).  If neither
   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

4.1.2.  IP Address

   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
   identity i.e canonical identifier used to reach the user.


   SIP   : ''
   JID   : ''
   email : ''

   '' is retrieved from the above examples.

   The means to extract the domain name may be different based on the
   type of identifier and is outside the scope of this document.

4.2.  Resolution

   Once the TURN discovery procedure has retrieved domain names, the
   resolution mechanism described in [RFC5928] is followed.  An S-NAPTR
   lookup with 'RELAY' application service and the desired protocol tag
   is made to obtain information necessary to connect to the
   authoritative TURN server within the given domain.

   In the example below, for domain '', the resolution
   algorithm will result in IP address, port, and protocol tuples as
      IN NAPTR 100 10 "" RELAY:turn.udp ""
      IN NAPTR 100 10 S RELAY:turn.udp ""
      IN SRV   0 0 3478
      IN A

                    | Order | Protocol | IP address | Port |
                    | 1     | UDP      |  | 3478 |

   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).  If more domain names are known, the
   discovery procedure may perform the corresponding S-NAPTR lookups
   immediately.  However, before retrying a lookup that has failed, a
   client MUST wait a time period that is appropriate for the
   encountered error (NXDOMAIN, timeout, etc.).

4.2.1.  SOA

   If no TURN-specific S-NAPTR records can be retrieved using the
   previous step, additional steps described

5.  DNS Service Discovery

   DNS-based Service Discovery (DNS-SD) [RFC6763] and Multicast DNS
   (mDNS) [RFC6762] provide generic solutions for discovering services
   available in this section have to be
   followed.  First, an SOA a local network.  DNS-SD/ mDNS define a set of naming
   rules for certain DNS record types that they use for advertising and
   discovering services.  PTR records are used to enumerate service
   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 "reverse zone" i.e., host name and
   port number contained in its SRV record, the zone additional information
   is carried in a TXT record.

   Section 4.1 of [RFC6763] specifies that a service instance name in
   DNS-SD has the following structure:

   <Instance> . <Service> . <Domain>
   The <Domain> portion specifies the DNS sub-domain where the service
   instance is registered.  It may be "local.", indicating the mDNS
   local domain, or it may be a conventional domain that contains name such as
   "".  The <Service> portion of the IP
   address(s) TURN service instance
   name MUST be "_turnserver._udp", "_turnserver._tcp".

   The <Instance> portion is a DNS label, containing UTF-8-encoded text,
   limited to 63 octets in question, has length.  It is meant to be retrieved.  IP addresses a user-friendly
   description of the service instance, suitable for a menu-like user
   interface display.  Thus it can be
   determined, if not done already, contain any characters including
   spaces, punctuation, and non-Latin characters as described long as they can be
   encoded in Section 4.1.2. UTF-8.

   For example, TURN server advertises the following DNS records :

      _turnserver._udp.local.  PTR  SRV 0 0 5030 example-turn-

      example-turn-server.local.  A sample SOA record could be:
      IN  SOA (
                                    1         ; Serial
                               604800         ; Refresh
                                86400         ; Retry
                              2419200         ; Expire
                               604800 )       ; Negative Cache TTL

   If this lookup fails,

   In addition to the discovery procedure is aborted without service instance name, IP address and the port
   number, DNS-SD provides a

   Once way to publish other information pertinent
   to the SOA service being advertised.  The additional data can be stored
   as name/value attributes in a TXT record is available, with the discovery procedure extracts same name as the MNAME field, i.e.,
   SRV record for the responsible master name server from service.  Each name/value pair within the
   SOA record.  An example MNAME could be:  Then,
   an S-NAPTR lookup as specified in TXT
   record is preceded by a single length byte, thereby limiting the previous step
   length of the pair to 255 bytes (See Section 4.2 is
   performed on this MNAME 6 of [RFC6763] and
   Section 3.3.14 of [RFC1035] for details).

5.1.  mDNS

   A TURN client tries 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. 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
   packet sent to an anycast address is delivered to the "topologically
   nearest" network interface with the anycast address.  Using the TURN
   anycast address, the only two things that need to be deployed in the
   network are the two things that actually use TURN.

   When a client requires TURN services, it sends a TURN allocate
   request to the assigned anycast address.  The TURN anycast server
   responds with a 300 (Try Alternate) error as described in [RFC5766];
   The response contains the TURN unicast address in the ALTERNATE-
   SERVER attribute.  For subsequent communication with the TURN server,
   the client uses the responding server's unicast address.  This has to
   be done because two packets addressed to an anycast address may reach
   two different anycast servers.  The client, thus, also needs to
   ensure that the initial request fits in a single packet.  An
   implementation may choose to send out every new request to the
   anycast address to learn the closest TURN server each time.


7.  Deployment Considerations

7.1.  Mobility and Changing IP addresses

   A change of IP address on an interface may invalidate the result of
   the TURN server discovery procedure.  For instance, if the IP address
   assigned to a mobile host changes due to host mobility, it may be
   required to re-run the TURN server discovery procedure without
   relying on earlier gained information.  New requests should be made
   to the newly learned TURN servers learned after TURN discovery re-
   run.  However, if an earlier learned TURN server is still accessible
   using the new IP address, procedures described for mobility using
   TURN defined in [I-D.wing-mmusic-ice-mobility] [I-D.wing-tram-turn-mobility] can be used for ongoing


8.  IANA Considerations


8.1.  Anycast

   IANA should allocate an IPv4 and an IPv6 well-known TURN anycast
   address. and 2001:0000::/48 are reserved for IETF
   Protocol Assignments, as listed at

   <> and



9.  Security Considerations

   In general, it is recommended that a TURN client authenticate with
   the TURN server to identify a rouge server.  [RFC7350] can be
   potentially used by a client to validate a previously unknown server.


9.1.  Service Resolution

   The primary attack against the methods described in this document is
   one that would lead to impersonation of a TURN server.  An attacker
   could attempt to compromise the S-NAPTR resolution.  Security
   considerations described in [RFC5928] are applicable here as well.

   In addition to considerations related to S-NAPTR, it is important to
   recognize that the output of this is entirely dependent on its input.
   An attacker who can control the domain name can also control the
   final result.  Because more than one method can be used to determine
   the domain name, a host implementation needs to consider attacks
   against each of the methods that are used.

   If DHCP is used, the integrity of DHCP options is limited by the
   security of the channel over which they are provided.  Physical
   security and separation of DHCP messages from other packets are
   commonplace methods that can reduce the possibility of attack within
   an access network; alternatively, DHCP authentication [RFC3188] can
   provide a degree of protection against modification.  When using DHCP
   discovery, clients are encouraged to use unicast DHCP INFORM queries
   instead of broadcast queries which are more easily spoofed in
   insecure networks.


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

9.3.  Anycast

   In a network without any TURN server that is aware of the TURN
   anycast address, outgoing TURN requests could leak out onto the
   external Internet, possibly revealing information.

   Using an IANA-assigned well-known TURN anycast address enables border
   gateways to block such outgoing packets.  In the default-free zone,
   routers should be configured to drop such packets.  Such
   configuration can occur naturally via BGP messages advertising that
   no route exists to said address.

   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
   they can travel into the public Internet.


10.  Acknowledgements

   Discovery using

   The authors would like to thank Simon Perrault, Paul Kyzivat and Troy
   Shields for their review and valuable comments.  Thanks to Adam Roach
   for his detailed review and suggesting DNS Service Resolution described in Section 4 of this
   document was derived from similar techniques described in ALTO Server Discovery [RFC7286] and [I-D.kist-alto-3pdisc].

10. as an
   additional discovery mechanism.

11.  References


11.1.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              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,
              "DNS Extensions to Support IP Version 6", RFC 3596,
              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
              Relays around NAT (TURN): Relay Extensions to Session
              Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.

   [RFC5928]  Petit-Huguenin, M., "Traversal Using Relays around NAT
              (TURN) Resolution Mechanism", RFC 5928, August 2010.

   [RFC5986]  Thomson, M. and J. Winterbottom, "Discovering the Local
              Location Information Server (LIS)", RFC 5986, September

   [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
              (LIS) Discovery Using IP Addresses and Reverse DNS", RFC
              7216, April 2014.

   [RFC7350]  Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport
              Layer Security (DTLS) as Transport for Session Traversal
              Utilities for NAT (STUN)", RFC 7350, August 2014.


11.2.  Informative References

              Alvestrand, H., "Overview: Real Time Protocols for
              Browser-based Applications", draft-ietf-rtcweb-overview-13
              (work in progress), November 2014.

              Kiesel, S., Krause, K., and M. Stiemerling, "Third-Party
              ALTO Server Discovery (3pdisc)", draft-kist-alto-3pdisc-05
              (work in progress), January 2014.


              Wing, D., Reddy, T., Patil, P., Reddy, T., and P. Martinsen,
              "Mobility with ICE (MICE)", draft-wing-mmusic-ice-
              mobility-07 TURN", draft-wing-tram-turn-mobility-03
              (work in progress), June 2014. May 2015.

   [RFC3188]  Hakala, J., "Using National Bibliography Numbers as
              Uniform Resource Names", RFC 3188, October 2001.

   [RFC5128]  Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-
              Peer (P2P) Communication across Network Address
              Translators (NATs)", RFC 5128, March 2008.

   [RFC7286]  Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and
              H. Song, "Application-Layer Traffic Optimization (ALTO)
              Server Discovery", RFC 7286, November 2014.

Appendix A.  Change History

   [Note to RFC Editor: Please remove this section prior to

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
      means to obtain domain names

   o  New Section 4.2.1 SOA (inspired by draft-kist-alto-3pdisc)

   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

   Prashanth Patil
   Cisco Systems, Inc.


   Tirumaleswar Reddy
   Cisco Systems, Inc.
   Cessna Business Park, Varthur Hobli
   Sarjapur Marathalli Outer Ring Road
   Bangalore, Karnataka  560103


   Dan Wing
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, California  95134