Re: Address privacy

[Gyan Mishra <[e-mail]>]

On Sun, Jan 26, 2020 at 7:05 PM Gyan Mishra <[e-mail]> wrote:

>
> On Sun, Jan 26, 2020 at 5:00 PM Brian E Carpenter <
> [e-mail]> wrote:
>
>> On 27-Jan-20 10:39, Manfredi (US), Albert E wrote:
>> ....
>> > This seems like a good default, no? The business about "privacy"
>> concerns not so much the type of privacy that data encryption would
>> provide, but rather, being able to track an individual in his/her travels.
>> Changing the IID only when the prefix changes should prevent that well
>> enough?
>>
>> The IID is normally set *before* the host generates its Link Local
>> address, which is normally before it starts to listen for RAs from which it
>> will learn the current prefix(es).
>>
>> So you'd have to make the IID for SLAAC independent of the IID for LL
>> (which is of course exactly what RFC4941 does).
>
>
>   Gyan>  Agreed.  So the happy medium achieved for two camps on opposite
> ends of the spectrum.
>
> 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.
>
> Gyan> Is anyone aware of this vulnerability with RFC 4941 privacy
> algorithm stated below in this RIPE blog.   From this blog it appears that
> OS vendors are using a random number instead thus providing a sufficient
> level of protection.
>

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

RFC 4941 <https://tools.ietf.org/html/rfc4941> specifies however a
vulnerable algorithm for the Privacy Extension's interface identifier
generation. Adversaries are able to gain the algorithm's internal state via
a side channel, and predict all future addresses of a host afterwards
contradicting the intended privacy protection. The algorithm has not been
officially revised yet; nevertheless operating systems implementing the
IPv6 Privacy Extension appear to use random numbers instead and thus
provide a sufficient level of protection. Initially, the temporary
addresses of the Privacy Extension have been intended to be assigned in
addition to some sort of static addresses; nowadays, they are also assigned
in absence of static addresses. The latter fact significantly improves
protection against active scanning: the adversary now has to find the
(random or pseudo-random) temporary address instead of the static one which
is a more tedious task.

>
Kind Regards

>
>
>>
>>    Brian
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> --
>
> Gyan  Mishra
>
> Network Engineering & Technology
>
> Verizon
>
> Silver Spring, MD 20904
>
> Phone: [phone]
>
> Email: [e-mail]
>
>
>
> --

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]