Subject: Re: Address privacy

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Jan 2020 13:12:17 -0300

On 28/1/20 04:31, Gyan Mishra wrote:
> 
> 
> Sent from my iPhone
> 
>> On Jan 27, 2020, at 8:36 PM, Fernando Gont <[email-masked]> wrote:
>>
>> On 26/1/20 21:05, Gyan Mishra wrote:
>>> On Sun, Jan 26, 2020 at 5:00 PM Brian E Carpenter 
>>> <[email-masked] <mailto:[email-masked]>> 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: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 28 Jan 2020 11:26:34 -0500

Will do.

Kind regards

Gyan

On Tue, Jan 28, 2020 at 3:40 AM <[email-masked]> wrote:

> Hi Gyan,
>
> Can you please propose text?
> Either as a pull request against https://github.com/ietf-6man/4941bis
> or as OLD: / NEW: in email.
>
> Best regards,
> Ole
>
> > On 28 Jan 2020, at 09:20, Gyan Mishra <[email-masked]> wrote:
> >
> >
> >
> > On Tue, Jan 28, 2020 at 2:41 AM Ole Troan <[email-masked]> wrote:
> > Gyan,
> >
> > > On 28 Jan 2020, at 08:31, Gyan Mishra <[email-masked]> wrote:
> > >
> > > Do you think we should start this algorithm vulnerability in RFC
> 4941bis draft?
> >
> > Could you expand a bit more on what you mean?
> > Rfc4941bis already uses different example algorithms for generation of
> random iids than 4941.
> >
> >
> >     I understand the draft discussed various methods of generating IID.
> From an operations perspective of existing deployments of RFC 4941 privacy
> algorithm stating the vulnerabilities that exist with the algorithm
> addition at the top of section 3.2.  Maybe even state to not use privacy
> algorithm.
> > That would be a good segway   into listing alternative algorithm
> examples that can be employed by OS vendors.
> >
> > In Section 8 - Significant changes - maybe we should explicitly mention
> also to not use the original privacy algorithm and to use the alternatives
> algorithms mentioned. I noticed one of the changes in section 8 mentioned-
> is to make the temporary address - enabled - by default.  That will have
> major operational impacts when an address changes occurs for  active
> sessions.   I think if we can figure out a way to improve the robustness of
> the temporary address so that it does not impact existing sessions.  I
> maybe wrong but I thought the way it worked is the temporary address during
> regeneration once the address becomes deprecated, existing sessions
> continue to use deprecated address  for outgoing connections and the newly
> regenerated preferred address is for new connections.  If that is true then
> their should not be any impact during regeneration.
> >
> > 6. Temporary addresses are *not* disabled by default.  ** I really think
> we should keep the temporary address disabled by default**
> >
> > This is an excerpt from RFC 4941 Deployment considerations section.
> >
> >  In addition, some applications may not behave
> >    robustly if temporary addresses are used and an address expires
> >    before the application has terminated, or if it opens multiple
> >    sessions, but expects them to all use the same addresses.
> >    Consequently, the use of temporary addresses SHOULD be disabled by
> >    default in order to minimize potential disruptions.  Individual
> >    applications, which have specific knowledge about the normal duration
> >    of connections, MAY override this as appropriate.
> >
> >
> >  I think RFC 4941 does have room for improvement from an operations
> perspective with the privacy extension many addresses in use per slaac
> address.  In updating the spec with this draft it would be good to come up
> with ways to provide privacy without sacrificing operations with many
> addresses and changing addresses in use simultaneously.
> >
> > Best regards,
> > Ole
> > --
> > Gyan  Mishra
> >
> > Network Engineering & Technology
> >
> > Verizon
> >
> > Silver Spring, MD 20904
> >
> > Phone: 301 502-1347
> >
> > Email: [email-masked]
> >
> >
> >
> >
>
> --

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Jan 2020 13:36:43 -0300

On 28/1/20 05:20, Gyan Mishra wrote:
[...]
> 
>      I understand the draft discussed various methods of generating 
> IID.  From an operations perspective of existing deployments of RFC 4941 
> privacy algorithm stating the vulnerabilities that exist with the 
> algorithm addition at the top of section 3.2.  Maybe even state to not 
> use privacy algorithm.

THat's implied by the fact we are obsoleting RFC4941.

> also to not use the original privacy algorithm and to use the 
> alternatives algorithms mentioned. I noticed one of the changes in 
> section 8 mentioned-  is to make the temporary address - enabled - by 
> default.  That will have major operational impacts when an address 
> changes occurs for  active sessions.

Temporary addresses are enabled by default in a number of popular 
operating systems. So, in a way, rfc4941bis is following deployed 
practice. Besides, disabling them by default in a post-Snowden era would 
be a hard case to make.

>   I think if we can figure out a 
> way to improve the robustness of the temporary address so that it does 
> not impact existing sessions.

THat can be addressed by what's currently in the "Future Work" section.

That said, the "Valid lifetime" is one week. For long-lived connections, 
I'd argue you should be opting out of temporary addresses.

>  I maybe wrong but I thought the way it 
> worked is the temporary address during regeneration once the address 
> becomes deprecated, existing sessions continue to use deprecated address 
>   for outgoing connections and the newly regenerated preferred address 
> is for new connections.  If that is true then their should not be any 
> impact during regeneration.

That's flagged in "future work", but not mandated.

>     sessions, but expects them to all use the same addresses.

