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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 10 Feb 2015 06:58:48 +0000

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Brandon Williams
> Sent: Tuesday, February 10, 2015 12:54 AM
> To: [email-masked]
> Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-
> ipaddress-privacy-00.txt
> 
> 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. 

There must be trust b/w the endpoint and the TURN server, similar to the way endpoints trusts Anonymous VPN service provider .

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

If the server cannot support privacy then it should not return the new attribute defined in this draft.

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

For every call client makes a decision if privacy is required or not, each time it will learn new alternatives from the TURN server.

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

This mechanism won't work if the user is roaming.

-Tiru

> 
> --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
> >
> > 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
> >
> 
> --
> Brandon Williams; Senior Principal Software Engineer Emerging Products
> Engineering; Akamai Technologies Inc.
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Brandon Williams <[email-masked]>
Date: Tue, 10 Feb 2015 10:08:28 -0500

> For every call client makes a decision if privacy is required or not, each time it will learn new alternatives from the TURN server.

I agree that a mechanism like the one in the draft requires trust b/w 
the endpoint and the TURN server. I was arguing that the "return NNN" 
approach has that same limitation, and that it needs some explicit 
indication of the privacy requirement in order to know which NNN 
alternates to return. It doesn't seem to simplify the solution.

> This mechanism won't work if the user is roaming.

How does it not work if the user is roaming? It won't give good 
performance, but I maintain that performance goals and privacy goals are 
in conflict as long as you must disclose the relay address to the remote 
peer. The point of always using the same relay server, even when 
roaming, is to hide details about your location (such as the fact that 
you're roaming).

--Brandon

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 10 Feb 2015 16:49:23 +0000

> From: Brandon Williams [mailto:[email-masked]]
> Sent: Tuesday, February 10, 2015 8:38 PM
> To: Tirumaleswar Reddy (tireddy); [email-masked]
> >> Subject: Re: [tram] FW: New Version Notification for
> >> draft-reddy-tram-turn- ipaddress-privacy-00.txt
> >>
> >> 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.
> >
> > There must be trust b/w the endpoint and the TURN server, similar to the
> way endpoints trusts Anonymous VPN service provider .
> >
> >> 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?
> >
> >> 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?
> >
> > For every call client makes a decision if privacy is required or not, each time
> it will learn new alternatives from the TURN server.
> 
> I agree that a mechanism like the one in the draft requires trust b/w the
> endpoint and the TURN server. I was arguing that the "return NNN"
> approach has that same limitation, and that it needs some explicit indication
> of the privacy requirement in order to know which NNN alternates to return.
> It doesn't seem to simplify the solution.

Agreed.

-Tiru

> 
> >
> >>
> >> 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.
> >
> How does it not work if the user is roaming? It won't give good performance,
> but I maintain that performance goals and privacy goals are in conflict as long
> as you must disclose the relay address to the remote peer. The point of
> always using the same relay server, even when roaming, is to hide details
> about your location (such as the fact that you're roaming).
> 
> --Brandon
> 
> >
> > -Tiru
> >
> >>
> >> --Brandon
> >>
> >>> 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.
> >>>
> >>> 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]
> >>>
> >>> 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
> >>>
> >>> 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.
> >>>
> >>> 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
> >>>
> >>>
> >> Brandon Williams; Senior Principal Software Engineer Emerging
> >> Products Engineering; Akamai Technologies Inc.
> >>