draft-ietf-tram-turn-server-discovery-06.txt   draft-ietf-tram-turn-server-discovery-07.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 9, 2016 Cisco Expires: October 20, 2016 Cisco
January 6, 2016 April 18, 2016
TURN Server Auto Discovery TURN Server Auto Discovery
draft-ietf-tram-turn-server-discovery-06 draft-ietf-tram-turn-server-discovery-07
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 July 9, 2016. This Internet-Draft will expire on October 20, 2016.
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 23 skipping to change at page 2, line 23
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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 5
5. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 6 5. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 6
5.1. mDNS . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. mDNS . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Discovery using Anycast . . . . . . . . . . . . . . . . . . . 8 6. Discovery using Anycast . . . . . . . . . . . . . . . . . . . 8
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . 10
9.2. DNS Service Discovery . . . . . . . . . . . . . . . . . . 11 9.2. DNS Service Discovery . . . . . . . . . . . . . . . . . . 11
9.3. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.3. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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. time communication using audio, video, collaboration etc.
skipping to change at page 3, line 38 skipping to change at page 3, line 38
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 family and address family. How to select an interface and IP address family
is out of the scope of this document. 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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
3. Discovery Procedure 3. Discovery Procedure
A TURN client that implements the auto discovery algorithm uses the A TURN client that implements the auto discovery algorithm uses the
following mechanisms for discovery: following mechanisms for discovery:
1. Local Configuration : Local or manual TURN configuration i.e., 1. Local Configuration : Local or manual TURN configuration i.e.,
TURN servers configured at the system level. For example, in TURN servers configured at the system level. For example, in
case of Web Real-Time Communication (WebRTC) case of Web Real-Time Communication (WebRTC)
[I-D.ietf-rtcweb-overview] usages and related extensions, which [I-D.ietf-rtcweb-overview] usages and related extensions, which
skipping to change at page 6, line 21 skipping to change at page 6, line 21
example.net. example.net.
IN NAPTR 100 10 "" RELAY:turn.udp "" example.net. IN NAPTR 100 10 "" RELAY:turn.udp "" example.net.
example.net. example.net.
IN NAPTR 100 10 S RELAY:turn.udp "" _turn._udp.example.net. IN NAPTR 100 10 S RELAY:turn.udp "" _turn._udp.example.net.
_turn._udp.example.net. _turn._udp.example.net.
IN SRV 0 0 3478 a.example.net. IN SRV 0 0 3478 a.example.net.
a.example.net. a.example.net.
IN A 192.0.2.1 IN A 192.0.2.1
IN AAAA 2001:db8:8:4::2
+-------+----------+------------+------+ +-------+----------+------------------+------+
| Order | Protocol | IP address | Port | | Order | Protocol | IP address | Port |
+-------+----------+------------+------+ +-------+----------+------------------+------+
| 1 | UDP | 192.0.2.1 | 3478 | | 1 | UDP | 192.0.2.1 | 3478 |
+-------+----------+------------+------+ +-------+----------+------------------+------+
| 2 | UDP | 2001:db8:8:4::2 | 3478 |
+-------+----------+------------------+------+
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.).
5. DNS Service Discovery 5. DNS Service Discovery
skipping to change at page 7, line 32 skipping to change at page 7, line 34
For example, TURN server advertises the following DNS records : For example, TURN server advertises the following DNS records :
_turnserver._udp.local. PTR example.com._turnserver._udp.local. _turnserver._udp.local. PTR example.com._turnserver._udp.local.
example.com._turnserver._udp.local. SRV 0 0 5030 example-turn- example.com._turnserver._udp.local. SRV 0 0 5030 example-turn-
server.local. server.local.
example-turn-server.local. A 198.51.100.2 example-turn-server.local. A 198.51.100.2
example-turn-server.local. AAAA 2001:db8:8:4::2
In addition to the service instance name, IP address and the port In addition to the service instance name, IP address and the port
number, DNS-SD provides a way to publish other information pertinent number, DNS-SD provides a way to publish other information pertinent
to the service being advertised. The additional data can be stored 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 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 SRV record for the service. Each name/value pair within the TXT
record is preceded by a single length byte, thereby limiting the record is preceded by a single length byte, thereby limiting the
length of the pair to 255 bytes (See Section 6 of [RFC6763] and length of the pair to 255 bytes (See Section 6 of [RFC6763] and
Section 3.3.14 of [RFC1035] for details). Section 3.3.14 of [RFC1035] for details).
5.1. mDNS 5.1. mDNS
skipping to change at page 9, line 19 skipping to change at page 9, line 22
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.ietf-tram-turn-mobility] can be used for ongoing TURN defined in [I-D.ietf-tram-turn-mobility] can be used for ongoing
streams. streams.
7.2. Recursively Encapsulated TURN 7.2. Recursively Encapsulated TURN
A TURN client could attempt to discover multiple TURN servers so as WebRTC endpoints SHOULD treat any TURN server discovered through the
to use recursively encapsulated TURN, as described in mechanims described in this specification as an enterprise/gateway
[I-D.ietf-rtcweb-return], to route traffic through multiple TURN server, in accordance with Recursively Encapsulated TURN
servers for privacy. [I-D.ietf-rtcweb-return].
8. IANA Considerations 8. IANA Considerations
8.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/>
9. Security Considerations 9. Security Considerations
Clients can use TURN servers provided by the local network or by the Use of STUN authentication is OPTIONAL for TURN servers provided by
access network without authenticating with the TURN server. It is the local network or by the access network. A network provided TURN
recommended that clients use (D)TLS with network provided TURN server MAY be configured to accept Allocation requests without STUN
servers to validate the TURN server and prevent man-in-middle authentication, and a TURN client MAY be configured to accept
attacks. A TURN client may use the following techniques to validate Allocation success responses without STUN authentication from a
a TURN server: network provided TURN server. In order to protect against man-in-
the-middle attacks when accepting a TURN allocation response without
STUN authentication, it is RECOMMENDED that the TURN client use one
of the following techniques with (D)TLS to validate the TURN server:
o For certificate-based authentication, a pre-populated trust anchor o For certificate-based authentication, a pre-populated trust anchor
store [RFC6024] allows a TURN client to perform path validation store [RFC6024] allows a TURN client to perform path validation
for the server certificate obtained during the (D)TLS handshake. for the server certificate obtained during the (D)TLS handshake.
If the client used a domain name to discover the TURN server, that If the client used a domain name to discover the TURN server, that
domain name also provides a mechanism for validation of the TURN domain name also provides a mechanism for validation of the TURN
server. The client MUST use the rules and guidelines given in server. The client MUST use the rules and guidelines given in
section 6 of [RFC6125] to validate the TURN server identity. section 6 of [RFC6125] to validate the TURN server identity.
o For TURN servers that don't have a certificate trust chain (e.g., o For TURN servers that don't have a certificate trust chain (e.g.,
because they are on a home network or a corporate network), a because they are on a home network or a corporate network), a
configured list of TURN servers can contain the Subject Public Key configured list of TURN servers can contain the Subject Public Key
Info (SPKI) fingerprint of the TURN servers. The public key is Info (SPKI) fingerprint of the TURN servers. The public key is
used for the same reasons HTTP pinning [RFC7469] uses the public used for the same reasons HTTP pinning [RFC7469] uses the public
key. key.
o Raw public key-based authentication, as defined in [RFC7250], o Raw public key-based authentication, as defined in [RFC7250],
could also be used to authenticate a TURN server. could also be used to authenticate a TURN server.
o For opportunistic privacy, analogous to SMTP opportunistic An auto-discovered TURN server is considered to be only as trusted as
encryption [RFC7435] one does not require privacy, but one desires the path between the client and the TURN server. In order to safely
privacy when possible. With opportunistic privacy, a client might use auto-discovered TURN servers for sessions with 'strict privacy'
learn of a TLS-enabled TURN server from an untrusted source and requirements, the user needs to be able to define privacy criteria
may not be able to validate the TLS certificate. These choices (e.g. a trusted list of servers, networks, or domains) that are
maximize availability and performance, but they leave the client considered acceptable for such traffic. Any discovered TURN server
vulnerable to on-path attacks that remove privacy. Opportunistic outside the criteria is considered untrusted and is not used for
privacy can be used by any current client, but it only provides privacy sensitive communication.
guaranteed privacy when there are no on-path active attackers.
In some auto-discovery scenarios, it might not be possible for the
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
client open to on-path injection of spoofed TURN messages. For this
reason, it is beneficial for the TURN client to make use of
'opportunistic privacy', analogous to SMTP opportunistic encryption
[RFC7435], where one does not require privacy but one desires privacy
when possible. In this scenario, a TURN client attempts (D)TLS with
authentication and encryption, falling back to encryption-only if the
TURN server cannot be authenticated via (D)TLS. If the TURN server
does not support unauthenticated (D)TLS, then the client falls back
to clear text. Fallback to clear text is NOT RECOMMENDED because it
makes the client more susceptible to man-in-the-middle attacks and
on-path packet injection. A TURN client SHOULD fall-back to
encryption-only (D)TLS when (D)TLS authentication is not available in
order to protect against on-path attackers who might attempt to
inject fake 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.
skipping to change at page 13, line 17 skipping to change at page 13, line 37
<http://www.rfc-editor.org/info/rfc6762>. <http://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>. <http://www.rfc-editor.org/info/rfc6763>.
11.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-14 Browser-based Applications", draft-ietf-rtcweb-overview-15
(work in progress), June 2015. (work in progress), January 2016.
[I-D.ietf-rtcweb-return] [I-D.ietf-rtcweb-return]
Schwartz, B. and J. Uberti, "Recursively Encapsulated TURN Schwartz, B. and J. Uberti, "Recursively Encapsulated TURN
(RETURN) for Connectivity and Privacy in WebRTC", draft- (RETURN) for Connectivity and Privacy in WebRTC", draft-
ietf-rtcweb-return-00 (work in progress), May 2015. ietf-rtcweb-return-01 (work in progress), January 2016.
[I-D.ietf-tram-turn-mobility] [I-D.ietf-tram-turn-mobility]
Wing, D., Patil, P., Reddy, T., and P. Martinsen, Wing, D., Patil, P., Reddy, T., and P. Martinsen,
"Mobility with TURN", draft-ietf-tram-turn-mobility-00 "Mobility with TURN", draft-ietf-tram-turn-mobility-02
(work in progress), November 2015. (work in progress), April 2016.
[RFC3188] Hakala, J., "Using National Bibliography Numbers as [RFC3188] Hakala, J., "Using National Bibliography Numbers as
Uniform Resource Names", RFC 3188, DOI 10.17487/RFC3188, Uniform Resource Names", RFC 3188, DOI 10.17487/RFC3188,
October 2001, <http://www.rfc-editor.org/info/rfc3188>. October 2001, <http://www.rfc-editor.org/info/rfc3188>.
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-
Peer (P2P) Communication across Network Address Peer (P2P) Communication across Network Address
Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March Translators (NATs)", RFC 5128, DOI 10.17487/RFC5128, March
2008, <http://www.rfc-editor.org/info/rfc5128>. 2008, <http://www.rfc-editor.org/info/rfc5128>.
 End of changes. 16 change blocks. 
41 lines changed or deleted 67 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/