The expectation for all sessions to use the same addresses would seem 
obsolete these days. Whether because the network employs multiple 
prefixes, and/or because with Happy Eyeballs it's hard to predict what 
you will end up using.

> address.  In updating the spec with this draft it would be good to come 
> up with ways to provide privacy without sacrificing operations with many 

Temporary addresses leads to about a dozen addresses per host. That's 
the least one could expect in the context of RFC7934. And in ant case, 
it's a deployed reality.

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 28 Jan 2020 11:53:43 -0500

On Tue, Jan 28, 2020 at 11:12 AM Fernando Gont <[email-masked]>
wrote:

> Gyan> Windows does employ the privacy extension for rolling temporary
> address which addresses anonymity by using the temporary address for
> outgoing connections and the stable random IID for incoming connections.
> In RFC 4941 the analogy is given that use of stable IID for incoming
> connections is analogous to publishing your phone number in the white pages
> and using the temporary address for outgoing connections is analogous to
> caller id block.
>
> {...]
> >

  Gyan>  Please read the link for RIPE below regarding the RFC 4941 privacy
algorithm vulnerability.  Both links state the vulnerability with the
existing algorithm.

>     Gyan> Understood.  As stated above from the links below Microsoft and
other OS vendors moved to using their own random number generator schema
due to the RFC 4941 algorithm vulnerability for both the interface IID and
temporary address privacy extension.

> Understood.  I am on the same page as you.  Just want to be clear that as
> you are aware that Microsoft implemented both the “stable” interface random
> IID

   for incoming connections and the privacy     extension temporary rolling
address for outgoing connections.

>                content/uploads/publications/Ullrich2015Privacy.pdf>.

   Gyan> So you will get the text language updates into the current version
of 4941bis that was dropped from Johanna’s paper.  I will stand down on
adding updates to GitHub asked by Ole as we are on the same page now, and
you will be updating.

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Fernando Gont <[email-masked]>
Date: Tue, 28 Jan 2020 14:27:57 -0300

On 28/1/20 13:53, Gyan Mishra wrote:
[....]
>     Gyan> Windows does employ the privacy extension for rolling
>     temporary address which addresses anonymity by using the temporary
>     address for outgoing connections and the stable random IID for
>     incoming connections.

Nodes typically have two "types" of addresses: temporary addresses and 
stable addresses.

Even if you implement RFC4941, stable addresses that embed the 
underlying MAC address pose a problem, because e.g. they result in 
patterns, and thus make hosts possible to address-scan.

Windows did two things:
1) They implemented temporary addresses (rfc4941), such that network 
activity correlation over time is mitigated.

2) They implemented an alternative algorithm to the traditional 
generation of IIDs based on the underlying MAC address (at the time they 
did it, RFC7217 didn't exist). The algorithm that they use to generate 
these stable IIDs is essentially the same as in RFV4941, except that, 
since the identifier is meant to be stable, they don¡t rotate *this* IID.

One ould expect that they will replace 2) with RFC7217 (as recommended 
by RFC8054). However, the flaws in RFC4941 (which you correctly 
referenced) need to be addressed with a replacement for RFC4941: that's 
the rfc4941bis draft we're discussing.

>    Gyan>  Please read the link for RIPE below regarding the RFC 4941 
> privacy algorithm vulnerability.  Both links state the vulnerability 
> with the existing algorithm.

Indeed. THat's part of the motivation for rfc4941bis, and why we chose 
to replace the algorithm that generates the interface identifier (IID)

>      Gyan> Understood.  As stated above from the links below Microsoft 
> and other OS vendors moved to using their own random number generator 
> schema due to the RFC 4941 algorithm vulnerability for both the 
> interface IID and temporary address privacy extension.

No, that's not correct. Microsoft implemented the randomized IID 
because, at the time, the only standard to generate IIDs was to embed 
the MAC addresses, and that has a number of issues, as noted above.

As noted, there are two separate problems:
* stable addresses
* temporary addresses

The issue with stable addresses has been addressed by RFC7217. We still 
need to address the flaws in RFC4941, and that's why we're working on 
rfc4941bis.

>     4941bis
>     Gyan> So you will get the text language updates into the current 
> version of 4941bis that was dropped from Johanna’s paper.  I will stand 
> down on adding updates to GitHub asked by Ole as we are on the same page 
> now, and you will be updating.

WHat I'm saying is that we coulf add something like:
      "This document addresses a number of flaws discovered in RFC4931
      [references], and formally obsoletes RFC4941."

thus making it explicit why we're changing the algorithm. The reader can 
always go and read the reference for further details.

WOuld this address your concern?

THanks!

Cheers,

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 29 Jan 2020 15:06:49 -0500

On Tue, Jan 28, 2020 at 12:28 PM Fernando Gont <[email-masked]>
wrote:

> Gyan> Agreed
> Gyan> Good!
>    Gyan> Understood

> WOuld this address your concern?

  Gyan> Yes that will do it.  It maybe good to describe the flaw
vulnerability details in the RFC 4941 algorithm.  Security is always a big
issue and if you explain the vulnerability that would also help vendors get
on board quickly with the new version.  So in the bis version you mention
multiple algorithms for Random IID generation.  Would you nail it down to
one maybe even the RFC 7217 method as the preferred alternative.  Also
doing so would give vendors the option to stay with new iteration of 4941
or support RFC 7217.

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347