[tram] Ben Campbell's Discuss on draft-ietf-tram-turn-server-discovery-09: (with DISCUSS and COMMENT)

["Ben Campbell" <[e-mail]>]

Ben Campbell has entered the following ballot position for
draft-ietf-tram-turn-server-discovery-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/



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


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