Subject: [Ideas] Addressing the privacy issues exposed by IDEAS

From: Robert Moskowitz <[email-masked]>
Date: Wed, 18 Oct 2017 09:04:31 -0400

I chose the subject line carefully as you will see by my analysis of the 
privacy issue(s).  I have discussed this with Padma before bringing this 
up to the list.

Here is the privacy attack, as I see it:

It is fairly well established that web sites collect a lot of personal 
information and information about the device(s) connected to that 
personal information.  IP addresses, even the actual address of NATed 
clients are part of the harvest.  Mal and his cousins are busy stealing 
this information and putting it all together in their own big data pile.

Meanwhile, Eve and her cousins are busy watching the network and seeing 
which IP addresses are communicating with other IP addresses.  Eve and 
cohorts put their data together with Mal and cohorts' data and then is 
able to note that:  "Hey look, Alice is talking directly with Barb."  
Oh, look, they both moved to new addresses, but we can see it is still 
Alice and Barb.

What is going on here?

ID/Loc technologies, enhanced with IDEAS technology, will make 
Peer-to-Peer communications without any triangular routing achievable.  
As long as these P2P communications use the same IP addresses as used in 
web Client/Server communications, the linkage is there to the privacy 
leakage occuring through those websites.

Three things have to happen to protect the privacy of P2P communications 
from the swamp of privacy leakage in C/S communications.

Identities need to be masked/hidden by both the ID/Loc technologies and 
IDEAS.

Identifiers of all ilk, both in the control channel and the data channel 
need to change with each move using some Perfect Forward Secrecy (PFS) 
technology.

Multiple IP addresses MUST be used, at least separating the P2P from C/S 
communications.  Different addresses for different P2P connections is wise.

Note that if IDEAS-ID/Loc does everything to hide and confuse 
Identity/Identifier, it is all for naught if multiple IP addresses are 
not used.  At this point I should mention that TLS 1.3 may have a 
similar privacy risk, but that is for a different soapbox.

Action plan:

The IDEAS charter should say something like:

"IDEAS will act as an enabling technology for the various ID/Loc 
technologies currently specified within the IETF.  As such it will 
result in a wider deployment of, mobile, Peer to Peer communications.  
Care will be taken in the design of the IDEAS technology not to enable 
the privacy leakage attacks in current Client/Server (predominately 
web-based) to be linked to these P2P communications."

This means that whatever technology we come up for IDEAS will mask/hide 
PII/Identity/Identifier.  So that Eve is in the dark and we need only 
defend the IDEAS data store from Mal.

Each ID/Loc technolgy (and this means ME with HIP) will need revisions 
to both their control and data plane (this means ESP for HIP) to change 
how Indentity and Identifiers are handled to break privacy tracking by 
Eve.  This may require using IDEAS as an enabler of privacy functions (I 
suspect I will need it in HIP to deal with the HI in the R1 packet).  
TLS 1.3 may also need revisions with its zero RT method.

The final, and potentially big one that is outside the IETF's control is 
that OSs and ISPs MUST enable support for multiple addresses per host 
and let technologies within the hosts (like ID/Loc) to get addresses to 
provide privacy separation.  This ALSO extends to MAC addresses!  Eve 
could be tapping into those IPFIX flows (now there is a BIG privacy 
leakage attack that no one is talking about) and getting all the MAC/IP 
address mappings!

One caveat that makes the multiple address not so big of a challenge is 
that ISPs are already providing some level of multiple address support 
by allowing hotspot usage on the mobile devices.  The IP address seen on 
the network MAY be from a given device or a device using it as a 
gateway.  This will become increasingly more common with automotive 
hotspots.  But this is NOT something we should count on as a mitigation 
of this privacy attack.

==========

Conclusion

IDEAS will analyse all security and privacy risks and include mitigation 
approaches in its design.

I will take this attack to the HIP group for revisions there.  I already 
have some work going (fast moblity draft for one) that I can leverage to 
this purpose.

I will reach out to the experts of other ID/Loc technologies (including 
MobileIKE) to discuss what they can do to ensure privacy as a design goal.

Finally, as some of you know, my suit has a kevlar armor layer.  So have 
at it!   :)

Bob

---

From: <[email-masked]>
Date: Wed, 18 Oct 2017 14:15:49 +0000

Bob

A very interesting discussion and one we need to clear before we can move on IMvHO!

Your comment:

	" ID/Loc technologies, enhanced with IDEAS technology, will make Peer-to-Peer communications without any triangular routing achievable."    

