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

[Ballot comment]
Thanks, this version helps, and I am clearing my DISCUSS. (I assume Spencer will figure out the Right Thing to do to make sure the update to 5766 gets the right review.)

I have a few minor comments on the resulting text. None of these are showstoppers:

- Absrtact: Please mention that this draft updates 5766 to relax the requirement for authentication in certain cases in the abstract.

- 9, 2nd paragraph, "Making STUN authentication OPTIONAL ..."

Since  you already used a 2119 MAY in the previous paragraph, there's no need for the 2119 OPTIONAL here. (In general, 2119 keywords should be used to state requirements, not talk about existing requirements)

-9, third paragraph:
I saw a comment on my DISCUSS email thread from Karl Stahl, stating that DTLS could not be mandated. Has that input been considered? (I don't have an opinion; I just want to make sure people noticed the comment.)

-9, 9th paragraph: "Instead, with an explicit administrator choice, a TURN client SHOULD fall-back to encryption-only (D)TLS when (D)TLS authentication is not available."
I’m not sure what SHOULD means after adding the explicit choice part. Does that means the administrator SHOULD make that choice? Is the point that you can fall back, but MUST NOT do so without explicit choice?

-9, 10th paragraph:
-- The first sentence is now redundant with the previous paragraph.
-- is the point of the first part of the second sentence that you MUST NOT fall back without explicit choice? (similar to for server authentication?)

[Ballot comment]
Thank you for adding in the text on restricting access to the turn server to address my prior discuss.  I think this is helpful.

[Ballot comment]

- 5.1: s/chance/change/

- I think section 9 covers all the bases in terms of what
might be done, but probably has to be a bit vague about what's
best to do and the consequences that follow. (For example,
with the reference to how RFC7250 "could be used.") I think it
might be a good idea to admit that we don't really yet know
the security implications of this mechanism, if widely
deployed.  However, I also admit that I'm unsure about this
since it's just very hard to know the security properties of
discovery of this kind ahead of time, so I'm not sure what
kind of text to suggest that'd be useful.

[Ballot discuss]
* Section 4.1.1.

The DHCP procedure is underspecified. I think this can be easily fixed but it requires some work.

Please describe what sort of messages you would be using. i.e. are you going for a stateful exchange to piggy pack with other address and config information or are you going for a stateless Information-request based exchange(Most likely). Is there an ORO? If so, what options are requested in the ORO? Are there multiple request-response round trips as implied by the text?

[Ballot discuss]
-9, first paragraph says:

"Use of Session Traversal Utilities for NAT (STUN) [RFC5389]
  authentication is OPTIONAL for TURN servers provided by the local
  network or by the access network.  A network provided TURN server MAY
  be configured to accept Allocation requests without STUN
  authentication, and a TURN client MAY be configured to accept
  Allocation success responses without STUN authentication from a
  network provided TURN server. "

This seems to relax the MUST level requirement in RFC 5766 that says TURN MUST use STUN long-term credential authentication, or use some other equally strong mechanism. From a purely process perpective, this would either require an update to 5766, or it would require an argument that the local/access network is somehow equally protected. I think the latter would only be true if the access network has some sort of protection beyond just being the access network (e.g. a vpn, ipsec, or physical isolation.)  I don't recall seeing text that suggested any of those.

But in any case, I think relaxing that requirement needs some discussion about how the server or client can be sure that all communication is in fact constrained to the local network.

[Ballot comment]
Substantive:

- general: I agree with the DISCUSS positions from Terry, Alexey, and Kathleen.

-3, paragraph 1: Are the MUST and MAY in this paragraph _new_ requirements, or just statements of fact about previously existing requirements? If the latter, they should not use 2119 keywords.

-4.1.2, first paragraph: It would be helpful to have a discussion about clients that may support multiple users, potentially with different domains, or for a single user to use different domains for different services.

-4.2, general: Do I correctly understand that most of this section describes the results of applying RFC 5928 procedures to the extracted domain name? If so, is it not enough reference 5928 and leave it at that?

-4.2, last paragraph, last sentence: Is this requirement new to this draft, or something from 5928? If the latter, please use descriptive language.

-9, paragraph 5: "Any discovered TURN server outside the criteria is considered untrusted and is not used for privacy sensitive communication."

It seems like this needs stronger guidance, maybe even "MUST NOT be used..."

- Informational References:
I-D.ietf-rtcweb-return and RFC 6125 are cited as part of normative requirements, which makes them by definition need to be normative references. I-D.ietf-tram-turn-mobility, RFC6024, and RFC7250 are borderline; I think one could make an argument that one needs to read them to fully understand this draft.

Editorial:

-3, last paragraph: "MAY optionally" is redundant.

-5.1, first paragraph, first sentence: I got lost in the nested “or”s. Please consider breaking this up into a few simpler sentences.

- Figure 1: Why merge the query and reply for the A/AAAA query but not the other queries?

-6, first paragraph, last sentence: I'm not sure what that sentence means.

[Ballot discuss]
In Section 9:

o  For certificate-based authentication, a pre-populated trust anchor
      store [RFC6024] allows a TURN client to perform path validation
      for the server certificate obtained during the (D)TLS handshake.

      If the client used a domain name to discover the TURN server, that
      domain name also provides a mechanism for validation of the TURN
      server.  The client MUST use the rules and guidelines given in
      section 6 of [RFC6125] to validate the TURN server identity.

I am glad that you are referencing RFC 6125, but unfortunately you don't provide enough details. Please add details as specified in Section 3 of RFC 6125 to your document.

[Ballot comment]
= Section 6 =

"Using the TURN
  anycast address, the only two things that need to be deployed in the
  network are the two things that actually use TURN."

This is a bit opaque. I would suggest adding the qualifier "for discovery" somewhere in this sentence.

= Section 7.2 =

"WebRTC endpoints SHOULD treat any TURN server discovered through the mechanisms described in this specification as an enterprise/gateway server, in accordance with Recursively Encapsulated TURN [I-D.ietf-rtcweb-return]."

I think this needs to be re-phrased to include auto-discovery of a TURN server hosted by any access network, not just an enterprise network.

= Section 9 =

"Any discovered TURN server
  outside the criteria is considered untrusted and is not used for
  privacy sensitive communication."
 
This is stated as a fact, but I would have thought it's more of a recommendation to implementers, e.g., servers outside the criteria ought to be considered untrusted and therefore not used.

[Ballot discuss]
in requesting special use assignments, please read the registries and provide guidance on the scope of the allocations i.e.

  o  Source - A boolean value indicating whether an address from the
      allocated special-purpose address block is valid when used as the
      source address of an IP datagram that transits two devices.

  o  Destination - A boolean value indicating whether an address from
      the allocated special-purpose address block is valid when used as
      the destination address of an IP datagram that transits two
      devices.

  o  Forwardable - A boolean value indicating whether a router may
      forward an IP datagram whose destination address is drawn from the
      allocated special-purpose address block between external
      interfaces.

  o  Global - A boolean value indicating whether an IP datagram whose
      destination address is drawn from the allocated special-purpose
      address block is forwardable beyond a specified administrative
      domain.

[Ballot discuss]
This should be easy to resolve.  In reading the draft, it doesn't cover any mechanism for the TURN server to limit what clients can discover it.  For the second and third method, it seems like there are possible ways to do this.  Could these be added to the security considerations?  You'd need to state that this isn't possible with the first method.  If there is a reason why it is always okay to discover a TURN server, please let me know why this is not appropriate to add.  Thanks.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-tram-turn-server-discovery-08.txt. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

IANA has assigned TBD1 from the IPv4 special address registry (located at: https://www.iana.org/assignments/iana-ipv4-special-registry/ ) and TBD2 from the IPv6 special address registry (located at: https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml#iana-ipv6-special-registry-1 ).

The authors also need to include what should be in all the columns for each registry.

For example:
Source Destination Forwardable Global Reserved-by-Protocol

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: tram-chairs@ietf.org, "Simon Perreault" , draft-ietf-tram-turn-server-discovery@ietf.org, sperreault@jive.com, spencerdawkins.ietf@gmail.com, tram@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (TURN Server Auto Discovery) to Proposed Standard


The IESG has received a request from the TURN Revised and Modernized WG
(tram) to consider the following document:
- 'TURN Server Auto Discovery'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-08-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Current Traversal Using Relays around NAT (TURN) server discovery
  mechanisms are relatively static and limited to explicit
  configuration.  These are usually under the administrative control of
  the application or TURN service provider, and not the enterprise,
  ISP, or the network in which the client is located.  Enterprises and
  ISPs wishing to provide their own TURN servers need auto discovery
  mechanisms that a TURN client could use with no or minimal
  configuration.  This document describes three such mechanisms for
  TURN server discovery.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

Document shepherd: Simon Perreault
Responsible Area Director: Spencer Dawkins

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.

The requested publication type is Proposed Standard because it defines new
behaviour for TURN clients of which WebRTC is an immediate customer.


2. Review and Consensus

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.

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.


3. Intellectual Property

Each author has stated that their direct, personal knowledge of any IPR related
to this document has already been disclosed, in conformance with BCPs 78 and 79.
There was no IPR disclosure.


4. Other Points

This document registers new well-known anycast IP address ranges, and that
requires IETF Review.