[Ideas] Addressing the privacy issues exposed by IDEAS

[Robert Moskowitz <[e-mail]>]

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