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.
