Subject: [tram] Review of draft-ietf-tram-turn-server-discovery-04

From: Bernard Aboba <[email-masked]>
Date: Thu, 30 Jul 2015 11:23:17 -0700

1. Overall, in reading this document it was not clear to me how it was
intended
to be applied to WebRTC scenarios where a TURN server is configured in the
JS.

* Does TURN server discovery apply in this case, or is the JS-specified
TURN server considered "manual TURN configuration" ?

* Where IdP is used, is the local IdP identity considered to consitute a
"domain name" per Section 4.1.2?

2. In scenarios where TURN Server discovery does apply, what mechanisms are
to be used to authenticate or authorize the discovered TURN Servers(s)?
Using a configured domain name seems like a potentially viable approach,
but there are scenarios where that might not be configured, or might not be
secure
(e.g. if the domain name were obtained from unauthenticated DHCP).

Using the browser's configured trust anchor(s) doesn't seem like a good
idea, given that it would only be as secure as the least-secure trust
anchor.

Specific comments:

Section 3

   1.  Local Configuration : Local or manual TURN configuration (i.e.,
       TURN servers configured at the system level) should be tried
       first, as it may be an explicit preferred choice of a user.

[BA] Would TURN servers specified within a WebRTC JS application be
considered "local or manual" in this context?  Also, shouldn't a configured
domain name (Section 4.1.2) be considered part of "local TURN
configuration"?

IMHO, the configured domain name not only enables discovery as indicated
in Section 4.2, but also provides a mechanism for validation of the
TURN server discovered by other methods.

   The document does not prescribe a strict order that a client must
   follow for discovery.  An implementation may choose to perform steps
   2,3 and 4 in parallel for discovery OR choose to follow any desired
   order and stop the discovery procedure if a mechanism succeeds.

[BA] I am not sure I buy this.  It is already stated that "local or manual"
configuration should be tried first, and I would considered a configured
domain name to be part of this, which would imply attempting 2 first if
that exists.

Section 9.2

   For mDNS, in addition to what has been described above, a principal
   security threat is a security threat inherent to IP multicast routing
   and any application that runs on it.  A rogue system can advertise
   that it is a TURN server.  Discovery of such rogue systems as TURN
   servers, in itself, is not a security threat if there is a means for
   the TURN client to authenticate and authorize the discovered TURN
   servers.

[BA] In scenarios in which mDNS would be used, there typically will not be a
means for the TURN client to authentication and authorize the discovered
TURN server. For example, a home router with a built-in TURN server is
not likely to have a certificate chaining to a trust anchor.  Also, the
mDNS is not compatible with DNSSEC (e.g. there is no signer for the .local
domain).

Section 9.3

   Sensitive clients that do not wish to leak information about their
   presence can set an IP TTL on their TURN requests that limits how far
   they can travel into the public Internet.

[BA] This seems like a crude tool at best.  If the goal is to provide
privacy,
wouldn't use of encryption make more sense?  This could include DNS privacy,
encryption of TURN traffic, etc.

---

From: Benjamin Schwartz <[email-masked]>
Date: Thu, 30 Jul 2015 14:31:34 -0400

> TURN server considered "manual TURN configuration" ?

In WebRTC scenarios, RETURN specifies the correct handling of
autodiscovered TURN servers.  The conclusion, roughly, is that JS-specified
TURN servers and autodiscovered TURN servers are configured independently,
and under various conditions the client may use both
simultaneously, neither, or either one of the two.

I agree that the autodiscovery draft could be clearer about its interaction
with WebRTC.

> 2. In scenarios where TURN Server discovery does apply, what mechanisms
> are to be used to authenticate or authorize the discovered TURN
> Servers(s)?  Using a configured domain name seems like a potentially viable
> approach, but there are scenarios where that might not be configured, or
> might not be secure
> [BA] I am not sure I buy this.  It is already stated that "local or
> manual" configuration should be tried first, and I would considered a
> configured domain name to be part of this, which would imply attempting 2
> first if that exists.
>
> Section 9.2
>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>
>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 30 Jul 2015 11:36:29 -0700

Benjamin said:
"In WebRTC scenarios, RETURN specifies the correct handling of
autodiscovered TURN servers.  "

[BA] It seems like RETURN could be relevant beyond Web-based scenarios
(e.g. use in a mobile application).  But the draft doesn't mention RETURN
at all.

On Thu, Jul 30, 2015 at 11:31 AM, Benjamin Schwartz <[email-masked]>
wrote:

>> to be applied to WebRTC scenarios where a TURN server is configured in
>> the JS.
>>
> I agree that the autodiscovery draft could be clearer about its
> interaction with WebRTC.
>
>
>>