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

[Lorenzo Colitti <[e-mail]>]

On Tue, Feb 6, 2018 at 3:02 PM, Tom Herbert <[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).
>

In general, any scheme that relies in changing singletons can be
implemented by changing /64 prefixes in the same way.

Your example of a dissident that is criticizing the government is not a
relevant one in the likely case that the government has the power to compel
the network operator to log all the singletons that the network assigns.


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

Saying that assigning unaggregatable singleton addresses to each flow would
scale is an extremely bold statement. Back-of-the-envelope says that with
100M devices and an average of 10 flows per device that last 5 minutes on
average you've got 1B entries and 3.3 milion flow updates per second. That
amount of state must be available within a reasonable time (line rate, or,
say, 1 RTT) to any border router that could conceivably receive a packet
for any one of those flows. I don't know what sort of hardware you'd be
able to run that on, nor who would want to make such a colossal
infrastructure investment even if it could be done.