Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt

Inline [TR]

From: Hutton, Andrew [mailto:andrew.hutton@unify.com]
Sent: Friday, February 06, 2015 4:19 PM
To: Justin Uberti; Tirumaleswar Reddy (tireddy)
Cc: Simon Perreault; Benjamin Schwartz; tram@ietf.org
Subject: RE: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt

On a first read I am also rather skeptical about handing this privacy function over to the TURN server.

[TR] Please clarify why this is a concern ?
If privacy is provided let’s say using Tor or anonymous VPN service then the endpoint is trusting these services.

The draft introduces the first argument I have seen against using https://tools.ietf.org/html/draft-schwartz-rtcweb-return-03 in that it states:

“If the third party offered TURN server can provide IP address privacy then the application can avoid TURN-in-TURN mechanism discussed in[I-D.schwartz-rtcweb-return<http://tools.ietf.org/html/draft-reddy-tram-turn-ipaddress-privacy-00#ref-I-D.schwartz-rtcweb-return>] and thus avoid the overhead of using RETURN proxying”.

However it does not seem to me that the overhead of using a RETURN proxy is really that significant given that the RETURN proxy is likely to be close to the client in the enterprise proxy/firewall or in the access network.

[TR] The application provided TURN server may not always be close to the endpoint or the user may not trust the application server. RETURN proxying is certainly useful in certain scenarios and this draft helps client determine if RETURN proxying is required not. This draft can be used with RETURN proxying, for example based on the ‘privacy’ need conveyed the client the  application provided TURN server may point the client to an alternate TURN server which can meet the client’s ‘privacy’ needs.

-Tiru

Andy

From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: 06 February 2015 00:51
To: Tirumaleswar Reddy (tireddy)
Cc: Simon Perreault; Benjamin Schwartz; tram@ietf.org
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt

I agree with Simon and Ben in being skeptical about this proposal.

The client is the only party which knows exactly what 'privacy' means, and there is no trivial way to serialize this into a single attribute for the TURN server.

As such, I think this decision should be left entirely to the client.

On Wed, Feb 4, 2015 at 10:50 AM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com<mailto:tireddy@cisco.com>> wrote:
I agree that the client can do equally well itself, by sending a STUN Binding Request and comparing the response to the TURN server's own IP address.

[TR3] The difference this draft brings in is that it helps the TURN server (offered by a global or cloud service) to determine that the client wants privacy and level of privacy required conveyed in the new STUN attribute, the TURN server determines suitable alternate TURN server that can offer the required level of privacy.

-Tiru

_______________________________________________
tram mailing list
tram@ietf.org<mailto:tram@ietf.org>
https://www.ietf.org/mailman/listinfo/tram