Re: [Ideas] Comments on draft-ccm-ideas-identity-use-cases-02

[Tom Herbert <[e-mail]>]

On Mon, Oct 16, 2017 at 5:31 PM, Uma Chunduri <[e-mail]> wrote:
> Thx for the feedback on this version. I saw Alex's responses - some more of it below.
>
> --
> Uma C.
>
> ----
>
>         >I think the most critical use case isn't described here. It is in mobility where a devices may have many thousands of identifiers assigned to it. When the device moves, all the identifiers must move
>                > with it and want this to be performed in one operation in the infrastructure. Without the ability to perform a group operation, identifier-locator might not be able to scale. Today this is done by virtue
>                >of moving a device prefix, but device prefixes do not have reasonable privacy or security properties (see ongoing discussion in v6 ops about host prefix assignment and privacy ramifications).
> [Uma]: Yes.
>
>         >The phrase "long-lived" is ill-defined. Not just in this document, but I've noticed this popping up in other WGs. The obvious problem is that there is no common definition of the time it takes something to be long-lived.
>                 >Someone might say a day, another an hour, a minute, a second, ten milliseconds etc. In identifier-locator, it may be that a node wants to use a different identifier in every connection it creates which is the best privacy it can get.
> [Uma]:  It's relative. This is not new and not introduced in IDEAS.  This is nothing but HIT in HIP or EID in LISP (which are used for location resolution today).  The context of this usage is to differentiate from the one time anonymous identifiers used in the data plane.. Can clarify further.
>
>         >This by the way is why I don't think end user devices should ever participate in identifier-locator protocols...
>  [Uma]: You  are making a pretty broad statement here.  Which device uses this is orthogonal to IDEAS.   We have a host based solution (ID/LOC) HIP  and a network based solution LISP.
>
Uma,

This problem I highlighted would only exist on public networks where
end user devices are not under complete control of the
infrastructure-- i.e. smart phones on a public carrier network. In a
private data center for instance, where all hosts can be controlled,
there is no issue in running identifier-locator on hosts and that in
fact is a common deployment of network virtualization.

The exploit I'm conjecturing would work like this:

* Suppose that a UE (e.g. a smartphone) participating in an
identifier/locator protocols is hacked.
* The only thing the hacker does is to tap all packets sent or
received on wireless network interface.
* In order to be able to tap packets all a user needs to do is "root"
the Android device (that is gain root access) and then run tcpdump.
This is not difficult to do, there are instructions on the web how to
set this up.
* Once tcpdump is running, the hacker can now see the locators of
destinations the device is sending packets and can easily correlate
those packets to the higher level communications. It can also derive
their device's locator by looking at received packets.
* The hacker can then just drive around sending traffic between two
devices in their car. From this, they can create a geo map of
locators. The granularity of this map is the granularity of the
locators. Presumably, locators might refer to eNodeBs, so smaller
cells yield more accurate locator to physical location mapping.
* Given that one hacker can do this, then thousands will do it and web
sites will spring up that provide locator geo maps in a mash up.
* Efforts to obfuscate or rotate identifiers does not help much here.
Obfuscation complicates routing in the network such that translations
need to happen anyway. Periodic rotation of locators is defeated if
there are enough devices doing the mapping to keep the maps up to
date.
* The net effect is that this enables stalkers. An individual simply
initiates a communication with their target. For instance, this could
be a chat or phone call. If in doing this the locators for the device
belonging to the target are made visible to the hacker, then the
physical location of the target can be deduced using the locator geo
maps described above to the accuracy of the locator to physical world
maps.

It's true this may be orthogonal to the design of a mapping system or
identifier-locator protocol, however it does illustrate the dangers of
not adequately protecting sensitive information. Anyone who works at
companies like Apple and Google that regularly collect device
geo-location can vouch that it is among the most sensitive of all the
PII they collect. Accordingly, they implement extremely strong access
controls to the point that even that only a tiny number of employees
can directly access the data.

Tom

>
> _______________________________________________
> Ideas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ideas