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

["Aijun Wang" <[e-mail]>]

Hi, Justin:

 

As you described, the role of enterprise TURN is just let the inner user to communicate with the outsider remote party when there is firewall at the border of the enterprise network? You have said that when two users are within the corporate, they will not the use the corporate TURN server.

 

It is one common request that the inner user want to communicate with the outside world, not limited on WebRTC application, so why not use some tunnel protocol directly, such as L2TP, which rely on UDP datagram and can eliminate the latency introduced by other tunnel protocol that based on TCP?

 

RETURN maybe one available option, but I think the “L2TP(or other tunnel protocol)+TURN” is a better solution. On the other hand, RETURN is just another kind UDP tunnel technology?

 

Best Regards.

Aijun Wang.

 

From: tram [mailto:[e-mail]] On Behalf Of Justin Uberti
Sent: Wednesday, January 14, 2015 1:38 AM
To: Aijun Wang
Cc: [e-mail]; Tirumaleswar Reddy (tireddy)
Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00

 

 

 

On Mon, Jan 12, 2015 at 5:14 PM, Aijun Wang <[e-mail]> wrote:

Hi, Justin:

 

Please refer to the reply below.

 

 

From: Justin Uberti [mailto:[e-mail]] 
Sent: Tuesday, January 13, 2015 4:23 AM
To: Aijun Wang
Cc: Tirumaleswar Reddy (tireddy); [e-mail]
Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00

 

 

 

On Sun, Jan 11, 2015 at 10:32 PM, Aijun Wang <[e-mail]> wrote:

Hi, 

 

Do you refer to the draft http://www.ietf.org/id/draft-schwartz-rtcweb-return-04.txt as RETURN draft? This draft describes only TURN-in-TURN, not TURN-to-TURN. It does not describe the situation that the communication peers select the different public TURN server, and need the TURN server to relay the app data(TURN to TURN).

 

That is just normal UDP. 

 

[Aijun]: For TURN to TURN situation, I am discussing it with the Brandon, please refer to that thread.  We should consider carefully for the transport mechanism between A/TURN Server A; TURN Server A/TURN Server B and TURN Server B/B when peer A want to talk to B via the two TURN Server A/B. 

 

In situation that mentioned in RETURN draft, Why not to let ICE or App Server to select the appropriate TURN server(corporate private TURN server or public TURN server) based on the information of the two communication parts? This can even eliminate the solution of  RETURN:  two peer will use the corporate TURN server when they are both within corporate, and will use the public TURN server when one of them is located outside the corporation?

 

a) The TURN server isn't needed when both endpoints are within the enterprise. The TURN server sits on the enterprise border, and is used for inter-enterprise traffic.

b) The public TURN server may not be reachable from the enterprise. This is why the corporate TURN server is needed on the border.

c) The app may require use of its own TURN server for location privacy purposes, so both TURN servers may be used in this case.

 

This is all spelled out in https://tools.ietf.org/html/draft-schwartz-rtcweb-return-04#section-1.

 

[Aijun] Would you like to explain more detail about “but using only the enterprise's TURN server reveals information about the user (e.g. organizational affiliation)”,  and how do you achieve this goal via the RETURN mechanism?

 

If only the enterprise TURN server is used, and this server is on-premises, then the remote party can determine the location of the caller via IP geolocation of the relay candidates (as well as organization affiliation, by seeing who owns that IP). This is similar to the case where the remote party determines the location of a non-enterprise caller via their host/srflx candidates, although in this case applications can protect against this by forcing all traffic through an application-provided relay server, which provides some amount of location ambiguity. 

 

RETURN attempts to provide this same functionality for the enterprise TURN server case, and to do so it defines how traffic can transit both the enterprise TURN server as well as the application TURN server.

 

e.g.

 

[client] -------- [ETURN] ------------ [ATURN] -------------- [remote party]

 

Best Regards.

 

 

From: Tirumaleswar Reddy (tireddy) [mailto:[e-mail]] 
Sent: Monday, January 12, 2015 1:35 PM
To: Aijun Wang; 'Justin Uberti'
Cc: [e-mail]
Subject: RE: [tram] Comments on draft-patil-tram-turn-serv-selection-00

 

As Justin has pointed out we will be updating the draft with more details on the decisions that could be made by ICE and the application to select the TURN server. TURN-in-TURN communication is already explained in RETURN draft.

 

-Tiru

 

From: tram [mailto:[e-mail]] On Behalf Of Aijun Wang
Sent: Monday, January 12, 2015 7:08 AM
To: Tirumaleswar Reddy (tireddy); 'Justin Uberti'
Cc: [e-mail]
Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00

 

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:[e-mail]> mailto:[e-mail]] On Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Sunday, January 11, 2015 1:40 PM
To: Justin Uberti
Cc:  <mailto:[e-mail]> [e-mail]
Subject: Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00

 

Inline [TR]

 

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

 

 

 

On Fri, Jan 9, 2015 at 7:38 PM, Tirumaleswar Reddy (tireddy) <[e-mail]> 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.

 

[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: <mailto:[e-mail]> [e-mail]] On Behalf Of Justin Uberti
Sent: Friday, January 09, 2015 4:04 AM
To:  <mailto:[e-mail]> [e-mail]
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.