[tram] Protocol Action: 'TURN Server Auto Discovery' to Proposed Standard (draft-ietf-tram-turn-server-discovery-12.txt)
The IESG <iesg-secretary@ietf.org> Wed, 15 February 2017 14:48 UTC
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: tram@ietf.org
Delivered-To: tram@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE36129656; Wed, 15 Feb 2017 06:48:50 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.43.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148717013097.17257.14889174233451099322.idtracker@ietfa.amsl.com>
Date: Wed, 15 Feb 2017 06:48:50 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/IrjZauZUiO2aB_yG9pjJEGnwPNk>
Cc: tram-chairs@ietf.org, tram@ietf.org, draft-ietf-tram-turn-server-discovery@ietf.org, sperreault@jive.com, spencerdawkins.ietf@gmail.com, The IESG <iesg@ietf.org>, rfc-editor@rfc-editor.org
Subject: [tram] Protocol Action: 'TURN Server Auto Discovery' to Proposed Standard (draft-ietf-tram-turn-server-discovery-12.txt)
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.17
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Feb 2017 14:48:51 -0000
The IESG has approved the following document: - 'TURN Server Auto Discovery' (draft-ietf-tram-turn-server-discovery-12.txt) as Proposed Standard This document is the product of the TURN Revised and Modernized Working Group. The IESG contact persons are Mirja Kühlewind and Spencer Dawkins. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/ Technical Summary The intent of this document is to define a procedure for TURN clients to discover servers available to them. In a nutshell the procedure tries, in order, local configuration, S-NAPTR lookup of the client's domain name (obtained from either DHCP or the application-layer identity), DNS-SD, and then a well-known anycast address as last resort. Working Group Summary The document was heavily discussed and reviewed, both in TRAM and externally in RTCWEB, by many participants. Much of the discussion revolved around security considerations. The resulting text represents consensus of all participants. Initial requirements for this work included discovery of network-provided servers in both enterprise and ISP settings. DHCP and DNS-SD are targeted at the enterprise setting while anycast is targeted at the ISP setting. DNS-SD was suggested by a browser maker as an alternative mechanism that is typically more easily usable than DHCP from a user-space application such as a web browser. Document Quality It is expected that WebRTC browsers will implement this specification. However, although RETURN and TURN-bis contain informative references pointing to this spec, it is not mandatory-to-implement for WebRTC. Personnel Document shepherd: Simon Perreault <sperreault@jive.com> Responsible Area Director: Spencer Dawkins <spencerdawkins.ietf@gmail.com> RFC Editor Note OLD Making STUN authentication optional is a downgrade of a MUST level requirement defined in [RFC5766]. The downgrade allows TURN servers provided by local or access network to accept Allocation requests from new and/or guest users in the network who do not necessarily possess long term credentials for STUN authentication. The intention, in such deployments, being to provide TURN services to all 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]. A TURN server in such cases must be configured to only process STUN requests from the trusted local network or subscribers of the access network. Operational measures must be taken in order protect the TURN server; some of these measures include, but not limited to, access control by means of access-lists, firewalls, subscriber quota limits, ingress filtering etc. NEW Making STUN authentication optional is a downgrade of a MUST level requirement defined in [RFC5766]. The downgrade allows TURN servers provided by local or access network to accept Allocation requests from new and/or guest users in the network who do not necessarily possess long term credentials for STUN authentication. The intention, in such deployments, being to provide TURN services to all 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]. A TURN server in such cases must be configured to only process STUN requests from the trusted local network or subscribers of the access network. Operational measures must be taken in order to protect the TURN server; some of these measures include, but not limited to, access control by means of access-lists, firewalls, subscriber quota limits, ingress filtering etc.