Re: Address privacy

[Fernando Gont <[e-mail]>]

On 28/1/20 13:53, Gyan Mishra wrote:
[....]
>     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.
> 
>     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.



>     {...]
>      >
>      > 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.
> 
>    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)


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




> 
> 
>      > 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>.
> 
> 
> 
>     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,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492