draft-ietf-tram-turn-server-discovery-10.txt   draft-ietf-tram-turn-server-discovery-11.txt 
TRAM P. Patil TRAM P. Patil
Internet-Draft T. Reddy Internet-Draft T. Reddy
Updates: 5766 (if approved) Cisco Updates: 5766 (if approved) Cisco
Intended status: Standards Track D. Wing Intended status: Standards Track D. Wing
Expires: April 8, 2017 October 5, 2016 Expires: June 17, 2017 December 14, 2016
TURN Server Auto Discovery TURN Server Auto Discovery
draft-ietf-tram-turn-server-discovery-10 draft-ietf-tram-turn-server-discovery-11
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
configuration. This document describes three such mechanisms for configuration. This document describes three such mechanisms for
TURN server discovery. TURN server discovery.
This draft updates [RFC5766] to relax the requirement for mutual
authentication in certain cases.
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 April 8, 2017. This Internet-Draft will expire on June 17, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 21
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Discovery Procedure . . . . . . . . . . . . . . . . . . . . . 3 3. Discovery Procedure . . . . . . . . . . . . . . . . . . . . . 3
4. Discovery using Service Resolution . . . . . . . . . . . . . 4 4. Discovery using Service Resolution . . . . . . . . . . . . . 4
4.1. Retrieving Domain Name . . . . . . . . . . . . . . . . . 4 4.1. Retrieving Domain Name . . . . . . . . . . . . . . . . . 5
4.1.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.2. From own Identity . . . . . . . . . . . . . . . . . . 5 4.1.2. From own Identity . . . . . . . . . . . . . . . . . . 5
4.2. Resolution . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Resolution . . . . . . . . . . . . . . . . . . . . . . . 6
5. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 6 5. DNS Service Discovery . . . . . . . . . . . . . . . . . . . . 6
5.1. mDNS . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. mDNS . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Discovery using Anycast . . . . . . . . . . . . . . . . . . . 7 6. Discovery using Anycast . . . . . . . . . . . . . . . . . . . 7
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 7 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 8
7.1. Mobility and Changing IP addresses . . . . . . . . . . . 7 7.1. Mobility and Changing IP addresses . . . . . . . . . . . 8
7.2. Recursively Encapsulated TURN . . . . . . . . . . . . . . 7 7.2. Recursively Encapsulated TURN . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8.1. IPv4 Anycast . . . . . . . . . . . . . . . . . . . . . . 8 8.1. IPv4 Anycast . . . . . . . . . . . . . . . . . . . . . . 8
8.2. IPv6 Anycast . . . . . . . . . . . . . . . . . . . . . . 8 8.2. IPv6 Anycast . . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9.1. Service Resolution . . . . . . . . . . . . . . . . . . . 10 9.1. Service Resolution . . . . . . . . . . . . . . . . . . . 11
9.2. DNS Service Discovery . . . . . . . . . . . . . . . . . . 11 9.2. DNS Service Discovery . . . . . . . . . . . . . . . . . . 11
9.3. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.3. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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
skipping to change at page 7, line 20 skipping to change at page 7, line 35
6. Discovery using Anycast 6. Discovery using Anycast
IP anycast can also be used for TURN service discovery. A packet IP anycast can also be used for TURN service discovery. A packet
sent to an anycast address is delivered to the "topologically 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 for discovery are the two things that actually use TURN. network for discovery 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. A TURN anycast server
responds with a 300 (Try Alternate) error as described in [RFC5766]; performs checks 1 to 7 discussed in Section 6.2 of [RFC5766]. If all
The response contains the TURN unicast address in the ALTERNATE- checks pass, the TURN anycast server MUST respond with a 300 (Try
SERVER attribute. For subsequent communication with the TURN server, Alternate) error as described in Section 2.9 of [RFC5766]; The
the client uses the responding server's unicast address. This has to response contains the TURN unicast address in the ALTERNATE-SERVER
be done because two packets addressed to an anycast address may reach 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 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 TURN Allocation implementation may choose to send out every new TURN Allocation
request to the anycast address to discover the closest and the most request to the anycast address to discover the closest and the most
optimal unicast address for the TURN server. optimal unicast address for the TURN server.
7. Deployment Considerations 7. Deployment Considerations
7.1. Mobility and Changing IP addresses 7.1. Mobility and Changing IP addresses
skipping to change at page 9, line 15 skipping to change at page 9, line 36
9. Security Considerations 9. Security Considerations
Use of Session Traversal Utilities for NAT (STUN) [RFC5389] Use of Session Traversal Utilities for NAT (STUN) [RFC5389]
authentication is OPTIONAL for TURN servers provided by the local authentication is OPTIONAL for TURN servers provided by the local
network or by the access network. A network provided TURN server MAY network or by the access network. A network provided TURN server MAY
be configured to accept Allocation requests without STUN be configured to accept Allocation requests without STUN
authentication, and a TURN client MAY be configured to accept authentication, and a TURN client MAY be configured to accept
Allocation success responses without STUN authentication from a Allocation success responses without STUN authentication from a
network provided TURN server. network provided TURN server.
Making STUN authentication OPTIONAL is a downgrade of a MUST level Making STUN authentication optional is a downgrade of a MUST level
requirement defined in [RFC5766]. The downgrade allows TURN servers requirement defined in [RFC5766]. The downgrade allows TURN servers
provided by local or access network to accept Allocation requests provided by local or access network to accept Allocation requests
from new and/or guest users in the network who do not necessarily from new and/or guest users in the network who do not necessarily
possess long term credentials for STUN authentication. The possess long term credentials for STUN authentication. The
intention, in such deployments, being to provide TURN services to all intention, in such deployments, being to provide TURN services to all
users in the local or access network. However, this opens up a TURN users in the local or access network. However, this opens up a TURN
server to a variety of attacks described in Section 17 of [RFC5766]. server to a variety of attacks described in Section 17 of [RFC5766].
A TURN server in such cases must be configured to only process STUN A TURN server in such cases must be configured to only process STUN
requests from the trusted local network or subscribers of the access requests from the trusted local network or subscribers of the access
network. Operational measures must be taken in order protect the network. Operational measures must be taken in order protect the
skipping to change at page 10, line 27 skipping to change at page 10, line 46
use auto-discovered TURN servers for sessions with 'strict privacy' use auto-discovered TURN servers for sessions with 'strict privacy'
requirements, the user needs to be able to define privacy criteria requirements, the user needs to be able to define privacy criteria
(e.g. a trusted list of servers, networks, or domains) that are (e.g. a trusted list of servers, networks, or domains) that are
considered acceptable for such traffic. Any discovered TURN server considered acceptable for such traffic. Any discovered TURN server
outside the criteria is considered untrusted and therefore MUST NOT outside the criteria is considered untrusted and therefore MUST NOT
be used for privacy sensitive communication. be used for privacy sensitive communication.
In some auto-discovery scenarios, it might not be possible for the In some auto-discovery scenarios, it might not be possible for the
TURN client to use (D)TLS authentication to validate the TURN server. TURN client to use (D)TLS authentication to validate the TURN server.
However, fall-back to clear text in such cases could leave the TURN However, fall-back to clear text in such cases could leave the TURN
client open to on-path injection of spoofed TURN messages. Instead, client open to on-path injection of spoofed TURN messages. A TURN
with an explicit administrator choice, a TURN client SHOULD fall-back client could fall back to encryption-only (D)TLS when (D)TLS
to encryption-only (D)TLS when (D)TLS authentication is not authentication is not available, but MUST NOT fall back without
available. Another reason to fall-back to encryption-only is for explicit administrator choice. Another reason to fall-back to
privacy, which is analogous to SMTP opportunistic encryption encryption-only is for privacy, which is analogous to SMTP
[RFC7435] where one does not require privacy but one desires privacy opportunistic encryption [RFC7435] where one does not require privacy
when possible. but one desires privacy when possible.
It is suggested that a TURN client attempt (D)TLS with authentication A TURN client could fall back to clear text if it does not support
and encryption, falling back to encryption-only if the TURN server unauthenticated (D)TLS, but MUST NOT fall back without explicit
cannot be authenticated via (D)TLS. A TURN client could fall back to administrator choice. Fallback to clear text is NOT RECOMMENDED
clear text, with an explicit administrator choice, if it does not because it makes the client more susceptible to man-in-the-middle
support unauthenticated (D)TLS, but fallback to clear text is NOT attacks and on-path packet injection.
RECOMMENDED because it makes the client more susceptible to man-in-
the-middle attacks and on-path packet injection.
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 14, line 15 skipping to change at page 14, line 38
[RFC7635] Reddy, T., Patil, P., Ravindranath, R., and J. Uberti, [RFC7635] Reddy, T., Patil, P., Ravindranath, R., and J. Uberti,
"Session Traversal Utilities for NAT (STUN) Extension for "Session Traversal Utilities for NAT (STUN) Extension for
Third-Party Authorization", RFC 7635, Third-Party Authorization", RFC 7635,
DOI 10.17487/RFC7635, August 2015, DOI 10.17487/RFC7635, August 2015,
<http://www.rfc-editor.org/info/rfc7635>. <http://www.rfc-editor.org/info/rfc7635>.
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-15 Browser-based Applications", draft-ietf-rtcweb-overview-16
(work in progress), January 2016. (work in progress), November 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-01 (work in progress), January 2016. ietf-rtcweb-return-01 (work in progress), January 2016.
[I-D.ietf-tram-turn-mobility] [I-D.ietf-tram-turn-mobility]
Reddy, T., Wing, D., Patil, P., and P. Martinsen, Reddy, T., Wing, D., Patil, P., and P. Martinsen,
"Mobility with TURN", draft-ietf-tram-turn-mobility-09 "Mobility with TURN", draft-ietf-tram-turn-mobility-09
(work in progress), September 2016. (work in progress), September 2016.
 End of changes. 15 change blocks. 
34 lines changed or deleted 37 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/