Re: [v6ops] Same interface ID under several prefixes

[Alexandre Petrescu <[e-mail]>]

Le 09/11/2022 à 21:59, Brian E Carpenter a écrit :
> Looks like some progress in this area on Windows.
> 
> Yesterday I applied the latest Windows 10 update, and noticed that my 
> very old IPv6 status checker was giving me an unexpected result.
> 
> Why? Because as of yesterday, the stable IIDs for my GUA, ULA and LL 
> addresses are different. Kudos to MS.
> 
> This is Windows 10 Pro, version 21H2, OS Build 19044.2251
> 
> Can somebody check this on Windows 11?

I could check something on 22H2 Win10 (not Win 11), but not sure what to 
check more precisely, what commands to issue(?)

I am on an IPv4-only network and there is an IID in the link-local 
address, and that IID is different than the MAC address.

I have not recorded that IID in earlier days, so I cant check whether 
something changed after windows updates.

And, I am not  even sure of the MAC address being something of the 
actual Ethernet interface, because the USB-Ethernet interface is Dell, 
the Ethernet-less computer is HP and the MAC address on Windows says it 
is of HP (first 2 bytes checked from the public oui.txt).

And, there is something in the BIOS which tries to have a unique MAC 
address for the Ethernet interface despite connecting various external 
USB-Ethernet interfaces with their various MAC addresses.

This (MAC address from BIOS) stable identifier is very necessary, even 
though it does not appear in IPv6 addresses.

This stable id is used for some protection, even though it is known that 
it can be faked.

IPv6 is still considered to not give enough protection, compared to IPv4.

Alex

> 
> Regards
>     Brian
> 
> On 23-Jun-22 08:46, Fernando Gont wrote:
>> Hi, Brian,
>>
>> MacOS and OpenBSD also implement RFC7217/RFC8064.
>>
>> For embedded devices (e.g. printers), they are probably based on older
>> versions of the Linux kernel, and probably RFC7217 has not (and will
>> not) be back-ported to them -- so it'll take time for these devices to
>> adopt RFC7217.
>>
>> As for Android, there might be a similar issue going on -- but certainly
>> Lorenzo or Erik will be in a better position to tell.
>>
>> So my "concern" would probably be just the lack of support in Windows.
>>
>> P.S.: When it comes to Linux, it's more than just the kernel -- e.g.
>> there's an implementation in dhcpcd (that's what you probably see in
>> Raspberry Pi), and an implementation in NetworkManager (and there might
>> be one in systemd-networkd).
>>
>> Thanks,
>> Fernando
>>
>>
>>
>>
>> On 21/6/22 19:56, Brian E Carpenter wrote:
>>> Hi,
>>>
>>> I've done a little survey on my home network, and I don't find the 
>>> results
>>> very encouraging for RFC7217/RFC8064 deployment. In summary, there is
>>> some usage of pseudorandom IDs, but only Linux deserves a gold star
>>> (the PI is also Linux):
>>>
>>> Linux 5.4.0   - 3 different IIDs for GUA, ULA, LLA
>>> Raspberry PI  - 3 different IIDs for GUA, ULA, LLA
>>> Android 7     - same IID for GUA, ULA; different for LLA (EUI64)
>>> Android 11    - same IID for GUA, ULA; different for LLA (EUI64)
>>> Windows 10*   - same IID for GUA, ULA, LLA
>>> FritzBox 7530 - same IID for GUA, ULA, LLA (EUI64)
>>> Samsung TV s6 - same IID for GUA, LLA (EUI64, but also temporary IID for
>>> GUA & ULA)
>>> Chromecast 2  - LLA only (EUI64)
>>> Canon TS5100  - LLA only (EUI64)
>>>
>>> * with temporary addresses switched off
>>>
>>> Regards
>>>      Brian Carpenter
>>>
>>> On 18-Jun-22 10:20, Fernando Gont wrote:
>>>> On 17/6/22 17:51, Brian E Carpenter wrote:
>>>> [...]
>>>>>>
>>>>>> I assume they don't claim to implement RFC7217. -- If they did, then
>>>>>> yes, it would be fair to call that a bug. :-)
>>>>>
>>>>> Right, it would be fairer to call it a potential privacy vulnerability
>>>>> (discover one address, get another one free of charge).
>>>>
>>>> Indeed, their mechanism allows for host-tracking: i.e., once you know
>>>> the token, you can predict what's the address that that node would
>>>> configured if it connected to a given network.
>>>>
>>>>
>>>>> I don't regard
>>>>> it as a very serious problem that an outsider can learn my ULA or
>>>>> LLA.
>>>>
>>>> The biggest problem is that once the attacker learns your token, e.g.,
>>>> he can test whether you're connected to e.g. the IETF conference 
>>>> network
>>>> by e.g. pinging PREFIX::your_token.
>>>>
>>>>
>>>>
>>>>> Kudos to MS, anyway, for having moved to pseudo-random IIDs very 
>>>>> early,
>>>>> before RFC7217 in fact.
>>>>
>>>> Yes, that was the point I was trying to make!
>>>>
>>>> Thanks,
>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops