Re: [Ila] [5gangip] PS draft: New Version Notification for draft-hspab-5gangip-atticps-00.txt

[Tom Herbert <[e-mail]>]

>
>
>> This is true today when devices have address or assigned a single /64.
>> One alternative is gives users thousands or millions of addresses
>> (identifier). Identifier/locator split should facilitate that.
>
>
> Please suggest some text.
>
>

Here is my postulated privacy exploit that defeats periodic address
rotation [RFC4951]  and would be solved by single use addresses (a
different address per connection).


   -

   The attacker creates an “always connected” app that provides some
   seemingly benign service and users download the app.
   -

   The app includes some sort of persistent identity. For instance, this
   could be a login to account.
   -

   The backend server for the app logs the user identity and IP address
   they are using each time they connect.
   -

   When an address change happens, existing connections on the user device
   are disconnected. The app will receive a notification and immediately
   attempt to reconnect using the new source address.
   -

   The backend server will see the new connection and log the new IP
   address as being used by the user.
   -

   Thus, the server has a real-time record of users and the IP address they
   are using.
   -

   The attacker gains access to packet traces taken at some point in the
   Internet. The addresses in the captured packets can be time correlated with
   the server database to deduce the identity of the source of packets for
   flows communications unrelated to the app.



> Note
>> that this effect is already provided by NAT since every connection
>> through a NAT is translated to non-trackable address/port. NAT has
>> some law enforcement agencies freaking out because of its strong
>> (inadvertent) privacy!
>>
>> This reminds me some people say ILA is a NAT.
>
>
Mark Smith provided the best explanation as to why ILA is not NAT:

"The process ILA performs is a perfect transform, once at ingress to the
ILA domain, into the ILA domain's address space, and a perfect
transformation back at ILA egress. If the transformation isn't perfect,
then a fault has occurred.

The other reason I'd avoid "translate" is that it in the IETF it carries
with it the association with IPv4 NAT and its drawbacks. ILA doesn't suffer
from these issues because of the full reversal of the address changes upon
egress from the ILA domain.

(So how come I don't like NAT at all, yet am ok with what ILA is doing? The
full reversal of the address charges at ILA egress is the first reason.
Secondly, within the ILA domain, the ingress ILA device is a host, that is
in effect originating the packet within the ILA domain it is sending to the
egress ILA device, which is also a host or end-point within the ILA domain.

The ILA domain is effectively a virtual link layer or an underlay network
for the traffic being carried between hosts outside of the ILA domain. As
long as the ILA domain is perfectly transparent to the overlay network and
its hosts, then what ever happens within the ILA domain doesn't matter,
similar to how link layer compression, as long as fully and perfectly
reversed, also doesn't matter.)"


> "Privacy of identifiers is especially an issue for a UE communication
>
> with a server like Google, Facebook, LinkedIn, etc."
>>
>> You might want to mention that simple identifier rotation [RFC4914] is
>> not enough these days..
>>
>> Sure.
>
>
>> "Privacy issue can be mitigated only if Id-Loc system has proxy mode
>> of operation.  In proxy mode, user traffic is intercepted by a proxy.
>> Proxy node which could be placed at the subnet router or site border
>> router.  The router tunnels the traffic to the server.  In the process
>> UE identifier becomes hidden and this hopefully removes privacy
>> issues."
>>
>>
>
>> I'm not sure what this means. Multiple identifiers per deivce should
>> address the privacy issue, Maybe a proxy would have the same effect?
>>
>> Again please provide some text.
>
>
As I said, I don't know what this proxy mode of operation is in an idloc
system.


> "5G specific identifiers can also used to deal with privacy issues.
>> IMSI is known to be 64 bit and unique for each UE.  IMSI should not be
>> exposed to any entities.  It is like 64-identifier.  Instead
>> identifiers like 5G-GUTI can be used"
>>
>> I think this is two levels. An identifier in IP identifies a node for
>> the purpose of being the endpoint of the communication. Something like
>> IMSI identifies a specific device (and hence user). In the best case
>> scenario, IP identifiers don't reveal the identity of users and they
>> can be made externally visible.
>
>
> How?
>

The mapping of an identifier to a user of device is only known by the local
network. Outside of the local trusted network a third party should not be
able to infer identity of geo-location of a user solely based on IP
addresses. For that, something like IMSI can't be used to make addresses
without some sort of mapping or obfuscation.


>
>
>> IMSI is by its nature sensitive
>> information and only visible in a trusted domain. A mapping system
>> will need to map identifiers to identities (like an IMSI) so the
>> system needs to be secured.
>>
>>
> When do you need to access the mapping system is the issue I think.
> We did not want to get into this a lot in the draft it is more control
> plane.
>
>
IMO, it's going to be hard not to include the control plane in discussions.
That's where most of the major issues of idloc are, particularly in scaling
and securing the mapping database.


> A big item missing in this section is locator security. Fine grained
>> locators used in cellular system could be used to infer the
>> geo-location of devices and hence users, thus enabling stalkers
>> everywhere.  So locators need restricted visibility somehow..
>>
>>
> Good point. But how? Again, some text please.
>
>
Here is my postulated stalker exploit that illustrates the dangers of
exposed locators to the users:


   -

   Suppose that a user device participates in an identifier/locator
   protocol such that they cache locators and use locators to directly send to
   peer devices.
   -

   A hacker might tap all packets sent or received on the network
   interfaces which makes locators visible to them.
   -

   In order to be able to tap packets a user needs root access to the
   device. There are instructions on the web to root an Android device.
   Similarly, jailbreaking can be done to circumvent restrictions on an
   iPhone to gain the equivalent of root access.
   -

   Once root access has been obtained, packets can be tapped using tcpdump
   or similar packet sniffer application.
   -

   With the tap running and packet addresses being captured, the hacker
   just needs to drive around send traffic between two devices in their car.
   They can observe the locators that are assigned to the their device, and
   from this can create a geo map of locators.
   -

   Given that one hacker can do this, then thousands will do it and web
   sites will spring up that provide locator geo maps.
   -

   Efforts to obfuscate or rotate identifiers does not help much here.
   Obfuscation complicates routing in the network such that more
   transformations need to happen there. Locator rotation is defeated if there
   are enough devices to keep the maps up to date in a mashup.
   -

   The net effect is that this enables a stalker attack. 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.


Tom