One document matched: draft-ietf-tram-turn-server-discovery-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-tram-turn-server-discovery-02"
ipr="trust200902">
<front>
<title abbrev="TURN server auto disc">TURN Server Auto Discovery</title>
<author fullname="Prashanth Patil" initials="P." surname="Patil">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street/>
<street/>
<city>Bangalore</city>
<country>India</country>
</postal>
<email>praspati@cisco.com</email>
</address>
</author>
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Cessna Business Park, Varthur Hobli</street>
<street>Sarjapur Marathalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>tireddy@cisco.com</email>
</address>
</author>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>California</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<date/>
<workgroup>TRAM</workgroup>
<abstract>
<t>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, 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
three such mechanisms for TURN server discovery.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>TURN <xref target="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 <xref target="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) <xref target="I-D.ietf-rtcweb-overview"/> usages and related
extensions, which are mostly based on web applications, need this
immediately.</t>
<t>This document describes three discovery mechanisms. The reason for
providing multiple mechanisms is to maximize the opportunity for
discovery, based on the network in the which the TURN client finds
itself.</t>
<t><list style="symbols">
<t>A resolution mechanism based on straightforward Naming Authority
Pointer (S-NAPTR) resource records in the Domain Name System (DNS).
<xref target="RFC5928"/> describes details on retrieving a list of
server transport addresses from DNS that can be used to create a
TURN allocation.</t>
<t>DNS Service Discovery</t>
<t>A mechanism based on anycast address for TURN.</t>
</list>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.</t>
</section>
<section anchor="term" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/>.</t>
</section>
<section title="Discovery Procedure">
<t>A TURN client that implements the auto discovery algorithm uses the
following mechanisms for discovery:</t>
<t><list style="numbers">
<t>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.</t>
<t>Service Resolution : Service Resolution : The TURN client
attempts to perform TURN service resolution using the host's DNS
domain.</t>
<t>DNS Service Discovery (DNS SD)</t>
<t>Anycast : Send TURN allocate request to the assigned TURN anycast
request for each combination of interface and address family.</t>
</list></t>
<t>Not all TURN servers may be 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 above.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Discovery using Service Resolution">
<t>This mechanism is performed in two steps:</t>
<t>1. A DNS domain name is retrieved for each combination of interface
and address family.</t>
<t>2. Retrieved DNS domain names are then used for S-NAPTR lookups as
per <xref target="RFC5928"/>. Further DNS lookups may be necessary to
determine TURN server IP address(es).</t>
<section title="Retrieving Domain Name">
<t>A client has to determine the domain in which it is 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 scope of this document e.g. local configuration.</t>
<t>Implementations may allow the user to specify a default name that
is used if no specific name has been configured.</t>
<section title="DHCP">
<t>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. <xref target="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. <xref target="RFC2132"/> defines the DHCP IPv4 domain name
option. While this option is less suitable, it still may be useful
if the option defined in <xref target="RFC5986"/> is not
available.</t>
<t>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 resolution.</t>
</section>
<section title="From own Identity">
<t>A TURN client could also wish to extract the domain name from its
own identity i.e canonical identifier used to reach the user.</t>
<t><figure>
<artwork><![CDATA[Example
SIP : 'sip:alice@example.com'
JID : 'alice@example.com'
email : 'alice@example.com'
'example.com' is retrieved from the above examples.]]></artwork>
</figure></t>
<t>The means to extract the domain name may be different based on
the type of identifier and is outside the scope of this
document.</t>
</section>
</section>
<section title="Resolution">
<t>Once the TURN discovery procedure has retrieved domain names, the
resolution mechanism described in <xref target="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.</t>
<t>In the example below, for domain 'example.net', the resolution
algorithm will result in IP address, port, and protocol tuples as
follows:</t>
<t><figure>
<artwork><![CDATA[example.net.
IN NAPTR 100 10 "" RELAY:turn.udp "" example.net.
example.net.
IN NAPTR 100 10 S RELAY:turn.udp "" _turn._udp.example.net.
_turn._udp.example.net.
IN SRV 0 0 3478 a.example.net.
a.example.net.
IN A 192.0.2.1
+-------+----------+------------+------+
| Order | Protocol | IP address | Port |
+-------+----------+------------+------+
| 1 | UDP | 192.0.2.1 | 3478 |
+-------+----------+------------+------+
]]></artwork>
</figure>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.).</t>
</section>
</section>
<section title="DNS Service Discovery">
<t>DNS-based Service Discovery (DNS-SD) <xref target="RFC6763"/> and
Multicast DNS (mDNS) <xref target="RFC6762"/> provide generic solutions
for discovering services 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 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 host name
and port number contained in its SRV record, the additional information
is carried in a TXT record.</t>
<t>Section 4.1 of <xref target="RFC6763"/> specifies that a service
instance name in DNS-SD has the following structure:</t>
<t><Instance> . <Service> . <Domain></t>
<t>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 name such as
"example.com.". The <Service> portion of the TURN service instance
name MUST be "_turnserver._udp", "_turnserver._tcp".</t>
<t>The <Instance> portion is a DNS label, containing UTF-8-encoded
text, 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.</t>
<t>For example, TURN server advertises the following DNS records :</t>
<t><figure>
<artwork><![CDATA[ _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]]></artwork>
</figure></t>
<t>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 <xref target="RFC6763"/> and Section
3.3.14 of <xref target="RFC1035"/> for details).</t>
<section title="mDNS">
<t>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.</t>
<t><figure>
<artwork><![CDATA[ +------+ +-------------+
| 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]]></artwork>
</figure></t>
</section>
</section>
<section title="Discovery using Anycast">
<t>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.</t>
<t>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 <xref
target="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.</t>
</section>
<section title="Deployment Considerations">
<section title="Mobility and Changing IP addresses">
<t>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 <xref target="I-D.wing-tram-turn-mobility"/> can be used
for ongoing streams.</t>
</section>
</section>
<section anchor="iana" title="IANA Considerations">
<section title="Anycast">
<t>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
Protocol Assignments, as listed at</t>
<t><http://www.iana.org/assignments/iana-ipv4-special-registry/>
and</t>
<t><http://www.iana.org/assignments/iana-ipv6-special-registry/></t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>In general, it is recommended that a TURN client authenticate with
the TURN server to identify a rouge server. <xref target="RFC7350">
</xref> can be potentially used by a client to validate a previously
unknown server.</t>
<section title="Service Resolution">
<t>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 <xref target="RFC5928"/> are applicable
here as well.</t>
<t>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.</t>
<t>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 <xref
target="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.</t>
</section>
<section title="DNS Service Discovery">
<t>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) <xref target="RFC4033"/> should be used where the
authenticity of information is important. For DNS updates, secure
updates <xref target="RFC2136"/><xref target="RFC3007"/> should
generally be used to control which clients have permission to update
DNS records.</t>
<t>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.</t>
</section>
<section title="Anycast">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
</section>
<section anchor="ack" title="Acknowledgements">
<t>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 Discovery as an
additional discovery mechanism.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.5766"?>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.5986"?>
<?rfc include="reference.RFC.2132"
?>
<?rfc include="reference.RFC.1035"?>
<?rfc include="reference.RFC.5928"
?>
<?rfc include="reference.RFC.3596"?>
<?rfc include="reference.RFC.7350"?>
<?rfc include="reference.RFC.6762"?>
<?rfc include="reference.RFC.6763"?>
<?rfc include="reference.RFC.7216"
?>
<?rfc include="reference.RFC.4033"
?>
<?rfc include="reference.RFC.2136"
?>
<?rfc include="reference.RFC.3007"
?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.7286"?>
<?rfc include="reference.RFC.3188"?>
<?rfc include="reference.RFC.5128"?>
<?rfc include="reference.I-D.kist-alto-3pdisc"?>
<?rfc include='reference.I-D.ietf-rtcweb-overview'?>
<?rfc include="reference.I-D.wing-tram-turn-mobility"?>
<!---->
</references>
<section title="Change History">
<t>[Note to RFC Editor: Please remove this section prior to
publication.]</t>
<section title="Change from draft-patil-tram-serv-disc-00 to -01">
<t><list style="symbols">
<t>Added IP address (Section 4.1.2) and Own identity (4.1.3) as
new means to obtain domain names</t>
<t>New Section 4.2.1 SOA (inspired by draft-kist-alto-3pdisc)</t>
<t>300 (Try Alternate) response for Anycast</t>
</list></t>
</section>
<section title="Change from draft-ietf-tram-turn-server-discovery-01 to 02">
<t><list style="symbols">
<t>Removed sections that describe reverse IP lookup</t>
<t>Added DNS Service Discovery as an additional discovery
mechanism</t>
</list></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:50:17 |