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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 10 Jan 2015 03:38:34 +0000

Hi Justin,

Enterprise-provided TURN server cannot provide location privacy may not be always true. For example Enterprise network could use TURN server provided by a cloud service and the user needs to know that the Enterprise TURN server can provide location privacy and not proceed with TURN-in-TURN.

We will have to discuss if TURN server can advertise that it can provide location privacy in a new attribute or this info can be conveyed out-of-band (e.g. PAC).

The other problem not discussed in the draft is, what if the user wants privacy against the calling site and let’s say uses Tor for privacy. In this scenario app TURN server must not be selected.

-Tiru

From: tram [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: Friday, January 09, 2015 4:04 AM
To: [email-masked]
Subject: [tram] Comments on draft-patil-tram-turn-serv-selection-00

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: Justin Uberti <[email-masked]>
Date: Sat, 10 Jan 2015 12:47:28 -0800

On Fri, Jan 9, 2015 at 7:38 PM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

>  Hi Justin,
>
>
>
> Enterprise-provided TURN server cannot provide location privacy may not be
> always true. For example Enterprise network could use TURN server provided
> by a cloud service and the user needs to know that the Enterprise TURN
> server can provide location privacy and not proceed with TURN-in-TURN.
>
>
>
> We will have to discuss if TURN server can advertise that it can provide
> location privacy in a new attribute or this info can be conveyed
> out-of-band (e.g. PAC).
>

>
> The other problem not discussed in the draft is, what if the user wants
> privacy against the calling site and let’s say uses Tor for privacy. In
> this scenario app TURN server must not be selected.
>

RETURN handles this situation fine, since the traffic will be routed
through the network-provided TURN server before being routed to the app
TURN server. Of course, if the application does not try to provide location
privacy, only the network-provided TURN server will be used.

However, I think the user is much more likely to trust the application than
its network provider to provide privacy protection.

>
>
>
> *From:* tram [mailto:[email-masked]] *On Behalf Of *Justin Uberti
> *Sent:* Friday, January 09, 2015 4:04 AM
> *To:* [email-masked]
> *Subject:* [tram] Comments on draft-patil-tram-turn-serv-selection-00
>
>
>
> 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.
>
>
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sun, 11 Jan 2015 05:40:10 +0000

Inline [TR]

From: Justin Uberti [mailto:[email-masked]]
Sent: Sunday, January 11, 2015 2:17 AM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]
Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00

On Fri, Jan 9, 2015 at 7:38 PM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Justin,

RETURN handles this situation fine, since the traffic will be routed through the network-provided TURN server before being routed to the app TURN server. Of course, if the application does not try to provide location privacy, only the network-provided TURN server will be used.

[TR] But the problem is how will the endpoint how if network-provided TURN server can provide location privacy or not ?
         TURN server can convey this information in a new STUN attribute to the client.

However, I think the user is much more likely to trust the application than its network provider to provide privacy protection.

[TR] User may or may not trust the application server. https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10 discusses users using privacy techniques like Tor so that app server does not learn the user's IP address. The Poker example given in the above draft explains that the users in the call do not trust the calling service. In this case IdP ensures that even if malicious calling service replaces the media addresses with its own addresses  and replaces the certificate fingerprint in SDP with its own certificate, IdP assertion would ensure that the Poker site cannot act as  man-in-middle device. In this scenario user may not want to pick app provided TURN server.

-Tiru

From: tram [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Justin Uberti
Sent: Friday, January 09, 2015 4:04 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [tram] Comments on draft-patil-tram-turn-serv-selection-00

---

From: "Aijun Wang" <[email-masked]>
Date: Mon, 12 Jan 2015 09:37:51 +0800

Hi, Reddy and Justin:

I suggest the TURN server selection should be made by ICE, not the client itself.  This can eliminate the needs for the communication between different TURN server that selected by communication peer. ICE has more information about the communication situation, and is suitable to make this decision.

There are several issues needed to be solved when the communication peers select the different TURN server, for example, how to find the second TURN server, what is the communication mechanism between different TURN servers, the channel connection among different data segments: client/first TURN server, first TURN server/second TURN server, and second TURN server/peer etc.

Best Regards.

From: tram [mailto:[email-masked]] On Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Sunday, January 11, 2015 1:40 PM
To: Justin Uberti
Cc: [email-masked]
Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00

Inline [TR]

 

On Fri, Jan 9, 2015 at 7:38 PM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:

Hi Justin,

-Tiru

---

From: Justin Uberti <[email-masked]>
Date: Sun, 11 Jan 2015 21:31:28 -0800

RETURN addresses how the TURN servers communicate.

On Sun, Jan 11, 2015 at 5:37 PM, Aijun Wang <[email-masked]>
wrote:

> Hi, Reddy and Justin:
>
>
>
> I suggest the TURN server selection should be made by ICE, not the client
> itself.  This can eliminate the needs for the communication between
> different TURN server that selected by communication peer. ICE has more
> information about the communication situation, and is suitable to make this
> decision.
>
>
>
> There are several issues needed to be solved when the communication peers
> select the different TURN server, for example, how to find the second TURN
> server, what is the communication mechanism between different TURN servers,
> the channel connection among different data segments: client/first TURN
> server, first TURN server/second TURN server, and second TURN server/peer
> etc.
>
>
>
> Best Regards.
>
>
>
> *From:* tram [mailto:[email-masked]] *On Behalf Of *Tirumaleswar
> Reddy (tireddy)
> *Sent:* Sunday, January 11, 2015 1:40 PM
> *To:* Justin Uberti
>
> *Cc:* [email-masked]
> *Subject:* Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00
>
>
>
> Inline [TR]
>
>
>
> *From:* Justin Uberti [mailto:[email-masked] <[email-masked]>]
> *Sent:* Sunday, January 11, 2015 2:17 AM
> *To:* Tirumaleswar Reddy (tireddy)
> *Cc:* [email-masked]
> *Subject:* Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00
>
>
>
>
>
>
>
> [TR] But the problem is how will the endpoint how if network-provided TURN
> server can provide location privacy or not ?
>
> However, I think the user is much more likely to trust the application
> than its network provider to provide privacy protection.
>
>
>
> [TR] User may or may not trust the application server.
> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10 discusses
> users using privacy techniques like Tor so that app server does not learn
> the user's IP address. The Poker example given in the above draft explains
> that the users in the call do not trust the calling service. In this case
> IdP ensures that even if malicious calling service replaces the media
> addresses with its own addresses  and replaces the certificate fingerprint
> in SDP with its own certificate, IdP assertion would ensure that the Poker
> site cannot act as  man-in-middle device. In this scenario user may not
> want to pick app provided TURN server.
>
>
>
> -Tiru
>
>
>
>
>
>
>