Yes but we need to keep in mind the operation of LI and should be supportive of that.   It can be achieved without triangular routing, but we should not consider it as an after-thought.   It is a regulatory and business requirement for the operators and they will (and have) reject any technology which does not meet these needs.   That is why we are still seeing anchored GTP tunnels in Rel.15.

	Meanwhile, Eve and her cousins are busy watching the network and seeing which IP addresses are communicating with other IP addresses.  Eve and cohorts put their data together with Mal and cohorts' data and then is able to note that:  "Hey look, 	Alice is talking directly with Barb."  

Whilst I love your sarcasm, there is another, less nefarious reason for the interception and that it is to do with allocation of resources and delivery against SLAs in mobile networks.    As mobile becomes the pre-dominant mode of connection to the Internet (driven by the trend to virtually zero cost we are witnessing in most geographies now for mobile packages), given that we have a very limited transport resource (RF spectrum), controlled access to and differentiated services over the Air Interface will be key to new services.  The ONLY reasons VoLTE works is because we have hard allocation of everything from radio bearer to packet-core and back. 

If we imagine a world where services other than default-bearer mobile broadband and dedicated bearer VoLTE exist (and this is the basic premise for 5G), then having knowledge of location, service and end-point is vital so that a) resources can be allocated and b) you (and I) can be billed for it appropriately.

In terms of privacy, one aspect is missing from you critique - location.   A mobile operator will know simply from association of IMSI to IP address to GTP TEID exactly which cell(s) you are on.

David

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Robert Moskowitz
Sent: 18 October 2017 06:05
To: [email-masked]
Subject: [Ideas] Addressing the privacy issues exposed by IDEAS

I chose the subject line carefully as you will see by my analysis of the privacy issue(s).  I have discussed this with Padma before bringing this up to the list.

It is fairly well established that web sites collect a lot of personal information and information about the device(s) connected to that personal information.  IP addresses, even the actual address of NATed clients are part of the harvest.  Mal and his cousins are busy stealing this information and putting it all together in their own big data pile.

Meanwhile, Eve and her cousins are busy watching the network and seeing which IP addresses are communicating with other IP addresses.  Eve and cohorts put their data together with Mal and cohorts' data and then is able to note that:  "Hey look, Alice is talking directly with Barb."  
Oh, look, they both moved to new addresses, but we can see it is still Alice and Barb.

What is going on here?

ID/Loc technologies, enhanced with IDEAS technology, will make Peer-to-Peer communications without any triangular routing achievable.  
As long as these P2P communications use the same IP addresses as used in web Client/Server communications, the linkage is there to the privacy leakage occuring through those websites.

Three things have to happen to protect the privacy of P2P communications from the swamp of privacy leakage in C/S communications.

Identities need to be masked/hidden by both the ID/Loc technologies and IDEAS.

Identifiers of all ilk, both in the control channel and the data channel need to change with each move using some Perfect Forward Secrecy (PFS) technology.

Multiple IP addresses MUST be used, at least separating the P2P from C/S communications.  Different addresses for different P2P connections is wise.

Note that if IDEAS-ID/Loc does everything to hide and confuse Identity/Identifier, it is all for naught if multiple IP addresses are not used.  At this point I should mention that TLS 1.3 may have a similar privacy risk, but that is for a different soapbox.

Action plan:

"IDEAS will act as an enabling technology for the various ID/Loc technologies currently specified within the IETF.  As such it will result in a wider deployment of, mobile, Peer to Peer communications.  
Care will be taken in the design of the IDEAS technology not to enable the privacy leakage attacks in current Client/Server (predominately
web-based) to be linked to these P2P communications."

This means that whatever technology we come up for IDEAS will mask/hide PII/Identity/Identifier.  So that Eve is in the dark and we need only defend the IDEAS data store from Mal.

Each ID/Loc technolgy (and this means ME with HIP) will need revisions to both their control and data plane (this means ESP for HIP) to change how Indentity and Identifiers are handled to break privacy tracking by Eve.  This may require using IDEAS as an enabler of privacy functions (I suspect I will need it in HIP to deal with the HI in the R1 packet).  
TLS 1.3 may also need revisions with its zero RT method.

The final, and potentially big one that is outside the IETF's control is that OSs and ISPs MUST enable support for multiple addresses per host and let technologies within the hosts (like ID/Loc) to get addresses to provide privacy separation.  This ALSO extends to MAC addresses!  Eve could be tapping into those IPFIX flows (now there is a BIG privacy leakage attack that no one is talking about) and getting all the MAC/IP address mappings!

