Traversal Using Relays around NAT (TURN) Server Auto Discovery
draft-ietf-tram-turn-server-discovery-12

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
Cc: tram-chairs@ietf.org, "Simon Perreault" <sperreault@jive.com>, 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, tram@ietf.org
Subject: Protocol Action: 'TURN Server Auto Discovery' to Proposed Standard (draft-ietf-tram-turn-server-discovery-12.txt)

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.