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
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.