Re: [6lo] Generation of IPv6 IIDs

[Fernando Gont <[e-mail]>]

Hi, Carsten,

On 05/01/2014 04:32 PM, Carsten Bormann wrote:
> On 01 May 2014, at 23:04, Robert Cragie <[e-mail]>
> wrote:
> 
>> However, for link local addresses, especially in a route-over mesh
>> where a link-local IP packet travels strictly one node hop, it does
>> not seem as critical. As mentioned below, in many cases 6LoWPAN
>> compression relies on a one-to-one correspondence between a link
>> local and IPv6 address to provide effective compression.
> 
> Indeed, and a more complete approach to fix the privacy leaks for the
> link-local cases will involve privacy enhancements to the layers
> below (as discussed by Piers O'Hanlon at IETF 89 and see also
> https://www.w3.org/2014/strint/papers/35.pdf).

While I don't necessarily disagree with doing any privacy-wise
improvements at the link-layer, that's mostly orthogonal to what we're
discussing here.

Several things to note:

* Firstly (and most importantly), traditional SLAAC IIDs mean that the
IID has the same properties as the underlying MAC address. That's where
the problem resides.  If you play with the underlying MAC address,
you're not solving that problem.

* If you do simple MAC-address-randomization + traditional SLAAC, that
would lead to IPv6 addresses that change over time, even when that's not
really desirable. In order to know where such change might be desirable,
you would need to do some sort flavor of RFC6059.. but most of the
"hints" there are not available at layer-2.

* The scale of the problem is different between MAC address privacy vs.
IPv6 address privacy: In order to exploit the former, you essentially
need a rogue device connected to the victim's network. In order to
exploit the later, you just need to be connected to the Internet.

* Finally, there could even be cases where the MAC address is not
changeable (for one reason or another).

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