Re: [RFC PATCH] ipv6: Use dev_addr in stable-privacy address generation

["Bram Bonné" <brambonne@google.com>]

Hi Hannes,

Thank you for your detailed explanation and helping me understand the
context! This is really useful.

On Fri, Mar 27, 2020 at 2:06 PM Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> The main idea behind stable IPv6 identifiers is to eventually replace EUI-48 based generated addresses, because knowledge of the MAC address should never leave the broadcast domain you are in. This leads to tracking of a user moving between different networks (in this case moving between different ipv6 prefixes). It does not necessarily replace the temporary address mode which fully randomizes addresses and is still available to you for use in cases where you don't want to have this compromise. temp_addresses are still a good choice to use.
>
> MAC address randomization was mainly introduced to blind the unique identifier during wifi probing and association, where no IPv6 traffic is yet visible on unencrypted links. As soon as the encrypted link between your wifi endpoint and the access point is established, IPv6 addresses are generated and used inside the "encrypted wifi tunnel". This is an orthogonal measure to reduce the exposure of unique identifiers in the closer geographical proximity.

While the purpose of disassociated MAC address randomization is indeed
to prevent tracking a device during probing and association, my
understanding is that connected MAC address randomization (as used in
Android, for example) is designed to prevent devices being tracked
across different networks that are managed by the same network
operator. In this mode, a different MAC address is used for every
network (based on SSID in the case of wireless networks) the user
associates with. A user using connected MAC address randomization to
associate with two different networks has the privacy expectation that
those networks are not able to link those associations to the same
device without some other form of identification.

> You might want to combine those two features: Not being able to be disclosed in your proximity while having a stable address on your network. If that is not your goal, you can still enable temporary addresses, which will fully randomize your IPv6 addresses and are thus is completely independent of your MAC address. This would meet your concerns above.

I was under the impression that use_tempaddr does not apply to
link-local addresses. Is this not the case? A quick experiment on my
machine shows:

# sysctl -w net.ipv6.conf.enp0s31f6.use_tempaddr=2
# ip link set dev enp0s31f6 down && ip link set dev enp0s31f6 up
# ip address show dev enp0s31f6
2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UP group default qlen 1000
inet6 {same as before} scope link noprefixroute
valid_lft forever preferred_lft forever

> My additional concern with this patch is that users might already expect a certain way of the generation of stable IPv6 identifiers: even though wpa_supplicant randomizes the mac address, they might already depend on the stable generation of those addresses. If this changes, contact to those systems might get lost during upgrade. Though I don't know how severe this scenario is, I do, in fact, have some IPv6 stable identifiers in my shell history which are wifi endpoints.

If this is a scenario we care about, do you think it would make sense
to put this behavior behind a separate configuration parameter?
Something like use_software_mac, defaulting to disabled to keep
current behavior?

> If the IPv6 link local address can get discovered on the unencrypted wifi medium, I would be concerned but I don't think that is the case. In case of fully unencrypted wifis you can make the above case. It is possible to determine if a network endpoint (with the same secret and permanent mac address) shows up again. In this case I would recommend temporary addresses.

I'm not sure I understand this paragraph. In unencrypted wireless
networks, the link-local IPv6 address would be visible to
eavesdroppers when it's being used, again negating the benefits of MAC
address randomization. Please let me know if I misunderstood.

Thanks again for taking the time to respond to my questions.

Kind regards,
Bram