Re: [Ila] [DMM] Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Tom Herbert <[e-mail]>]

On Mon, Feb 5, 2018 at 9:22 PM, Lorenzo Colitti <[e-mail]> wrote:

> On Tue, Feb 6, 2018 at 2:17 PM, Tom Herbert <[e-mail]> wrote:
>
>> Section 8.3 provides the argument that singleton addresses are needed for
>> privacy-sensitive communications. For practicality and probably scaling /64
>> is needed, however for strong privacy singleton addresses would be needed
>> (to avoid resorting to NAT).
>>
>
> You don't need singletons for privacy. You can just assign /64s that
> change over time.
>

Yes, that seems to be the recommendation of RFC4914. However, neither that
RFC nor anyone else that I can tell has been able to quantitatively
describe the relationship between frequency of changing prefix and privacy.
Any statements about this are qualitative in nature. By intuition, it might
be believable that higher frequency should mean better privacy, but nobody
can quantify that. So for a user where privacy is paramount, my example is
a political dissident that is anonymously criticizing their government,
there is no definitive answer to give then when they ask what frequency
they need to ensure their privacy. Besides that, I believe that any
frequency could be defeated with the postulated exploit below (if you see a
flaw in this logic please let me know).

Actually, there is one frequency where the privacy effects can be
qualified: that is to use a different address per connection. This is
effectively what stateful NAT provides and why law enforcement doesn't like
it. With a large enough pool of users behind a NAT, flows sourced form the
same device cannot be correlated by a third party in external network. This
is strong privacy privacy in addressing (properties listed in 8.3). In lieu
of telling the political dissident to find a provider using NAT, assigning
addresses for singe use can provide it. Assigning a /64 to every flow won't
scale, but singleton addresses could.

----

The following exploit is proposed to defeat the privacy goal of periodic
address rotation:


   -

   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.

Tom