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

[Justin Uberti <[e-mail]>]

On Tue, Jan 13, 2015 at 6:08 PM, Aijun Wang <[e-mail]>
wrote:

> 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.
>

Correct.

>
>
> 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?
>

The network admin typically just wants to set up a proxy server (perhaps a
combined HTTP/TURN proxy) and be done. L2TP would be a much more
complicated design.

Also, I don't understand where the TCP would come from. RETURN would use
UDP.

>
>
> 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?
>

You can think of RETURN as an application-level UDP tunnel technology,
similar to how HTTPS proxying is an application-level TCP tunnel
technology; both will be useful in enterprise situations.

>
>
> 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] <[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] <[e-mail]>] *On
> Behalf Of *Tirumaleswar Reddy (tireddy)
> *Sent:* Sunday, January 11, 2015 1:40 PM
> *To:* Justin Uberti
> *Cc:* [e-mail]
> *Subject:* Re: [tram] Comments on draft-patil-tram-turn-serv-selection-00
>
>
>
> Inline [TR]
>
>
>
> *From:* Justin Uberti [mailto:[e-mail] <[e-mail]>]
> *Sent:* Sunday, January 11, 2015 2:17 AM
> *To:* Tirumaleswar Reddy (tireddy)
> *Cc:* [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:[e-mail]] *On Behalf Of *Justin Uberti
> *Sent:* Friday, January 09, 2015 4:04 AM
> *To:* [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.
>
>
>
>
>
>
>