Re: Address privacy

[Fernando Gont <[e-mail]>]

On 28/1/20 04:31, Gyan Mishra wrote:
> 
> 
> Sent from my iPhone
> 
>> On Jan 27, 2020, at 8:36 PM, Fernando Gont <[e-mail]> wrote:
>>
>> On 26/1/20 21:05, Gyan Mishra wrote:
>>> On Sun, Jan 26, 2020 at 5:00 PM Brian E Carpenter 
>>> <[e-mail] <mailto:[e-mail]>> wrote:
>> [....]
>>> 1.  End user privacy on mobile device connected at home or
>>> 2.  End user privacy within an enterprise- non existent as IT 
>>> security and availability for mission critical applications -IPv6 
>>> stability and tracking ability is the primary objective.
>>> Happy medium achieved:
>>> For both scenarios following RFC 4941 disabling the temporary address 
>>> and keeping the modified EUI-64 random IID - provides both privacy 
>>> with MD5 randomized IID - and with the IID only changing with 
>>> mobility when you receive an new RA for SLAAC with mobility from a 
>>> different subnet which is what we want from and IT stability 
>>> perspective.  If you reboot with permanent storage as most devices 
>>> have the IID does not change as long as the prefix is the same.
>>
>> Not sure what you mean. THe algorithm that windows was using for 
>> stable addresses was rfc4941 without regeneration. SO essentially they 
>> generate a random number, and use it instead of the mac address.
>>
>> The resulting IIDs have all the same privacy issues as traditional 
>> slaac addresses, except that they cannot be address-scanned because 
>> they don't follow any patterns.
>>
> Gyan> See Microsoft link below stating that windows follows RFC 4941 and 
> supports random IID for incoming connections and regeneration of 
> temporary addresses for outgoing connections.
> 
> http://download.microsoft.com/download/F/D/F/FDF4CF55-5FDE-4CFF-8539-3662BB5EB7A0/TD13Basel2-43.pptx
> 
> Beginning with Windows Vista and Windows Server 2008, a randomized 
> method is utilized to determine the Interface ID instead of EUI-64

That's better that EUI-64, but still bad. Windows employs constant IIDs, 
that allow host tracking across networks.



{...]
> 
> Are you aware of this vulnerability with RFC 4941 privacy algorithm and 
> why OS vendors started using random numbers versus the privacy 
> algorithm, which maybe why Microsoft started doing the same - using 
> random number.

You are mixing things up.

Microsoft started using randomized IIDs because there was no alternative 
to MAC-based IIDs (such as RFC7217). So tey were proactive, and did 
something to mitigate address scanning attacks.

Temporary addresses are unrelated with stable addresses. They are about 
mitigating activity correlation over time.


> 
> https://labs.ripe.net/Members/johanna_ullrich/ipv6-addresses-security-and-privacy
> 

This is all fixed in rfc4941bis. In fact, Johanna reviewed rfc4941bis, IIRC.



> Here is another article that talks about RFC 4941 privacy algorithm 
> vulnerabilities.
> 
> https://publications.sba-research.org/publications/Ullrich2015Privacy.pdf
> 
> Do you think we should start this algorithm vulnerability in RFC 4941bis 
> draft?

I don't think that would be of much use for this I-D. We could add a 
note such as:
"This document addresses a number of flaws discovered in RFC4931 
[references], and formally obsoletes RFC4941."

At the end of the day, it's always better to give copius credit than to 
offer half baked explanations.

I've just realized that the ref to Johanna's paper was lost when we 
switched from  to rfc4941bis.

FWIW, the ref is:
    [RAID2015]
               Ullrich, J. and E. Weippl, "Privacy is Not an Option:
               Attacking the IPv6 Privacy Extension",  International
               Symposium on Recent Advances in Intrusion Detection
               (RAID), 2015, <https://www.sba-research.org/wp-
               content/uploads/publications/Ullrich2015Privacy.pdf>.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492