One caveat that makes the multiple address not so big of a challenge is that ISPs are already providing some level of multiple address support by allowing hotspot usage on the mobile devices.  The IP address seen on the network MAY be from a given device or a device using it as a gateway.  This will become increasingly more common with automotive hotspots.  But this is NOT something we should count on as a mitigation of this privacy attack.

==========

Conclusion

IDEAS will analyse all security and privacy risks and include mitigation approaches in its design.

I will take this attack to the HIP group for revisions there.  I already have some work going (fast moblity draft for one) that I can leverage to this purpose.

Bob

_______________________________________________
Ideas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ideas

---

From: AshwoodsmithPeter <[email-masked]>
Date: Wed, 18 Oct 2017 15:01:55 +0000

> Yes but we need to keep in mind the operation of LI and should be supportive of that.   It can be achieved without triangular routing, but we should not consider it as an after-thought.   It is a r…

LI - Lawful Intercept can be implemented with ID/Loc technologies via the mapping system. In fact traffic can be directed to any convenient DC for intercept rather than having to be on a known data path. Fixed tunnels actually give you less flexibility for intercept since you can only do it on paths that you know the traffic is traversing and for access technologies that use those tunnels.

An ID loc / mapping system approach means that all interception for lawful, policy, etc. reasons are handled the same way, for multiple different access technologies and work under mobility the same way regardless of access. I'd have thought the regulatory bodies would be all over a more flexible intercept technology ;(

Cheers,

Peter

....

David

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Robert Moskowitz
Sent: 18 October 2017 06:05
To: [email-masked]
Subject: [Ideas] Addressing the privacy issues exposed by IDEAS

What is going on here?

Action plan:

==========

Conclusion

Bob

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 18 Oct 2017 11:10:30 -0400

> LI - Lawful Intercept can be implemented with ID/Loc technologies via the mapping system. In fact traffic can be directed to any convenient DC for intercept rather than having to be on a known data…

I had another proposal for LI using IPFIX or similar to fork traffic 
from the routing note between Alice and Barb.  And as long as Alice or 
Barb stays on the cellular network, their location would be known and 
the forking would move to a new place.

And none of this addresses that perhaps the traffic is from a connected 
friend via the mobile device's hotspot functionality.

Bob

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 18 Oct 2017 11:12:35 -0400

On 10/18/2017 10:15 AM, [email-masked] wrote:
> Whilst I love your sarcasm,

You should see the original version I sent to Padma.  I toned it down.  :)

Would make for some great slides for the next IETF session!  If someone 
good at making such slides to a try at it...

Bob

>   there is another, less nefarious reason for the interception and that it is to do with allocation of resources and delivery against SLAs in mobile networks.    As mobile becomes the pre-dominant mode of connection to the Internet (driven by the trend to virtually zero cost we are witnessing in most geographies now for mobile packages), given that we have a very limited transport resource (RF spectrum), controlled access to and differentiated services over the Air Interface will be key to new services.  The ONLY reasons VoLTE works is because we have hard allocation of everything from radio bearer to packet-core and back.
>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 18 Oct 2017 09:18:36 -0700

On Wed, Oct 18, 2017 at 6:04 AM, Robert Moskowitz
<[email-masked]> wrote:
> privacy issue(s).  I have discussed this with Padma before bringing this up
> to the list.
>
> information and information about the device(s) connected to that personal
> information.  IP addresses, even the actual address of NATed clients are
> part of the harvest.  Mal and his cousins are busy stealing this information
> and putting it all together in their own big data pile.
>
> cohorts put their data together with Mal and cohorts' data and then is able
> to note that:  "Hey look, Alice is talking directly with Barb."  Oh, look,
> they both moved to new addresses, but we can see it is still Alice and Barb.
>
> What is going on here?
>
> ID/Loc technologies, enhanced with IDEAS technology, will make Peer-to-Peer
> communications without any triangular routing achievable.  As long as these
> P2P communications use the same IP addresses as used in web Client/Server
> communications, the linkage is there to the privacy leakage occuring through
> those websites.
>
Bob,

It's more than just using multiple addresses. Today carriers are
assigning multiple addresses giving /64s so that a UE is getting 2^64
addresses. The problem is that this is done by a prefix assignment for
each device which means the device is easily tracked by that. What we
want are multiple addresses with some specific properties for privacy.

Here the properties of addresses that I came up with:

     o They are composed of a global routing prefix and a suffix that
        is internal to an organization or provider. This is the same
