draft-ietf-tram-turn-server-discovery-11.txt   draft-ietf-tram-turn-server-discovery-12.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: June 17, 2017 December 14, 2016 Expires: July 16, 2017 January 12, 2017
TURN Server Auto Discovery TURN Server Auto Discovery
draft-ietf-tram-turn-server-discovery-11 draft-ietf-tram-turn-server-discovery-12
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 42 skipping to change at page 1, line 42
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 June 17, 2017. This Internet-Draft will expire on July 16, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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
skipping to change at page 9, line 51 skipping to change at page 9, line 51
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
TURN server; some of these measures include, but not limited to, TURN server; some of these measures include, but not limited to,
access control by means of access-lists, firewalls, subscriber quota access control by means of access-lists, firewalls, subscriber quota
limits, ingress filtering etc. limits, ingress filtering etc.
A TURN client MUST use (D)TLS in the absence of STUN long-term A TURN client in the absence of STUN long-term credential mechanism
credential mechanism [RFC5389] or STUN Extension for Third-Party [RFC5389] or STUN Extension for Third-Party Authorization [RFC7635]
Authorization [RFC7635]. It is RECOMMENDED that the TURN client use MUST use (D)TLS unless it trusts the network infrastructure to defend
one of the following techniques with (D)TLS to validate the TURN against attacks discussed in [RFC5766]. It is RECOMMENDED that the
server: 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 Certification authorities that issue TURN server certificates o Certification authorities that issue TURN server certificates
skipping to change at page 11, line 7 skipping to change at page 11, line 7
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. A TURN client open to on-path injection of spoofed TURN messages. A TURN
client could fall back to encryption-only (D)TLS when (D)TLS client could fall back to encryption-only (D)TLS when (D)TLS
authentication is not available, but MUST NOT fall back without authentication is not available, but MUST NOT fall back without
explicit administrator choice. Another reason to fall-back to explicit administrator choice. Another reason to fall-back to
encryption-only is for privacy, which is analogous to SMTP encryption-only is for privacy, which is analogous to SMTP
opportunistic encryption [RFC7435] where one does not require privacy opportunistic encryption [RFC7435] where one does not require privacy
but one desires privacy when possible. but one desires privacy when possible.
In order to allow the TURN client to fallback to (D)TLS as described
above, a TURN server that does not require either STUN long term
authentication [RFC5389] or STUN Extension for Third Party
Authorization [RFC7635] MUST support (D)TLS and if the network
infrastructure is capable of defending against attacks discussed in
[RFC5766] then the TURN server MAY allow fallback to clear text.
A TURN client could fall back to clear text if it does not support A TURN client could fall back to clear text if it does not support
unauthenticated (D)TLS, but MUST NOT fall back without explicit unauthenticated (D)TLS, but MUST NOT fall back without explicit
administrator choice. Fallback to clear text is NOT RECOMMENDED administrator choice. Fallback to clear text is NOT RECOMMENDED
because it makes the client more susceptible to man-in-the-middle because it makes the client more susceptible to man-in-the-middle
attacks and on-path packet injection. 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
 End of changes. 6 change blocks. 
9 lines changed or deleted 17 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/