Subject: [tram] Comments on draft-patil-tram-turn-serv-selection-00

From: Justin Uberti <[email-masked]>
Date: Thu, 8 Jan 2015 14:34:22 -0800

At IETF 91, I promised to send feedback on this document, so here goes.

Generally, I think many of the issues mentioned in this document are
important, but the recommendations are confusing and possibly
contradictory; a developer with little knowledge of TURN will have a hard
time figuring out exactly what to do. Furthermore, many of the properties
discussed in this document are dynamic, and should be handled by the ICE
process, rather than in TURN server selection (for example, the notion of
RTT as it relates to user experience).

Therefore, I think this document should take a stronger stance and put
forth explicit best practices for selection (as opposed to "things to
consider"), for non-dynamic properties, and leave the decisions on dynamic
properties to be resolved by ICE.

For example, I think we should omit the text in Section 3 about what to do
with non-working TURN servers, and measuring RTT. Same for Section 3.3,
which also discusses RTT, and Section 3.4, which talks about multiple
interfaces. This can all be handled by ICE.

In addition, the sections on local config and location privacy are
unnecessary when RETURN is used. When RETURN is used, the application can
always use the app TURN server for location privacy, and the relationship
between local TURN server and app TURN server is fully spelled out, so
there is nothing for the application to decide on.

This leaves only the Security, Authentication, and Mobility sections.

For security, I think we can give some clear guidance on what applications
should do. For security, I think the guidance should be to use only DTLS +
TLS, if both are available, with fallback to UDP or TCP if DTLS or TLS
aren't available. If privacy is paramount, UDP/TCP fallback may be
contraindicated, but at this point in time, DTLS deployment isn't
widespread enough to truly recommend this.

This relates to the Authentication section - but I think any failures to
authenticate the server cert should cause the TURN allocation to fail. This
is just like any other misconfiguration on the TURN server - there's no
reason we should even allow use of TURN servers whose cert chains don't
validate. So, this section could probably be removed.

Lastly, the Mobility section says that if "all other parameters [are]
equal", a TURN server with mobility should be used. Clearly, all other
parameters will not be equal (e.g. RTT), and even if they were, the client
has no way to know if a server is mobility-capable a priori. So I think
this recommendation ought to be removed, or perhaps turned into some sort
of recommendation for TURN server developers (e.g. TURN servers SHOULD
support TLS/DTLS, SHOULD support mobility, SHOULD support redirect),
probably in a separate doc.

These recommendations should reduce the size of this document and provide
much clearer advice to app developers.

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Fri, 9 Jan 2015 16:28:47 +0000

Thanks, Justin.  We'll collect Brandon's feedback on the draft too and the authors will deliberate on text edits and produce a new version for your review.

-G

> On Jan 8, 2015, at 5:34 PM, Justin Uberti <[email-masked]> wrote:
> 
> Generally, I think many of the issues mentioned in this document are important, but the recommendations are confusing and possibly contradictory; a developer with little knowledge of TURN will have a hard time figuring out exactly what to do. Furthermore, many of the properties discussed in this document are dynamic, and should be handled by the ICE process, rather than in TURN server selection (for example, the notion of RTT as it relates to user experience).
> 
> Therefore, I think this document should take a stronger stance and put forth explicit best practices for selection (as opposed to "things to consider"), for non-dynamic properties, and leave the decisions on dynamic properties to be resolved by ICE. 
> 
> For example, I think we should omit the text in Section 3 about what to do with non-working TURN servers, and measuring RTT. Same for Section 3.3, which also discusses RTT, and Section 3.4, which talks about multiple interfaces. This can all be handled by ICE.
> 
> In addition, the sections on local config and location privacy are unnecessary when RETURN is used. When RETURN is used, the application can always use the app TURN server for location privacy, and the relationship between local TURN server and app TURN server is fully spelled out, so there is nothing for the application to decide on.
> 
> For security, I think we can give some clear guidance on what applications should do. For security, I think the guidance should be to use only DTLS + TLS, if both are available, with fallback to UDP or TCP if DTLS or TLS aren't available. If privacy is paramount, UDP/TCP fallback may be contraindicated, but at this point in time, DTLS deployment isn't widespread enough to truly recommend this.
> 
> This relates to the Authentication section - but I think any failures to authenticate the server cert should cause the TURN allocation to fail. This is just like any other misconfiguration on the TURN server - there's no reason we should even allow use of TURN servers whose cert chains don't validate. So, this section could probably be removed.
> 
> Lastly, the Mobility section says that if "all other parameters [are] equal", a TURN server with mobility should be used. Clearly, all other parameters will not be equal (e.g. RTT), and even if they were, the client has no way to know if a server is mobility-capable a priori. So I think this recommendation ought to be removed, or perhaps turned into some sort of recommendation for TURN server developers (e.g. TURN servers SHOULD support TLS/DTLS, SHOULD support mobility, SHOULD support redirect), probably in a separate doc.
> 
> These recommendations should reduce the size of this document and provide much clearer advice to app developers.
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Thu, 15 Jan 2015 07:02:47 +0000

Hi Justin,

From: Justin Uberti <[email-masked]<mailto:[email-masked]>>
Date: Friday, January 9, 2015 4:04 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [tram] Comments on draft-patil-tram-turn-serv-selection-00

Yes, we'll clarify this in the next revision. We'll simply advise that dynamic properties have to be resolved by ICE.

Sure. We can add a note on RETURN. However, a server selection mechanism should consider cases in the absence of RETURN, especially for local config.

For security, I think we can give some clear guidance on what applications should do. For security, I think the guidance should be to use only DTLS + TLS, if both are available, with fallback to UDP or TCP if DTLS or TLS aren't available.

Will do.

If privacy is paramount, UDP/TCP fallback may be contraindicated, but at this point in time, DTLS deployment isn't widespread enough to truly recommend this.

This relates to the Authentication section - but I think any failures to authenticate the server cert should cause the TURN allocation to fail.

Yes, we'll make this clear. The documents reads 'prefer a TURN server whose authenticity can be ascertained', which needs to change.

This is just like any other misconfiguration on the TURN server - there's no reason we should even allow use of TURN servers whose cert chains don't validate. So, this section could probably be removed.

The section offers some guidance on how to validate the certs in case of pre-configured list of trusted names etc.
We also wanted to add some guidance on how to go about validating certs when the client discovers a TURN server IP address but not necessarily its name, but certificates have a DNS name in the SubjectAltName field.
Thoughts?

Lastly, the Mobility section says that if "all other parameters [are] equal", a TURN server with mobility should be used. Clearly, all other parameters will not be equal (e.g. RTT), and even if they were, the client has no way to know if a server is mobility-capable a priori.

Right. Given this, we could perhaps recommend that a client that wants mobility sends the STUN MOBILITY-TICKET attribute in the Allocate request and rejects a TURN server that doesn’t include a STUN MOBILITY-TICKET in its response. If none of the discovered TURN servers support mobility, then the client just goes back to the first TURN server is attempted to connect. Not very ideal.

We could maybe have a similar mechanism for location privacy? A TURN server should respond with an attribute indicating that it offers location privacy.

So I think this recommendation ought to be removed, or perhaps turned into some sort of recommendation for TURN server developers (e.g. TURN servers SHOULD support TLS/DTLS, SHOULD support mobility, SHOULD support redirect), probably in a separate doc.

Thanks,
Prashanth