internetstandards / Internet.nl

Internet standards compliance test suite
https://internet.nl
178 stars 37 forks source link

"Privacy Extensions for IPv6" does not trigger on EUI-64 addresses #1036

Open dnmvisser opened 1 year ago

dnmvisser commented 1 year ago

I am on a VPN connection where by the outgoing addresses are that of the VPN host. In my case that means I'm using an EUI-64 IPv6 address to browse the internet. But if I run a Connection test, I do get a green check at Privacy Extensions for IPv6 (link to results:)): Screenshot 2023-07-23 at 19 20 49

Other checker sites, such as https://ip6.nl, do warn about this:

Screenshot 2023-07-23 at 19 19 35

I believe the result on Internet.nl should also say that it leaks MAC address and hence should report some failure.

dnmvisser commented 1 year ago

Looking at the code, I can see that get_slaac_mac_vendor is probably resposible for this. That code checks if there is a match on the MAC OUI. In my case there is no such match, but the address is an EUI64 one, and while it doesn't leak a vendor, it is static and hence a privacy risk.

So, I think the check for a MAC OUI is too specific. It would be better to have an overarching check for an EUI64 address (with something like if(bytearray(s[11:13]).hex() == 'fffe')). If that is there, a first warning should be raised. Then the get_slaac_mac_vendor could be run, and that can optionally raise another warning about a MAC OUI detected and it means vendor XYZ, etc etc. But, just the fact that the address is an EUI64 address, should already be enough. There is little benefit in doing a lookup of the OUI....

baknu commented 1 year ago

Input by mail from GT (dd 15 August 2023):

I believe the actual OUI check is there to see if the produced EUI-64 is unique and thus globally identifiable. The existence of a publicly registered OUI makes sure of that.

Apart from that, an address with an unknown OUI is not guaranteed to be unique. Also an address with the 0xFF 0xFE bytes is not guaranteed to be a EUI-64 address.

What I am trying to say is that yes his address has the 0xFF 0xFE bytes and looks like a EUI-64 address, but it could be a random address (probably not in his case), or a non guaranteed unique address which for the privacy aspect it works in this case.

If we don't want to change the test, maybe the description could be expanded to include more information and reflect our reasoning. Otherwise an extra result for the test would be "it looks like it could be globally identifiable but not quite".

I am clearly in favor of the first option. Although I am not an expert on the EUI-64 stuff, unless I hear better arguments I am not convinced we should change the test.