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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 9 Feb 2015 18:10:41 +0000

Inline [TR2]

From: Benjamin Schwartz [mailto:[email-masked]]
Sent: Friday, February 06, 2015 9:49 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Justin Uberti; [email-masked]; Simon Perreault
Subject: RE: [tram] FW: New Version Notification for draft-reddy-tram-turn-ipaddress-privacy-00.txt

I appreciate the goal of this work.  Maybe a slightly different strategy would be more easily accepted in the working group.  What if the client could query the server for a list of alternate TURN servers?  Then the client could have the option of selecting a server based on geolocation, but the client would not have to convey its privacy goals to the server explicitly.

[TR2] Interesting alternative, it has pros and cons that client will not have to convey its privacy goals to server explicitly but if it receives NNN number of alternate servers it will have to try all of them and pick the one which suites its privacy needs (TURN server can probably give additional information on the privacy levels that can be provided by each of the alternate servers to address this problem)

-Tiru
Inline [TR]

From: Justin Uberti [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, February 06, 2015 6:21 AM
To: Tirumaleswar Reddy (tireddy)
Cc: Benjamin Schwartz; Simon Perreault; [email-masked]<mailto:[email-masked]>
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.

[TR] We are evaluating how the client can covey its ‘privacy’ needs in this new attribute to the TURN server so that it can take appropriate action and the server responds if the client ‘privacy’ requirement can be met fully or partially.

-Tiru

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) <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram

---

From: Brandon Williams <[email-masked]>
Date: Mon, 09 Feb 2015 14:24:26 -0500

I'm not sure that the "return NNN" approach can address the issue 
anyway. If you take the case of a broadly distributed system (e.g. a 
single system with several hundred POPs, for example), how will it 
decide which "NNN" alternates to provide? If I have 3 reasonable relay 
servers for your location and you want 3 alternates, should I 
intentionally not return the 3 reasonable ones?

If the only purpose of this method is privacy, then the server could 
pick a set of alternates that is broadly distributed geographically. It 
could even indicate a score of some sort that tells the client how 
closely correlated each relay server is to the client address. But you 
still have the trust issue here. If the server returned a bad candidate 
set, did it do so because it didn't have options, or because it doesn't 
want to give you location privacy? And if the alternates are good, how 
will client select alternates over time to ensure that this selection 
doesn't give enough away about where the client isn't to allow you to 
figure out where the client is?

If the client has to select the relay very carefully in order to ensure 
that it gets the privacy characteristics that it wants, then it's 
probably better to provide a server with a fixed location that never 
changes no matter where you're located. That way, you can always select 
the privacy relay when that's what you want and know that the relay's 
location will never say something useful about you all by itself.

--Brandon

On 02/09/2015 01:10 PM, Tirumaleswar Reddy (tireddy) wrote:
> Inline [TR2]
>
> *From:*Benjamin Schwartz [mailto:[email-masked]]
> *Sent:* Friday, February 06, 2015 9:49 PM
> *To:* Tirumaleswar Reddy (tireddy)
> *Cc:* Justin Uberti; [email-masked]; Simon Perreault
> *Subject:* RE: [tram] FW: New Version Notification for
> draft-reddy-tram-turn-ipaddress-privacy-00.txt
>
> I appreciate the goal of this work.  Maybe a slightly different strategy
> would be more easily accepted in the working group.  What if the client
> could query the server for a list of alternate TURN servers?  Then the
> client could have the option of selecting a server based on geolocation,
> but the client would not have to convey its privacy goals to the server
> explicitly.
>
> [TR2] Interesting alternative, it has pros and cons that client will not
> have to convey its privacy goals to server explicitly but if it receives
> NNN number of alternate servers it will have to try all of them and pick
> the one which suites its privacy needs (TURN server can probably give
> additional information on the privacy levels that can be provided by
> each of the alternate servers to address this problem)
>
> -Tiru
>
> Inline [TR]
>
> *From:*Justin Uberti [mailto:[email-masked]
> <mailto:[email-masked]>]
> *Sent:* Friday, February 06, 2015 6:21 AM
> *To:* Tirumaleswar Reddy (tireddy)
> *Cc:* Benjamin Schwartz; Simon Perreault; [email-masked]
> <mailto:[email-masked]>
> *Subject:* Re: [tram] FW: New Version Notification for
> draft-reddy-tram-turn-ipaddress-privacy-00.txt
>
> 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.
>
> [TR] We are evaluating how the client can covey its ‘privacy’ needs in
> this new attribute to the TURN server so that it can take appropriate
> action and the server responds if the client ‘privacy’ requirement can
> be met fully or partially.
>
> -Tiru
>
> On Wed, Feb 4, 2015 at 10:50 AM, Tirumaleswar Reddy (tireddy)
> <[email-masked] <mailto:[email-masked]>> 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
>
>
> [email-masked] <mailto:[email-masked]>

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.