Subject: [tram] location privacy considerations for TURN

From: Brandon Williams <[email-masked]>
Date: Mon, 09 Feb 2015 11:37:43 -0500

Hi all,

There has been recent discussion about location privacy on the list. One 
approach to location privacy has been to select a relay server that will 
not give away important location information, but one key issue has been 
how to determine whether an allocated relay address meets the peer's 
location privacy requirements. If such a relay server can be identified, 
then the location privacy requirements can be met, but this could 
sacrifice the user's performance expectations.

We have been working on some ideas about how to address these privacy 
concerns by adding a new channel binding mechanism to TURN that does not 
require a peer to know even the relay address of the remote peer. Before 
I try to engage the WG on a possible solution, I first want to get some 
sense of whether I'm on target in the way that I'm framing the problem 
(location privacy vs. performance).

I've included a rough cut of the problem statement below (this seemed 
better than publishing a draft just for the one page of content) and 
will appreciate feedback from the list. Have I clearly stated the 
problem? Are there other ways in which location privacy could negatively 
impact performance? And is anyone else interested in trying to solve 
this problem within the WG?

Thanks,
--Brandon

-----
1.  Introduction

    Traversal Using Relay around NAT (TURN) [RFC5766] defines a mechanism
    for establishment of peer-to-peer communication using a data relay
    server.  Although not part of the explicit intent of the protocol, a
    TURN relay can also be used in a way that provides enhanced privacy
    by hiding the network geographic location of one or both peers from
    the other peer.  However, location privacy considerations can have a
    negative impact on latency, both during call setup and throughout the
    life of the session.

1.1.  Location Privacy During Session Initiation

    Peer-to-peer session initiation typically involves relay of an
    invitation via a rendezvous server.  The initiating peer sends an
    invitation to the rendezvous server, which relays the invitation to
    the receiving peer for acceptance.  Although the rendezvous server's
    role requires it to maintain a registry of peer addresses, location
    privacy demands that it should not send the receiving peer's address
    to the initiating peer until the receiving peer has accepted the
    call.

    When direct connectivity between the peers is possible, Interactive
    Connectivity Establishment (ICE) [RFC5245] connectivity checks can
    proceed and complete successfully as soon as the receiving peer has
    received the invitation, since the initiating peer's host and
    reflexive addresses can be delivered to the receiving peer along with
    the invitation.  However, when the initiating peer requires a TURN
    relay, the receiving peer's address information must be delivered via
    the rendezvous server with the invitation response in order for the
    initiating peer to send a ChannelBind or CreatePermission request.

    Since the rendezvous server is often centrally located, even one-way
    latency between the peers via the rendezvous server can be
    significantly longer than the latency for direct connectivity,
    meaning that initiation of successful peer-to-peer communication can
    take significantly longer when a TURN relay is used, even if the
    relay server is optimally selected for end-to-end performance.

1.2.  Location Privacy and Call Quality

    Many peer-to-peer applications (e.g. voice or video calls) are
    sensitive to path latency, with long one-way latencies often leading
    to a negative impact on user experience.  For this reason, it can be
    important to select a relay server that is on-path between the peers
    in order to prevent use of the relay from negatively impacting
    latency.  Achieving this goal can mean selecting the relay based on
    its relative proximity to the associated peer.  For this reason, the
    relay address itself could provide information about the location of
    the peer.  In other words, a user who wishes not to disclose her/his
    current location to the remote peer might have to intentionally
    select a TURN relay that is suboptimal for performance.
-----

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 9 Feb 2015 19:50:21 +0000

Do you have any performance numbers to show the impact of the problem ?

-Tiru

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Brandon Williams
> Sent: Monday, February 09, 2015 10:08 PM
> To: [email-masked]
> Subject: [tram] location privacy considerations for TURN
> 
> Hi all,
> 
> approach to location privacy has been to select a relay server that will not
> give away important location information, but one key issue has been how to
> determine whether an allocated relay address meets the peer's location
> privacy requirements. If such a relay server can be identified, then the
> location privacy requirements can be met, but this could sacrifice the user's
> performance expectations.
> 
> require a peer to know even the relay address of the remote peer. Before I
> try to engage the WG on a possible solution, I first want to get some sense of
> whether I'm on target in the way that I'm framing the problem (location
> privacy vs. performance).
> 
> better than publishing a draft just for the one page of content) and will
> appreciate feedback from the list. Have I clearly stated the problem? Are
> there other ways in which location privacy could negatively impact
> performance? And is anyone else interested in trying to solve this problem
> within the WG?
> 
> Thanks,
> --Brandon
> 
> -----
> 1.  Introduction
> 
> 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: Justin Uberti <[email-masked]>
Date: Mon, 9 Feb 2015 14:31:59 -0800

I agree that these goals seem to be at odds with one another, so if you
have a proposal to solve both simultaneously I think you are on the right
track.