property for IP
        addresses [RFC3513].

      o The registry and organization of an address can be determined by
        the network prefix. This is true for any global address.

      o The organizational bits in the address should have minimal
        hierarchy to prevent inferences. It might be reasonable to have
        an internal prefix that divides identifiers based on broad
        geographic regions, but detailed information such as location,
        department in an enterprise, or device type should not be
        encoded in a globally visible address.

      o Given two addresses and no other information, the
        desired properties of correlating them are:

         o It can be inferred if they belong the same organization and
           registry. This is true for any two global IP addresses.

         o It may be inferred that they belong to the same broad
           grouping, such as a geographic region, if the information is
           encoded in the organizational bits of the address.

         o No other correlation can be established. For example, it
           cannot be inferred that the IP addresses address the same
           node, the addressed nodes reside in the same subnet, rack, or
           department, or that the nodes for the two addresses have any
           geographic proximity to one another.

> Identity/Identifier, it is all for naught if multiple IP addresses are not
> used.  At this point I should mention that TLS 1.3 may have a similar
> privacy risk, but that is for a different soapbox.
>
> Action plan:
>
> technologies currently specified within the IETF.  As such it will result in
> a wider deployment of, mobile, Peer to Peer communications.  Care will be
> taken in the design of the IDEAS technology not to enable the privacy
> leakage attacks in current Client/Server (predominately web-based) to be
> linked to these P2P communications."
>
> PII/Identity/Identifier.  So that Eve is in the dark and we need only defend
> the IDEAS data store from Mal.
>
> Each ID/Loc technolgy (and this means ME with HIP) will need revisions to
> both their control and data plane (this means ESP for HIP) to change how
> Indentity and Identifiers are handled to break privacy tracking by Eve.
> This may require using IDEAS as an enabler of privacy functions (I suspect I
> will need it in HIP to deal with the HI in the R1 packet).  TLS 1.3 may also
> need revisions with its zero RT method.
>
> that OSs and ISPs MUST enable support for multiple addresses per host and

ISP support requires a protocol to do bulk address assignment. This is
supported with DHCP, although it would be nice to have a method to
compress addresses in a response to 64 bits (identifiers) assuming
they all have a common 64 bit prefix. Of course Android doesn't
support DHCPv6 so they're going to need to be convinced that /128
address assignments are a leap forward.

OSes support multiple addresses to be configured on an interface
(order of 1000s). But the use of addresses needs to change to support
privacy. The concept of different address per outgoing connection
needs to be implemented. The semantics of INADDR_ANY need to be
modified to restrict the addresses allowed for incoming connections
(this is already be worked on container virtualization). There's also
a few "philosophical" questions relating to expected uses of any
assigned address-- like how to deal with ICMP. For instance, should
all of the addresses assigned to a device respond to ping?

> let technologies within the hosts (like ID/Loc) to get addresses to provide
> privacy separation.  This ALSO extends to MAC addresses!  Eve could be
> tapping into those IPFIX flows (now there is a BIG privacy leakage attack
> that no one is talking about) and getting all the MAC/IP address mappings!
>
RFC4941 talks about the problem of embedding IEEE identifiers into
IPv6 addresses. That practice is no longer considered acceptable. In
some sense, identifier-locator takes this it's logical extreme where
the "identifier" used to create addresses changes at the time
granularity of every new connection.

> One caveat that makes the multiple address not so big of a challenge is that
> ISPs are already providing some level of multiple address support by
> allowing hotspot usage on the mobile devices.  The IP address seen on the
> network MAY be from a given device or a device using it as a gateway.  This
> will become increasingly more common with automotive hotspots.  But this is
> NOT something we should count on as a mitigation of this privacy attack.
>
I was thinking about this problem. The normal way to implement a hot
spot is to give a device a prefix and delegate addresses from that
prefix. But that means the prefix is encoded in addresses which breaks
the address privacy properties above. I think the alternative is to
just to assign a host spot a whole bunch of /128 addresses and let
them do what they please with them. They can delegate addresses to the
their tethered clients.  So devices in the identifier-locator network
may each be assigned 1000s of addresses, and device that are hot spots
for many clients may end up needing 100s of thousands or more. The net
result is that the mapping system is going to need to scale to very
large numbers, I am assuming the system will need to track more than
1T identifiers at scale. Not going to be easy :-)

Tom

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 18 Oct 2017 12:28:51 -0400

Tom,

Excellent analysis.  Thanks for this.

Bob