Subject: [Pidloc] draft-nordmark-id-loc-privacy

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 4 Oct 2018 10:02:12 -0500

Hi Luigi, Dirk, all,

So far we have a number of reviews on Erik's draft indicating some
editorial issues and asking for clarification of some parts. All that is
good.

What I suggest is that we should also look into what he is saying in that
draft, what is he suggesting as the future work to do?

Here I am going to summary what I could find out:

- We should concentrate on long-lived identifiers;

- Worry not much on designing a privacy based unified mapping mapping
system which we had concentrated in our previous activity. This is because only
trusted devices can access the mappings  in an operator network

- Instead worry about minimizing the privacy implication one can explore
limiting to which peers and when the ID/ locator binding are exposed.

The cases where ID/locator bindings are exposed (especially any mobile
devices)
- Family and friends for example where are parents sharing young children
location
- In industrial IoT case, the devices belonging to the same company
share ID/locator
bindings but not share the ID/locator binding with third parties

In Section 6, the draft points to some possibilities on how this limiting
can be achieved:

1. pointing a locator for some fixed anchor point, like PGW or UPF

2. injecting routing prefixes for the ID prefixes into the normal routing
system

3. not providing any stable locators across this boundary; only allow
ephemeral IP addresses per session or otherwise limited exposure.

In short, the draft is coming up with a lot work to do.
We suggest that the group takes a close look into all these points and see
what we can do :-)
Regards,
Behcet & Dirk

---

From: Tom Herbert <[email-masked]>
Date: Thu, 4 Oct 2018 11:15:48 -0700

On Thu, Oct 4, 2018 at 8:02 AM, Behcet Sarikaya <[email-masked]> wrote:
> Hi Luigi, Dirk, all,
>
> So far we have a number of reviews on Erik's draft indicating some editorial
> issues and asking for clarification of some parts. All that is good.
>
> - Worry not much on designing a privacy based unified mapping mapping system
> which we had concentrated in our previous activity. This is because only

I don't believe this case is relevant. There's already applications
that I can use to track my kids (like Life360). These use the GPS in
mobile devices and secure connections to trasmit location information;
it's far more accurate and secure than trying to deriving location
information from a few bits in an IP address. I think it's a hard
requirement that Identifiers (IP addresses in general) must not expose
geo location or mobile devices, and it follows that identifier/locator
bindings should never be shared outside a network except LEA orders.

Tom

> - In industrial IoT case, the devices belonging to the same company share
> ID/locator bindings but not share the ID/locator binding with third parties
>
> --
> Pidloc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pidloc
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 5 Oct 2018 09:24:16 -0500

On Thu, Oct 4, 2018 at 1:15 PM Tom Herbert <[email-masked]> wrote:

> editorial
> information from a few bits in an IP address.

Yes, this has already  been alluded to in the draft:

Today such location sharing happens at an application layer using GPS
   coordinates.

I think it's a hard
> bindings should never be shared outside a network except LEA orders.
Here is the rest of the above paragraph I quoted from Erik's draft:

But while such sharing is in effect, it wouldn't be
   unreasonable to also consider sharing IP locators to make it more
   efficient or more robust to e.g., route a video feed from one device
   to another.

What do you think?

Behcet

Tom

---

From: Tom Herbert <[email-masked]>
Date: Fri, 5 Oct 2018 07:54:12 -0700

>    efficient or more robust to e.g., route a video feed from one device

Sure, it could be considered, but the benefits of exposing a third
party to identifier/locator mappings would have to be weighed against
the cost. The potential cost is weakened user privacy and security.
Locators will convey geo location in a mobile network, so if someone
knows identifier to locator mapping, then they know location of node
with that identifier. But more than that, knowledge of
identifier/locator mappings allow correlations to be made between
identifiers. For instance, if a device is using some number of
untrackable and uncorrelatable identifiers for privacy, knowledge of
identifier to locator mappings allows correlations to be made and the
identifiers that belong to the device can be deduced and the users can
be tracked.

Tom

>> > share

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 5 Oct 2018 10:09:57 -0500

On Fri, Oct 5, 2018 at 9:54 AM Tom Herbert <[email-masked]> wrote:

> >> On Thu, Oct 4, 2018 at 8:02 AM, Behcet Sarikaya <[email-masked]
> >
> >> wrote:
> >> > Hi Luigi, Dirk, all,
> >> >
Absolutely.