On Mon, Feb 9, 2015 at 11:50 AM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> not
> I

---

From: Aijun Wang <[email-masked]>
Date: Tue, 10 Feb 2015 07:44:39 +0800

If the communication peers use one well known relay addresses, then it will conceal its location from its peer. 
Under such architecture, each distributed TURN server will have one unique well known address, and the rendezvous server can select one most suitable TURN server(located at the most suitable optimal path) based on the proximity of the reflex addresses of the two peers, or it can select another TURN server if the client want more location privacy than performance.  On the other hand, if these TURN servers use one ANYCAST well known address,then the privacy and performance can be achieved simultaneously.

If the above mechanism is suitable, then we need another command to bind the two peers at the TURN relay server(because each peer send traffic to the well known relay address, the TURN server should know where is the corresponding peer. We have proposed such solution in draft http://datatracker.ietf.org/doc/draft-wang-tram-turnlite/ and are trying to revise it based on the feedback from our presentation in last IETF meeting and the discuss recently in this WG list.

This lightweight TURN solution can decouple the TURN function from the ICE procedure, alleviate the relay address allocation burden of the TURN server, make the TURN function be easily incorporated in some already distributed deployed network devices, cover almost all the functions provided by current TURN solution. And meet the requirements of local privacy preserve and achieve best performance described above.

From Aijun Wang

> 在 2015年2月10日，06:31，Justin Uberti <[email-masked]> 写道：
> 
> I agree that these goals seem to be at odds with one another, so if you have a proposal to solve both simultaneously I think you are on the right track.
> 
>> On Mon, Feb 9, 2015 at 11:50 AM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:

---

From: Brandon Williams <[email-masked]>
Date: Tue, 10 Feb 2015 09:33:36 -0500

On 02/09/2015 06:44 PM, Aijun Wang wrote:
> Under such architecture, each distributed TURN server will have one
> unique well known address, and the rendezvous server can select one most
> suitable TURN server(located at the most suitable optimal path) based on
> the proximity of the reflex addresses of the two peers, or it can select
> another TURN server if the client want more location privacy than
> performance.

As soon as you use a publicly available address and disclose it to the 
other peer, you begin to give away information about your location, 
especially (though not exclusively) if the address is selected based on 
proximity.

> On the other hand, if these TURN servers use one ANYCAST
> well known address,then the privacy and performance can be achieved
> simultaneously.

You cannot reliably use an ANYCAST address for a long-lived data flow, 
which is why TURN auto-discovery redirects the peer to a unicast address 
in response to the allocate request.

>
> If the above mechanism is suitable, then we need another command to bind
> the two peers at the TURN relay server(because each peer send traffic to
> the well known relay address, the TURN server should know where is the
> corresponding peer. We have proposed such solution in draft
> http://datatracker.ietf.org/doc/draft-wang-tram-turnlite/ and are trying
> to revise it based on the feedback from our presentation in last IETF
> meeting and the discuss recently in this WG list.

When the "turnlite" proposal was presented in Honolulu, the WG 
essentially said "this is not TURN". At least that was my understanding 
of the response. Unless the proposal has been modified so significantly 
that it is indistinguishable from the first draft, I would not expect 
the WG response to change. I am not trying to discourage you from 
working on your idea. I'm simply suggesting that, since it doesn't 
really appear to be an update to TURN, this WG might not be the best 
forum for the proposal.

--Brandon

>
> This lightweight TURN solution can decouple the TURN function from the
> ICE procedure, alleviate the relay address allocation burden of the TURN
> server, make the TURN function be easily incorporated in some already
> distributed deployed network devices, cover almost all the functions
> provided by current TURN solution. And meet the requirements of local
> privacy preserve and achieve best performance described above.
>
>
>
>
>  From Aijun Wang
>
>
> 在 2015年2月10日，06:31，Justin Uberti <[email-masked]
> <mailto:[email-masked]>> 写道：
>
>> I agree that these goals seem to be at odds with one another, so if
>> you have a proposal to solve both simultaneously I think you are on
>> the right track.
>>
>> On Mon, Feb 9, 2015 at 11:50 AM, Tirumaleswar Reddy (tireddy)
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     > From: tram [mailto:[email-masked]
>>     <mailto:[email-masked]>] On Behalf Of Brandon Williams
>>     > To: [email-masked] <mailto:[email-masked]>
>>     > [email-masked] <mailto:[email-masked]>
>>     [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

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

If you mean real-world data, then I could possibly provide some example 
numbers for the impact on call setup, but I don't have numbers for the 
call quality impact because I don't provide a true location privacy 
service today.

The impact of the rendezvous server's location during call setup will 
have a lot to do with how far off path it is for the individual peer 
pair. I have seen cases where the one way latency via the rendezvous 
server is a few hundred msec. IOW, the privacy concern is probably not 
extending the call setup time all that much. I have a hard time getting 
excited about this one, though I've got a customer who cares about it. 
The one way in which it's a problem for performance is that the 
additional delay to starting the ICE check via the relay can cause the 
relay path to be rejected as a result of the direct check completing 
first, even if the relay provides significantly better latency. That 
issue can be resolved by some of the work going on to improve ICE.

The call quality issue is the one that I don't expect there would be 
much question about, since it's fairly similar to the standard problem 
statement for use of a relay ... if the relay isn't on-path, then it 
will negatively impact performance to the degree that it isn't on-path. 
Client-side implementers probably have a better sense of what kind of 
latency impact would be observable by the user than I do.

--Brandon

---

From: Aijun Wang <[email-masked]>
Date: Tue, 10 Feb 2015 23:45:08 +0800

OK, Brandon, thank you for your advices. We are trying modify the previous draft, which will try to solve several problems that mentioned in this WG mail list. 

Other responses for your concerns points are described inline below.

From Aijun Wang

> 在 2015年2月10日，22:33，Brandon Williams <[email-masked]> 写道：
> 
> As soon as you use a publicly available address and disclose it to the other peer, you begin to give away information about your location, especially (though not exclusively) if the address is selected based on proximity.

Proximity is just one principle, the rendezvous server can select other TURN server for the two peers, based on the service policy that required by the communication peers.
> You cannot reliably use an ANYCAST address for a long-lived data flow, which is why TURN auto-discovery redirects the peer to a unicast address in response to the allocate request.
> 
Why can't? If one of the TURN server failed, the peer can reselect another TURN server to relay data. DS-Lite is using the ANYCAST method to encapsulate and decapsulate the IPv4inIPv6 packet, which is also long lived data flow.

> When the "turnlite" proposal was presented in Honolulu, the WG essentially said "this is not TURN". At least that was my understanding of the response. Unless the proposal has been modified so significantly that it is indistinguishable from the first draft, I would not expect the WG response to change. I am not trying to discourage you from working on your idea. I'm simply suggesting that, since it doesn't really appear to be an update to TURN, this WG might not be the best forum for the proposal.
> 

This draft has the same aim to achieve as current TURN draft, that is to solve several problems when two peers are behind NAT devices and can't  build the direct channel between them. 

We also admire the achievement of current related  ICE/TURN draft, but as all the TRAMer discussed here, there are still some scenarios that current ICE/TURN draft can't solve, or solve in one complex design, so why don't we also consider another possible viewpoint to solve these problems? Especially in one lightweight manner?

---

From: Brandon Williams <[email-masked]>
Date: Tue, 10 Feb 2015 11:09:57 -0500

Let me put it less categorically ...

If you want to use ANYCAST in a system that requires state to be 
maintained, then either you have to reliably share state across all 
machines that share the ANYCAST address, or you have to be prepared for 
flows to break when routing drives them to move to machines that do not 
have the state already. Protocol designers often avoid the state sharing 
problem by quickly moving the flow to a unicast address, as is done with 
the proposed TURN ANYCAST discovery mechanism. Switching to ANYCAST 
addresses for TURN relays in order to provide privacy would be 
complicated due to the state sharing requirements.

--Brandon

---

From: Justin Uberti <[email-masked]>
Date: Thu, 12 Feb 2015 15:30:36 -0800

Given that the mouth-to-ear target is 150ms (ITU recommendation), and the
impact of selecting a non-local TURN server can easily be 50 ms (e.g.
routing to us-central instead of us-west), it's pretty clear that the
additional latency can be fatal regarding whether the application is able
to hit the target or not.

On Tue, Feb 10, 2015 at 7:26 AM, Brandon Williams <
[email-masked]> wrote:

> numbers for the impact on call setup, but I don't have numbers for the call
> quality impact because I don't provide a true location privacy service
> today.
>
> The impact of the rendezvous server's location during call setup will have
> a lot to do with how far off path it is for the individual peer pair. I
> have seen cases where the one way latency via the rendezvous server is a
> few hundred msec. IOW, the privacy concern is probably not extending the
> call setup time all that much. I have a hard time getting excited about
> this one, though I've got a customer who cares about it. The one way in
> which it's a problem for performance is that the additional delay to
> starting the ICE check via the relay can cause the relay path to be
> rejected as a result of the direct check completing first, even if the
> relay provides significantly better latency. That issue can be resolved by
> some of the work going on to improve ICE.
>
> The call quality issue is the one that I don't expect there would be much
> question about, since it's fairly similar to the standard problem statement
> for use of a relay ... if the relay isn't on-path, then it will negatively
> impact performance to the degree that it isn't on-path. Client-side
> implementers probably have a better sense of what kind of latency impact
> would be observable by the user than I do.
>
> --Brandon
>
>