Subject: Re: [tram] TURN server auto-discovery

From: Brandon Williams <[email-masked]>
Date: Wed, 3 Aug 2016 14:17:06 -0400

Hi Olle,

Regarding your comment about section 9:

 > Section 9:
 > - “Use of STUN 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.  “
 > Is this text normative? If so it’s clearly out of scope for a draft 
on auto-discovery.
 > You also need to add text on DNSsec here.
 >
 > A lot of this text is good, but I have issues with it being in this 
draft. Does
 > this text normatively update another document? It covers how to set up
 > connections more than how to discover services. Maybe how to trust
 > the TURN server should be another draft or, if it needs to be in this 
draft,
 > should be made in a separate section. If that is the case, the abstract
 > and introduction section  needs to be modified to cover this scope too.

As I understand it, this text is meant to be normative, though perhaps 
just the first sentence. The existing TURN specification requires STUN 
authentication for TURN. For TURN servers provided by the local or 
access network, there is a presumption that network has other methods 
for restricting access and that STUN authentication is not required. 
Thus this draft intends to make STUN authentication OPTIONAL, but only 
when the relay is provided by either the local or the access network.

The additional sentence is meant, I think, to describe what this means 
in practice: both the client and the server can be configured to allow 
unauthenticated TURN messages, and they must both be configured to allow 
this in order for it to work.

As I write this explanation, I realize that the current text doesn't 
state the motivation. This should be added, I think. Also, maybe the 
second sentence isn't adequate clarification. Maybe we need something 
like: The server accepts the unauthenticated Allocate if configured 
appropriately. The client accepts the unauthenticated Allocate response 
if configured appropriately, and it now can send unauthenticated TURN 
messages on the channel. If the client receives an unauthenticated 
Allocate response but is not configured to accept them, then it ignores 
the message. Maybe there is a need to provide a fallback mechanism in 
the case that the client requires auth and the server doesn't.

--Brandon

On 07/27/2016 04:15 AM, Olle E. Johansson wrote:
> Sorry for being late into reviewing this document. If I am too late, my apologies,
> but nevertheless here’s a few nits and comments:
>
> https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-08
>
> Section 1:
> - “Web Real-Time Communication (WebRTC)
>     [I-D.ietf-rtcweb-overview] usages and related extensions, which are
>     mostly based on web applications, need this immediately.”
> When I read this in ten years time, it is no longer immediately. Please rephrase.
>
> - “This document describes three discovery mechanisms, so as to maximize
>     opportunity for discovery, based on the network in which the TURN
>     client finds itself.  “
>   A very complicated sentence. Can it be simplified to make reading easier?
>
> - “For example, in case of Web Real-Time Communication
>     (WebRTC) [I-D.ietf-rtcweb-overview] usages and related extensions,
>     which are based on web applications, a Java Script specified TURN
>     server MUST be considered as local configuration. “
> I think “local” is a bad choice here - maybe “application-provided configuration”
> could be an improvement?
>
> - “A client can choose auto-discovery in the absence of local
> configuration, if local configuration doesn't work or on top of local
>     configuration. “
> I think local security policy may affect choice and maybe also need to override
> “local configuration”
>
> - “An implementation
>     MAY give the user an opportunity (e.g., by means of configuration
>     file options or menu items) to specify a TURN server for each address
>     family.”
> How do you define the implementation? The browser, the javascript application
> or another TURN user, like a SIP phone? In the case of WebRTC you need
> to clarify your terminology - there’s one application running in javascript and
> then you have the browser. Also remember that TURN is not only about
> browsers :-)
>
> - “A TURN client that implements the auto discovery algorithm, to
>     discover TURN servers in the attached network, uses the following
>     mechanisms for discovery:”
> Change the list that follows to use bullets, as you later write that you do not
> prescribe a strict order.
>
> Section 4.1:
> This section is a bit open. If I want to write a SIP specific document
> specifying a way to use the outbound proxy URI or a service route URI
> to use for TURN service discovery - will that be a standalone document
> or an update to this document. Maybe some requirements on other
> ways to select a domain name would be appropriate.
>
> Section 4.1.2:
> - “JID   : [email-masked]’”
> You have a SIP URI and a bare JID. Maybe consider making it an XMPP URI
> by prefixing the JID with “XMPP:” for clarity.
>
> Section 5:
> - “For example, TURN server advertises the following DNS records :”
> s/TURN/a TURN/
>
> Section 9:
> - “Use of STUN 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.  “
> Is this text normative? If so it’s clearly out of scope for a draft on auto-discovery.
> You also need to add text on DNSsec here.
>
> A lot of this text is good, but I have issues with it being in this draft. Does
> this text normatively update another document? It covers how to set up
> connections more than how to discover services. Maybe how to trust
> the TURN server should be another draft or, if it needs to be in this draft,
> should be made in a separate section. If that is the case, the abstract
> and introduction section  needs to be modified to cover this scope too.
>
>
> /O
>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 17 Aug 2016 08:57:10 +0200

> On 03 Aug 2016, at 20:17, Brandon Williams <[email-masked]> wrote:
> 
> Hi Olle,
> 
> As I understand it, this text is meant to be normative, though perhaps just the first sentence. The existing TURN specification requires STUN authentication for TURN. For TURN servers provided by the local or access network, there is a presumption that network has other methods for restricting access and that STUN authentication is not required. Thus this draft intends to make STUN authentication OPTIONAL, but only when the relay is provided by either the local or the access network.
Ok, I see the intent. I am not sure I agree that encouraging the thought that there’s still a secure internal network and a hostile outside network.
This needs a larger discussion with security people involved.

> 
> The additional sentence is meant, I think, to describe what this means in practice: both the client and the server can be configured to allow unauthenticated TURN messages, and they must both be configured to allow this in order for it to work.
That is a big change.
> 
> As I write this explanation, I realize that the current text doesn't state the motivation. This should be added, I think. Also, maybe the second sentence isn't adequate clarification. Maybe we need something like: The server accepts the unauthenticated Allocate if configured appropriately. The client accepts the unauthenticated Allocate response if configured appropriately, and it now can send unauthenticated TURN messages on the channel. If the client receives an unauthenticated Allocate response but is not configured to accept them, then it ignores the message. Maybe there is a need to provide a fallback mechanism in the case that the client requires auth and the server doesn’t.
My backbone feeling is that this change is way to big to be part of autodiscovery. Personally I do not
think it’s a good thing. Even in an internal network, there has to be provisioning of account information and we should encourage that
instead of disabling authentication.

Sorry for the late response, have been enjoying a summer holiday :-)

/O