One reason why I posted this mail was to encourage the discussion of
solution approaches in different
IdLoc protocols.
How could we treat each of cases of Family and Friends, Industrial IoT,
etc. in ILA, ILNP, and LISP?
What about the three points in Section 6?

Behcet

---

From: <[email-masked]>
Date: Mon, 8 Oct 2018 15:01:32 +0000

See below …
Thanks and BR, Dirk
On Fri, Oct 5, 2018 at 9:54 AM Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:
On Fri, Oct 5, 2018 at 7:24 AM, Behcet Sarikaya <[email-masked]<mailto:[email-masked]>> wrote:
>
>
> On Thu, Oct 4, 2018 at 1:15 PM Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> On Thu, Oct 4, 2018 at 8:02 AM, Behcet Sarikaya <[email-masked]<mailto:[email-masked]>>
>> wrote:
>> > Hi Luigi, Dirk, all,
>> >

Absolutely.

One reason why I posted this mail was to encourage the discussion of solution approaches in different
IdLoc protocols.
How could we treat each of cases of Family and Friends, Industrial IoT, etc. in ILA, ILNP, and LISP?
What about the three points in Section 6?

Behcet

DH> I think we have to differentiate here between IP Locator mentioned above and geolocation. While the first used for end point routing may be statically correlated to a trackable geographic position and thus allow for privacy related tracking there should be measures to obfuscate this mapping to the outside world as the one between name or Identity to current location.
As such measures could serve the choices how to handle ID/locator mapping mentioned by Erik in sect. 6:
-   still using an ID/locator system but pointing a locator for some fixed anchor point,
- injecting routing prefixes for the ID prefixes into the normal routing system
- not providing any stable locators across the boundary between Id/Loc domain and rest of world …

I have no preference for the time being

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 8 Oct 2018 11:20:28 -0500

Hi Tom,

On Mon, Oct 8, 2018 at 10:01 AM <[email-masked]> wrote:

> with that identifier.

> But more than that, knowledge of
So you are saying that there is a cost for allowing Id/Loc mappings.
Do you think that letting family and friends or Industrial IoT devices that
belong to my company know my locator also
poses similar cost or issue? What should we do?
How could this effect, e.g. ILA?

Behcet

> DH> I think we have to differentiate here between IP Locator mentioned
> above and geolocation. While the first used for end point routing may be
> statically correlated to a trackable geographic position and thus allow for
> privacy related tracking there should be measures to obfuscate this mapping
> to the outside world as the one between name or Identity to current
> location.
>

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 11 Oct 2018 10:55:59 +0200

Hi,

> On 4 Oct 2018, at 17:02, Behcet Sarikaya <[email-masked]> wrote:
> 
[snip]

> 
> In Section 6, the draft points to some possibilities on how this limiting can be achieved:
> 

This would be kind of a home agent, right?
In this case ww will end up with possibly a long stretch in the path (depending on mobility).

> 2. injecting routing prefixes for the ID prefixes into the normal routing system
> 

LISP has this approach described in RFC 6832.

I think it is not completely disjoint from the previous point. The proxies will become a “fixed anchor point”.

Or you had something else in mind? 

> 3.  not providing any stable locators across this boundary; only allow ephemeral IP addresses per session or otherwise limited exposure.

When you say “ephemeral IP addresses” you mean the RLOCs or the IDs?

Ciao

L.

> We suggest that the group takes a close look into all these points and see what we can do :-)
> Regards,
> Behcet & Dirk
> -- 
> Pidloc mailing list
> [email-masked]

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 11 Oct 2018 11:27:33 +0200

> On 5 Oct 2018, at 17:09, Behcet Sarikaya <[email-masked]> wrote:
> 
> 

Not sure I follow the question here. 

You mean how these protocol can behave in the listed scenarios or how these protocol can avoid tracking ID?

Ciao

L.

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 15 Oct 2018 13:46:37 -0500

Hi Luigi,

On Thu, Oct 11, 2018 at 3:56 AM Luigi Iannone <[email-masked]> wrote:

> Here pointing to a fixed anchor means that a locator is given from the
fixed anchor's address space. This is a practice in use currently in 4G
networks.
The end result is that UE or mobile location can not be determined
precisely from such a locator.

> When you say “ephemeral IP addresses” you mean the RLOCs or the IDs?

ephemeral means a locator which is valid only for a short period of time.
 It is a locator not identifier.

Behcet