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

From: Tom Herbert <[email-masked]>
Date: Wed, 31 Jan 2018 14:02:54 -0800

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

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 31 Jan 2018 14:25:01 -0800

Tom, this is why addresses need to be obfuscated. And you can’t do that with address translation/transformation. I’m a fan of ILA, but the IPv6 header must be sent in the clear, and that is problematic for this issue.

Dino

> On Jan 31, 2018, at 2:02 PM, Tom Herbert <[email-masked]> wrote:
> 
> 
> 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
> "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.)"
>  
> As I said, I don't know what this proxy mode of operation is in an idloc system.
>  
> 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. 
>  
>  
> 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.
>  
> 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
> 
> _______________________________________________
> 5gangip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/5gangip

---

From: Tom Herbert <[email-masked]>
Date: Wed, 31 Jan 2018 14:42:57 -0800

> Tom, this is why addresses need to be obfuscated. And you can’t do that with address translation/transformation. I’m a fan of ILA, but the IPv6 header must be sent in the clear, and that is problem…
Dino,

It's not the addresses that need to be obfuscated, it's the identity
of the user that sourced the packet that needs to remain hidden. As
shown my postulated attack, if a user repeatedly the uses same address
in unrelated flows, it would be easy for a third party to deduce their
identity in their flows. NAT is an example of a process that
obfuscates identity to provide good privacy.

Tom

> ila mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ila

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 31 Jan 2018 14:55:15 -0800

> It's not the addresses that need to be obfuscated, it's the identity

I think both. 

> of the user that sourced the packet that needs to remain hidden. As

And I think there will be non-human users using such addresses. They need to be protected too. If you have a “default network to send anywhere”, then anything can be attacked.

> obfuscates identity to provide good privacy.

It doesn’t help. If Tom is protected from sending packets from his house, I still can deduce its Tom’s house.

You have to change and obfuscate EIDs and you have to keep using different RLOCs. Cat and mouse game.

Dino

---

From: Tom Herbert <[email-masked]>
Date: Wed, 31 Jan 2018 15:18:37 -0800

> It doesn’t help. If Tom is protected from sending packets from his house, I still can deduce its Tom’s house.

That should only be true if you are my network provider. To anyone
else the only thing they should be able to deduce from an address is
that the packet originated from a random user of my network provider.

> You have to change and obfuscate EIDs and you have to keep using different RLOCs. Cat and mouse game.
For best privacy you would keep using different source addresses
(identifiers) for different flows, Locators are not an issue if their
visibility is restricted to the provider network, so that neither UEs
nor external nodes ever see them .

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 31 Jan 2018 15:25:02 -0800

> that the packet originated from a random user of my network provider.

I can tcpdump packets on my router for packets you send before the locator is translated back to the sir-prefix. And count on the locator being in DNS for a reverse lookup so I can get some ascii text that gives me a clue.

> nor external nodes ever see them .

Don’t you want your provider to not track you?

Dino

---

From: Ca By <[email-masked]>
Date: Wed, 31 Jan 2018 23:50:58 +0000

On Wed, Jan 31, 2018 at 2:25 PM Dino Farinacci <[email-masked]> wrote:

> Tom, this is why addresses need to be obfuscated. And you can’t do that
> with address translation/transformation. I’m a fan of ILA, but the IPv6
> header must be sent in the clear, and that is problematic for this issue.
>
> Dino

And again, i really have no idea on what problem Tom and Dino are trying
solve that they think a mobile operator would want to implement.

I see Tom and Dino jockeying their solutions, but they are not solutions to
problems that network operators have articulated.

I believe at one point this listed agreed to produce requirements but then
quickly decided it was better to have secret group (design team?) write a
white paper about  id / loc.

IMHO id / loc has zero traction in mobile , it is not present in any of the
well publicized “5G” deployments that are currently going on.

On this list, id/loc is a solution looking for a problem.

Just $0.02 about the echo chamber we are in.

>
> > On Jan 31, 2018, at 2:02 PM, Tom Herbert <[email-masked]> wrote:n
> >
> >
> >       • The attacker creates an “always connected” app that provides
> some seemingly benign service and users download the app.
> >       • 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 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
> > (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.
> > 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.)"
> >
> > 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
> > 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.
> >
> >       • Suppose that a user device participates in an identifier/locator
> >       • A hacker might tap all packets sent or received on the network
> >       • 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
> >       • 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
> >

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 31 Jan 2018 16:01:17 -0800

> And again, i really have no idea on what problem Tom and Dino are trying solve that they think a mobile operator would want to implement. 

I’m trying to solve for the general case. And if possible, then 5G could benefit regardless if anyone thinks it is needed or not.

> I see Tom and Dino jockeying their solutions, but they are not solutions to problems that network operators have articulated. 

We both are trying to make both solutions better.

> I believe at one point this listed agreed to produce requirements but then quickly decided it was better to have secret group (design team?) write a white paper about  id / loc.  

Note the [email-masked] mailing list is copied. 

> IMHO id / loc has zero traction in mobile , it is not present in any of the well publicized “5G” deployments that are currently going on. 

Then you can ignore us. But many of us want to think out loud freely and learn from each other.

> Just $0.02 about the echo chamber we are in. 

You will have to use your email filters then.

Dino

---

From: Ca By <[email-masked]>
Date: Thu, 01 Feb 2018 00:05:58 +0000

On Wed, Jan 31, 2018 at 4:01 PM Dino Farinacci <[email-masked]> wrote:

> I’m trying to solve for the general case. And if possible, then 5G could
> benefit regardless if anyone thinks it is needed or not.
>
> > I see Tom and Dino jockeying their solutions, but they are not solutions
> to problems that network operators have articulated.
>
> > I believe at one point this listed agreed to produce requirements but
> then quickly decided it was better to have secret group (design team?)
> write a white paper about  id / loc.
>
> > IMHO id / loc has zero traction in mobile , it is not present in any of
> the well publicized “5G” deployments that are currently going on.
>

Ack.  Just contributing to the archive that 2 protocol wonks doting on
their own creations is not a working group or 5G.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 31 Jan 2018 16:08:40 -0800

> I can tcpdump packets on my router for packets you send before the locator is translated back to the sir-prefix. And count on the locator being in DNS for a reverse lookup so I can get some ascii t…

Again, that is only true if your router is in the provider network  If
locators imply geo-location, which they likely would in a mobile
network, then exposing them to anyone outside of the trusted network
is asking for trouble.
> Don’t you want your provider to not track you?

It's inherent in the operations  that my provider tracks me in order
to be able to forward packets. But, I have a contractual agreement
with the provider to do that and protect privacy. For anyone outside
of my provider, I don't want them to be able to track me. This is why
I don't want locators to be visible outside of the network. That would
include UEs attached to the network (they are not trusted devices) and
putting locators in DNS.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Wed, 31 Jan 2018 16:16:12 -0800

On Wed, Jan 31, 2018 at 4:05 PM, Ca By <[email-masked]> wrote:
>> > then quickly decided it was better to have secret group (design team?) write
>> > a white paper about  id / loc.
>>
> Ack.  Just contributing to the archive that 2 protocol wonks doting on their
> own creations is not a working group or 5G.
>
Ca,

3GPP CT4 working group has initiated a study of user plane protocol in
5GC for Release-16. Our intent is for ILA to be a candidate for that
study.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 31 Jan 2018 17:32:58 -0800

What if you and I are running ILA and are attached to different providers. How do you get packets to me if my locators are not exposed outside my provider?

Dino

> On Jan 31, 2018, at 4:08 PM, Tom Herbert <[email-masked]> wrote:
>