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

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

[Bram Bonné]

This patch extends the IN6_ADDR_GEN_MODE_STABLE_PRIVACY address
generation mode to use the software-defined MAC address (dev_addr)
rather than the permanent, hardware-defined MAC address (perm_addr) of
the interface when generating IPv6 link-local addresses.

This ensures that the IPv6 link-local address changes in line with the
MAC address when per-network MAC address randomization is used,
providing the expected privacy guarantees.

When no MAC address randomization is used, dev_addr corresponds to
perm_addr, and IN6_ADDR_GEN_MODE_STABLE_PRIVACY behaves as before.

When MAC address randomization is used, this makes the MAC address
fulfill the role of both the Net_Iface and the (optional) Network_ID
parameters in RFC7217.

Cc: Lorenzo Colitti <lorenzo@google.com>
Cc: Jeffrey Vanderstoep <jeffv@google.com>
Signed-off-by: Bram Bonné <brambonne@google.com>
---
 net/ipv6/addrconf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 5b9de773ce73..cd69a4331246 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3252,7 +3252,7 @@ static int ipv6_generate_stable_address(struct in6_addr *address,
 	sha_init(digest);
 	memset(&data, 0, sizeof(data));
 	memset(workspace, 0, sizeof(workspace));
-	memcpy(data.hwaddr, idev->dev->perm_addr, idev->dev->addr_len);
+	memcpy(data.hwaddr, idev->dev->dev_addr, idev->dev->addr_len);
 	data.prefix[0] = address->s6_addr32[0];
 	data.prefix[1] = address->s6_addr32[1];
 	data.secret = secret;
-- 
2.25.1.696.g5e7596f4ac-goog

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

[David Miller]

From: "Bram Bonné" <brambonne@google.com>
Date: Thu, 26 Mar 2020 10:42:52 +0100

> This patch extends the IN6_ADDR_GEN_MODE_STABLE_PRIVACY address
> generation mode to use the software-defined MAC address (dev_addr)
> rather than the permanent, hardware-defined MAC address (perm_addr) of
> the interface when generating IPv6 link-local addresses.
> 
> This ensures that the IPv6 link-local address changes in line with the
> MAC address when per-network MAC address randomization is used,
> providing the expected privacy guarantees.
> 
> When no MAC address randomization is used, dev_addr corresponds to
> perm_addr, and IN6_ADDR_GEN_MODE_STABLE_PRIVACY behaves as before.
> 
> When MAC address randomization is used, this makes the MAC address
> fulfill the role of both the Net_Iface and the (optional) Network_ID
> parameters in RFC7217.
> 
> Cc: Lorenzo Colitti <lorenzo@google.com>
> Cc: Jeffrey Vanderstoep <jeffv@google.com>
> Signed-off-by: Bram Bonné <brambonne@google.com>

I think the current behavior is intentional in that it's supposed to use
something that is unchanging even across arbitrary administrator changes
to the in-use MAC address.

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

[Bram Bonné]

On Thu, Mar 26, 2020 at 7:45 PM David Miller <davem@davemloft.net> wrote:
> I think the current behavior is intentional in that it's supposed to use
> something that is unchanging even across arbitrary administrator changes
> to the in-use MAC address.

Thank you for your feedback David.

Could you help me understand the use cases where the admin / user
chooses to use MAC address randomization, but still wants an IPv6
link-local address that remains stable across these networks? My
assumption was that the latter would defeat the purpose of the former,
though it's entirely possible that I'm missing something.

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

[Hannes Frederic Sowa]

Hello,

On Fri, Mar 27, 2020, at 12:50, Bram Bonné wrote:
> On Thu, Mar 26, 2020 at 7:45 PM David Miller <davem@davemloft.net> wrote:
> > I think the current behavior is intentional in that it's supposed to use
> > something that is unchanging even across arbitrary administrator changes
> > to the in-use MAC address.
> 
> Thank you for your feedback David.
> 
> Could you help me understand the use cases where the admin / user
> chooses to use MAC address randomization, but still wants an IPv6
> link-local address that remains stable across these networks? My
> assumption was that the latter would defeat the purpose of the former,
> though it's entirely possible that I'm missing something.

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.

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.

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

Bye,
Hannes

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

[Bram Bonné]

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

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

[Hannes Frederic Sowa]

Hello,

On Fri, Mar 27, 2020, at 18:15, Bram Bonné wrote:
> Thank you for your detailed explanation and helping me understand the
> context! This is really useful.

Sure, let's try to solve this. :) Sorry for the bad formatting of the
previous email, I tried to fix it. Also I am a bit rusty on those
topics, so excuse me if I do mistakes in my argumentation here.

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

Okay, I understand. This is an additional scenario that wasn't on my
radar so far. Is the MAC address randomized on the (E)SSID or the BSSID?
I assume later as the ESSID might be stable across operators, but
anyways that's just nit picking.

In this scenario you would like to blind all unique identifiers on the
network of a device in a "stable way". The MAC address is already
blinded, thus it would be possible to just inherit it as the link local
address, nothing seems to be lost then? Same for the globally scoped
generated addresses stemming from this randomized MAC address?

Using EUI-48 address generation mode here would give you the benefit of
having no unique identifier (managed by the randomized mac address), a
stable link-local address and global addresses per ESSID and not having
to maintain the stable address generation secret. Seems to me to be the
easiest way forward. I wonder what the implications regarding duplicate
MAC address detection and thus IPv6 address selection are, but that's
another topic.

Additionally for the global scoped address generation I think it makes
sense to still enable use_tempaddr=2, as it makes sure that for longer
lasting associations to an AP new addresses are phased in and old ones
are phased out regularly.

Do IPv6 addresses generated with the EUI-48 mode from a randomized MAC
address have less random bits than if it would having been generated
with the stable or temporary method?

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

Right, temporary addresses are only globally scoped. You can enable the
random address generator for link local addresses via `ip link ...
addrgenmode random`. Those addresses are not phased in and out like
temporary addresses are. Also check if keep_addr_on_down is enabled, as
this might influence this behavior as well.

> > 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 you like to keep the semantics of having ipv6 stable addresses as per
spec, I would not object a patch adding a new mode like e.g.
IN6_ADDR_GEN_MODE_STABLE_PRIVACY_SOFTMAC (or some better name) on an
interface and consequently using the admin-mac address. For me the sole
benefit seems to be that the generated global addresses would
additionally depend on the prefix announced by the operator in that
particular network. This would only help if use_tempaddr=2 is not
enabled or applications deliberately bind to a non temp addresses
circumventing the source address selection.

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

I think there was a misunderstanding: I was referring to the case that
an IPv6 address might leak prior to joining an encrypted wifi (in the
"pre-auth phase").

Off topic: does Android also deal with sockets that are still bound to
old addresses, which potentially (I am not sure) generate packets that
are black holed because of wrong source address but still recognizable
by an network operator?

Bye, Hannes

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

[David Miller]

From: Bram Bonné <brambonne@google.com>
Date: Fri, 27 Mar 2020 12:50:07 +0100

> Could you help me understand the use cases where the admin / user
> chooses to use MAC address randomization, but still wants an IPv6
> link-local address that remains stable across these networks? My
> assumption was that the latter would defeat the purpose of the former,
> though it's entirely possible that I'm missing something.

Someone could renumber all of their MACs using a certain numbering
scheme, but that would not ensure the kind of uniqueness that the
physical MAC does.

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

[Bram Bonné]

Hey Hannes and David,

Thank you so much for working this through with me, and apologies for
the delayed response; I wanted to take some time to check my
assumptions with members from the Android team as well.

On Fri, Mar 27, 2020 at 9:52 PM Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> Okay, I understand. This is an additional scenario that wasn't on my
> radar so far. Is the MAC address randomized on the (E)SSID or the BSSID?
> I assume later as the ESSID might be stable across operators, but
> anyways that's just nit picking.

Connected MAC address randomization in Android is based on the ESSID
by default, to allow devices to roam across different access points
from the same operator using the MAC address as part of their
authentication. However, nothing prevents the user from changing their
MAC address over time, rather than per-SSID.

> In this scenario you would like to blind all unique identifiers on the
> network of a device in a "stable way". The MAC address is already
> blinded, thus it would be possible to just inherit it as the link local
> address, nothing seems to be lost then? Same for the globally scoped
> generated addresses stemming from this randomized MAC address?
>
> Using EUI-48 address generation mode here would give you the benefit of
> having no unique identifier (managed by the randomized mac address), a
> stable link-local address and global addresses per ESSID and not having
> to maintain the stable address generation secret. Seems to me to be the
> easiest way forward. I wonder what the implications regarding duplicate
> MAC address detection and thus IPv6 address selection are, but that's
> another topic.

I think this is an excellent proposal, and I agree with your
assessment that a randomized MAC address essentially acts as a
link-local address as far as privacy properties are concerned.
However, I think this proposal has a few drawbacks compared to using
regular IPv6 stable privacy addresses:

* Depending on whether the current network has MAC address
randomization enabled, the interface would have to be continuously
reconfigured to use either stable privacy address generation or
EUI-48.
* Repurposing EUI-48 here would require an additional step to ensure
that the generated address is unique (which is not an issue EUI-48
address generation has to deal with currently). David, is this what
you were hinting at in your message from 27 March as well?
* EUI-48-generated IPv6 addresses have fewer random bits than those
generated using the stable privacy method, as you mentioned.

> Additionally for the global scoped address generation I think it makes
> sense to still enable use_tempaddr=2, as it makes sure that for longer
> lasting associations to an AP new addresses are phased in and old ones
> are phased out regularly.

Agreed.

> If you like to keep the semantics of having ipv6 stable addresses as per
> spec, I would not object a patch adding a new mode like e.g.
> IN6_ADDR_GEN_MODE_STABLE_PRIVACY_SOFTMAC (or some better name) on an
> interface and consequently using the admin-mac address. For me the sole
> benefit seems to be that the generated global addresses would
> additionally depend on the prefix announced by the operator in that
> particular network. This would only help if use_tempaddr=2 is not
> enabled or applications deliberately bind to a non temp addresses
> circumventing the source address selection.

If you're still OK with this, and if my aforementioned comments seem
reasonable to you, I will create a patch next week implementing this
proposal as a separate mode (IN6_ADDR_GEN_MODE_STABLE_PRIVACY_SOFTMAC
sounds good to me), and we can take it from there. I like that this
lets us adhere to the RFC, where this mode would allow us to
implicitly use the MAC address as both the Net_Iface and the
Network_ID parameter. If you have any other suggestions, please let me
know. Happy to incorporate any feedback you have.

> Off topic: does Android also deal with sockets that are still bound to
> old addresses, which potentially (I am not sure) generate packets that
> are black holed because of wrong source address but still recognizable
> by an network operator?

I will let Lorenzo (also on this thread) respond here, as he'll
certainly know more about this than I do.

Thank you once again for thinking this through with me, and for the
thorough explanation. And as always, please let me know if I
misunderstood anything.

Kind regards,
Bram