rfc9724v1.txt | rfc9724.txt | |||
---|---|---|---|---|
Internet Engineering Task Force (IETF) JC. Zúñiga | Internet Engineering Task Force (IETF) JC. Zúñiga | |||
Request for Comments: 9724 Cisco | Request for Comments: 9724 Cisco | |||
Category: Informational CJ. Bernardos, Ed. | Category: Informational CJ. Bernardos, Ed. | |||
ISSN: 2070-1721 UC3M | ISSN: 2070-1721 UC3M | |||
A. Andersdotter | A. Andersdotter | |||
Safespring AB | Safespring AB | |||
January 2025 | January 2025 | |||
Randomized and Changing Media Access Control (MAC) Address State of | State of Affairs for Randomized and Changing Media Access Control (MAC) | |||
Affairs | Addresses | |||
Abstract | Abstract | |||
Internet users are becoming more aware that their activity over the | Internet users are becoming more aware that their activity over the | |||
Internet leaves a vast digital footprint, that communications might | Internet leaves a vast digital footprint, that communications might | |||
not always be properly secured, and that their location and actions | not always be properly secured, and that their location and actions | |||
can be tracked. One of the main factors that eases tracking of | can be tracked. One of the main factors that eases tracking of | |||
Internet users is the wide use of long-lasting, and sometimes | Internet users is the wide use of long-lasting, and sometimes | |||
persistent, identifiers at various protocol layers. This document | persistent, identifiers at various protocol layers. This document | |||
focuses on Media Access Control (MAC) addresses. | focuses on Media Access Control (MAC) addresses. | |||
There have been several initiatives within the IETF and the IEEE 802 | There have been several initiatives within the IETF and the IEEE 802 | |||
standards committees to overcome some of the privacy issues involved. | standards committees to address some of the privacy issues involved. | |||
This document provides an overview of these activities to help | This document provides an overview of these activities to help | |||
coordinate standardization activities in these bodies. | coordinate standardization activities in these bodies. | |||
Status of This Memo | Status of This Memo | |||
This document is not an Internet Standards Track specification; it is | This document is not an Internet Standards Track specification; it is | |||
published for informational purposes. | published for informational purposes. | |||
This document is a product of the Internet Engineering Task Force | This document is a product of the Internet Engineering Task Force | |||
(IETF). It represents the consensus of the IETF community. It has | (IETF). It represents the consensus of the IETF community. It has | |||
skipping to change at line 69 ¶ | skipping to change at line 69 ¶ | |||
Table of Contents | Table of Contents | |||
1. Introduction | 1. Introduction | |||
2. Background | 2. Background | |||
2.1. MAC Address Usage | 2.1. MAC Address Usage | |||
2.2. MAC Address Randomization | 2.2. MAC Address Randomization | |||
2.3. Privacy Workshop, Tutorial, and Experiments at IETF and | 2.3. Privacy Workshop, Tutorial, and Experiments at IETF and | |||
IEEE 802 Meetings | IEEE 802 Meetings | |||
3. Activities Relating to Randomized and Changing MAC Addresses in | 3. Activities Relating to Randomized and Changing MAC Addresses in | |||
the IEEE 802 | the IEEE 802 | |||
4. Recent Activities Related to MAC Randomization in the WBA | 4. Recent Activities Related to MAC Address Randomization in the | |||
WBA | ||||
5. IPv6 Address Randomization in the IETF | 5. IPv6 Address Randomization in the IETF | |||
6. Taxonomy of MAC Address Selection Policies | 6. Taxonomy of MAC Address Selection Policies | |||
6.1. Per-Vendor OUI MAC Address (PVOM) | 6.1. Per-Vendor OUI MAC (PVOM) Address | |||
6.2. Per-Device Generated MAC Address (PDGM) | 6.2. Per-Device Generated MAC (PDGM) Address | |||
6.3. Per-Boot Generated MAC Address (PBGM) | 6.3. Per-Boot Generated MAC (PBGM) Address | |||
6.4. Per-Network Generated MAC Address (PNGM) | 6.4. Per-Network Generated MAC (PNGM) Address | |||
6.5. Per-Period Generated MAC Address (PPGM) | 6.5. Per-Period Generated MAC (PPGM) Address | |||
6.6. Per-Session Generated MAC Address (PSGM) | 6.6. Per-Session Generated MAC (PSGM) Address | |||
7. OS Current Practices | 7. OS Current Practices | |||
8. IANA Considerations | 8. IANA Considerations | |||
9. Security Considerations | 9. Security Considerations | |||
10. Informative References | 10. Informative References | |||
Acknowledgments | Acknowledgments | |||
Authors' Addresses | Authors' Addresses | |||
1. Introduction | 1. Introduction | |||
Privacy is becoming a huge concern, as more and more devices are | Privacy is becoming a huge concern, as more and more devices are | |||
skipping to change at line 110 ¶ | skipping to change at line 111 ¶ | |||
trackers, etc. | trackers, etc. | |||
Privacy concerns affect all layers of the protocol stack, from the | Privacy concerns affect all layers of the protocol stack, from the | |||
lower layers involved in the access to the network (e.g., MAC/L2 and | lower layers involved in the access to the network (e.g., MAC/L2 and | |||
L3 addresses can be used to obtain the location of a user) to higher- | L3 addresses can be used to obtain the location of a user) to higher- | |||
layer protocol identifiers and user applications [CSCN2015]. In | layer protocol identifiers and user applications [CSCN2015]. In | |||
particular, IEEE 802 MAC addresses have historically been an easy | particular, IEEE 802 MAC addresses have historically been an easy | |||
target for tracking users [wifi_tracking]. | target for tracking users [wifi_tracking]. | |||
There have been several initiatives within the IETF and the IEEE 802 | There have been several initiatives within the IETF and the IEEE 802 | |||
standards committees to overcome some of these privacy issues. This | standards committees to address some of these privacy issues. This | |||
document provides an overview of these activities to help coordinate | document provides an overview of these activities to help coordinate | |||
standardization activities within these bodies. | standardization activities within these bodies. | |||
2. Background | 2. Background | |||
2.1. MAC Address Usage | 2.1. MAC Address Usage | |||
Most mobile devices used today are WLAN enabled (i.e., they are | Most mobile devices used today are WLAN enabled (i.e., they are | |||
equipped with an IEEE 802.11 wireless local area network interface). | equipped with an IEEE 802.11 wireless local area network interface). | |||
Like any other kind of network interface based on IEEE 802 such as | Like any other kind of network interface based on IEEE 802 such as | |||
skipping to change at line 181 ¶ | skipping to change at line 182 ¶ | |||
Since universally administered MAC addresses are by definition | Since universally administered MAC addresses are by definition | |||
globally unique, when a device uses this MAC address over a shared | globally unique, when a device uses this MAC address over a shared | |||
medium to transmit data -- especially over the air -- it is | medium to transmit data -- especially over the air -- it is | |||
relatively easy to track this device by simple medium observation. | relatively easy to track this device by simple medium observation. | |||
Since a device is usually directly associated to an individual, this | Since a device is usually directly associated to an individual, this | |||
poses a privacy concern [link_layer_privacy]. | poses a privacy concern [link_layer_privacy]. | |||
MAC addresses can be easily observed by a third party, such as a | MAC addresses can be easily observed by a third party, such as a | |||
passive device listening to communications in the same L2 network. | passive device listening to communications in the same L2 network. | |||
In an 802.11 network, a station exposes its MAC address in two | In an 802.11 network, a station (STA) exposes its MAC address in two | |||
different situations: | different situations: | |||
* While actively scanning for available networks, the MAC address is | * While actively scanning for available networks, the MAC address is | |||
used in the Probe Request frames sent by the device (also known as | used in the Probe Request frames sent by the device. | |||
IEEE 802.11 STA). | ||||
* Once associated to a given Access Point (AP), the MAC address is | * Once associated to a given Access Point (AP), the MAC address is | |||
used in frame transmission and reception, as one of the addresses | used in frame transmission and reception, as one of the addresses | |||
used in the unicast address fields of an IEEE 802.11 frame. | used in the unicast address fields of an IEEE 802.11 frame. | |||
One way to overcome this privacy concern is by using randomly | One way to address this privacy concern is by using randomly | |||
generated MAC addresses. IEEE 802 addressing includes one bit to | generated MAC addresses. IEEE 802 addressing includes one bit to | |||
specify if the hardware address is locally or globally administered. | specify if the hardware address is locally or globally administered. | |||
This allows local addresses to be generated without the need for any | This allows local addresses to be generated without the need for any | |||
global coordination mechanism to ensure that the generated address is | global coordination mechanism to ensure that the generated address is | |||
still unique within the local network. This feature can be used to | still unique within the local network. This feature can be used to | |||
generate random addresses, which decouple the globally unique | generate random addresses, which decouple the globally unique | |||
identifier from the device and therefore make it more difficult to | identifier from the device and therefore make it more difficult to | |||
track a user device from its MAC/L2 address | track a user device from its MAC/L2 address | |||
[enhancing_location_privacy]. | [enhancing_location_privacy]. | |||
skipping to change at line 239 ¶ | skipping to change at line 239 ¶ | |||
[ieee_privacy_ecsg]. The work and discussions from the group have | [ieee_privacy_ecsg]. The work and discussions from the group have | |||
generated multiple outcomes, such as: 802E PAR (Project Authorization | generated multiple outcomes, such as: 802E PAR (Project Authorization | |||
Request, this is the means by which standards projects are started | Request, this is the means by which standards projects are started | |||
within the IEEE. PARs define the scope, purpose, and contact points | within the IEEE. PARs define the scope, purpose, and contact points | |||
for a new project): Recommended Practice for Privacy Considerations | for a new project): Recommended Practice for Privacy Considerations | |||
for IEEE 802 Technologies [IEEE_802E], and the 802c PAR: Standard for | for IEEE 802 Technologies [IEEE_802E], and the 802c PAR: Standard for | |||
Local and Metropolitan Area Networks - Overview and Architecture - | Local and Metropolitan Area Networks - Overview and Architecture - | |||
Amendment 2: Local Medium Access Control (MAC) Address Usage | Amendment 2: Local Medium Access Control (MAC) Address Usage | |||
[IEEE_802c]. | [IEEE_802c]. | |||
In order to test the effects of MAC address randomization, trials | In order to test the effects of MAC address randomization, | |||
were conducted at the IETF and IEEE 802 meetings between November | experiments were conducted at the IETF and IEEE 802 meetings between | |||
2014 and March 2015 -- IETF 91, IETF 92, and the IEEE 802 Plenary in | November 2014 and March 2015 -- IETF 91, IETF 92, and the IEEE 802 | |||
Berlin. The purpose of the trials was to evaluate the use of MAC | Plenary in Berlin. The purpose of the experiments was to evaluate | |||
address randomization from two different perspectives: (1) the effect | the use of MAC address randomization from two different perspectives: | |||
on the connectivity experience of the end user, as well as any effect | (1) the effect on the connectivity experience of the end user, as | |||
on applications and OSes, and (2) the potential impact on the network | well as any effect on applications and OSes, and (2) the potential | |||
infrastructure itself. Some of the findings were published in | impact on the network infrastructure itself. Some of the findings | |||
[CSCN2015]. | were published in [CSCN2015]. | |||
During the trials, it was observed that the probability of address | During the experiments, it was observed that the probability of | |||
duplication in a network is negligible. The trials also revealed | address duplication in a network is negligible. The experiments also | |||
that other protocol identifiers (e.g., the DHCP client identifier) | revealed that other protocol identifiers (e.g., the DHCP client | |||
can be correlated and can therefore still be used to track an | identifier) can be correlated and can therefore still be used to | |||
individual. Hence, effective privacy tools should not work in | track an individual. Hence, effective privacy tools should not work | |||
isolation at a single layer; instead; they should be coordinated with | in isolation at a single layer; instead; they should be coordinated | |||
other privacy features at higher layers. | with other privacy features at higher layers. | |||
Since then, MAC randomization has been further implemented by mobile | Since then, MAC address randomization has been further implemented by | |||
OSes to provide better privacy for mobile phone users when connecting | mobile OSes to provide better privacy for mobile phone users when | |||
to public wireless networks [privacy_ios] [privacy_windows] | connecting to public wireless networks [privacy_ios] | |||
[privacy_android]. | [privacy_windows] [privacy_android]. | |||
3. Activities Relating to Randomized and Changing MAC Addresses in the | 3. Activities Relating to Randomized and Changing MAC Addresses in the | |||
IEEE 802 | IEEE 802 | |||
Practical experiences with Randomized and Changing MAC addresses | Practical experiences with Randomized and Changing MAC (RCM) | |||
(RCM) in devices (some of which are explained in Section 6) helped | addresses in devices (some of which are explained in Section 6) | |||
researchers fine-tune their understanding of attacks against | helped researchers fine-tune their understanding of attacks against | |||
randomization mechanisms [when_mac_randomization_fails]. Within the | randomization mechanisms [when_mac_randomization_fails]. Within the | |||
IEEE 802.11 group, these research experiences eventually formed the | IEEE 802.11 group, these research experiences eventually formed the | |||
basis for a specified mechanism that randomizes MAC addresses, which | basis for a specified mechanism that randomizes MAC addresses, which | |||
was introduced in IEEE Std 802.11aq [IEEE_802.11aq] in 2018. | was introduced in IEEE Std 802.11aq [IEEE_802.11aq] in 2018. | |||
More recent developments include turning on MAC randomization in | More recent developments include turning on MAC address randomization | |||
mobile OSes by default, which has an impact on the ability of network | in mobile OSes by default, which has an impact on the ability of | |||
operators to customize services [rcm_user_experience_csd]. | network operators to customize services [rcm_user_experience_csd]. | |||
Therefore, follow-on work in the IEEE 802.11 mapped effects of a | Therefore, follow-on work in the IEEE 802.11 mapped effects of a | |||
potentially large uptake of randomized MAC identifiers on a number of | potentially large uptake of randomized MAC identifiers on a number of | |||
commonly offered operator services in 2019 [rcm_tig_final_report]. | commonly offered operator services in 2019 [rcm_tig_final_report]. | |||
In the summer of 2020, this work emanated in two new standards | In the summer of 2020, this work emanated in two new standards | |||
projects with the purpose of developing mechanisms that do not | projects with the purpose of developing mechanisms that do not | |||
decrease user privacy but enable an optimal user experience when the | decrease user privacy but enable an optimal user experience when the | |||
MAC address of a device in an Extended Service Set (a group of | MAC address of a device in an Extended Service Set (a group of | |||
interconnected IEEE 802.11 wireless access points and stations that | interconnected IEEE 802.11 wireless access points and stations that | |||
form a single logical network) is randomized or changes | form a single logical network) is randomized or changes | |||
[rcm_user_experience_par] and user privacy solutions applicable to | [rcm_user_experience_par] and user privacy solutions applicable to | |||
skipping to change at line 310 ¶ | skipping to change at line 310 ¶ | |||
Considerations for IEEE 802(R) Technologies") [IEEE_802E] recommends | Considerations for IEEE 802(R) Technologies") [IEEE_802E] recommends | |||
the use of temporary and transient identifiers if there are no | the use of temporary and transient identifiers if there are no | |||
compelling reasons for a newly introduced identifier to be permanent. | compelling reasons for a newly introduced identifier to be permanent. | |||
This recommendation is part of the basis for the review of user | This recommendation is part of the basis for the review of user | |||
privacy solutions for IEEE Std 802.11 devices (also known as Wi-Fi | privacy solutions for IEEE Std 802.11 devices (also known as Wi-Fi | |||
devices) as part of the RCM efforts [rcm_privacy_csd]. Annex T of | devices) as part of the RCM efforts [rcm_privacy_csd]. Annex T of | |||
IEEE Std 802.1AEdk-2023 ("MAC Privacy Protection") [IEEE_802.1AEdk] | IEEE Std 802.1AEdk-2023 ("MAC Privacy Protection") [IEEE_802.1AEdk] | |||
discusses privacy considerations in bridged networks. | discusses privacy considerations in bridged networks. | |||
As of 2024, two task groups in IEEE 802.11 are dealing with issues | As of 2024, two task groups in IEEE 802.11 are dealing with issues | |||
related to RCM: | related to RCM addresses: | |||
* The IEEE 802.11bh task group, which is looking at mitigating the | * The IEEE 802.11bh task group, which is looking at mitigating the | |||
repercussions that RCM creates on 802.11 networks and related | repercussions that RCM addresses create on 802.11 networks and | |||
services. | related services. | |||
* The IEEE 802.11bi task group, which is chartered to define | * The IEEE 802.11bi task group, which is chartered to define | |||
modifications to the IEEE Std 802.11 MAC specification to specify | modifications to the IEEE Std 802.11 MAC specification to specify | |||
new mechanisms that address and improve user privacy. | new mechanisms that address and improve user privacy. | |||
4. Recent Activities Related to MAC Randomization in the WBA | 4. Recent Activities Related to MAC Address Randomization in the WBA | |||
In the Wireless Broadband Alliance (WBA), the Testing and | In the Wireless Broadband Alliance (WBA), the Testing and | |||
Interoperability Work Group has been looking at issues related to MAC | Interoperability Work Group has been looking at issues related to MAC | |||
address randomization and has identified a list of potential impacts | address randomization and has identified a list of potential impacts | |||
of these changes to existing systems and solutions, mainly related to | of these changes to existing systems and solutions, mainly related to | |||
Wi-Fi identification. | Wi-Fi identification. | |||
As part of this work, the WBA has documented a set of use cases that | As part of this work, the WBA has documented a set of use cases that | |||
a Wi-Fi Identification Standard should address in order to scale and | a Wi-Fi Identification Standard should address in order to scale and | |||
achieve longer-term sustainability of deployed services. A first | achieve longer-term sustainability of deployed services. A first | |||
version of this document has been liaised with the IETF as part of | version of that document, a paper titled "Wi-Fi Identification In a | |||
the MAC Address Device Identification for Network and Application | post MAC Randomization Era v1.0" [wba_paper], was created while | |||
Services (MADINAS) activities through the "Wi-Fi Identification In a | liaising with the IETF MADINAS Working Group. | |||
post MAC Randomization Era v1.0" paper [wba_paper]. | ||||
5. IPv6 Address Randomization in the IETF | 5. IPv6 Address Randomization in the IETF | |||
[RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for | [RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for | |||
IPv6, which typically results in hosts configuring one or more | IPv6, which typically results in hosts configuring one or more | |||
"stable" addresses composed of a network prefix advertised by a local | "stable" addresses composed of a network prefix advertised by a local | |||
router and an Interface Identifier (IID). [RFC8064] formally updated | router and an Interface Identifier (IID). [RFC8064] formally updated | |||
the original IPv6 IID selection mechanism to avoid generating the IID | the original IPv6 IID selection mechanism to avoid generating the IID | |||
from the MAC address of the interface (via EUI64), as this | from the MAC address of the interface (via EUI64), as this | |||
potentially allowed for tracking of a device at L3. Additionally, | potentially allowed for tracking of a device at L3. Additionally, | |||
skipping to change at line 366 ¶ | skipping to change at line 365 ¶ | |||
eavesdroppers and other information collectors may trivially perform | eavesdroppers and other information collectors may trivially perform | |||
address-based network-activity correlation when the same address is | address-based network-activity correlation when the same address is | |||
employed for multiple transactions by the same host. Additionally, | employed for multiple transactions by the same host. Additionally, | |||
it reduces the window of exposure of a host as being accessible via | it reduces the window of exposure of a host as being accessible via | |||
an address that becomes revealed as a result of active communication. | an address that becomes revealed as a result of active communication. | |||
These temporary addresses are meant to be used for a short period of | These temporary addresses are meant to be used for a short period of | |||
time (hours to days) and then deprecated. Deprecated addresses can | time (hours to days) and then deprecated. Deprecated addresses can | |||
continue to be used for already-established connections but are not | continue to be used for already-established connections but are not | |||
used to initiate new connections. New temporary addresses are | used to initiate new connections. New temporary addresses are | |||
generated periodically to replace temporary addresses that expire. | generated periodically to replace temporary addresses that expire. | |||
In order to do so, a node produces a sequence of temporary global | To generate temporary addresses, a node produces a sequence of | |||
scope addresses from a sequence of IIDs that appear to be random in | temporary global scope addresses from a sequence of IIDs that appear | |||
the sense that it is difficult for an outside observer to predict a | to be random in the sense that (1) it is difficult for an outside | |||
future address (or identifier) based on a current one and it is | observer to predict a future address (or identifier) based on a | |||
difficult to determine previous addresses (or identifiers) knowing | current one and (2) it is difficult to determine previous addresses | |||
only the present one. Temporary addresses should not be used by | (or identifiers) knowing only the present one. Temporary addresses | |||
applications that listen for incoming connections (as these are | should not be used by applications that listen for incoming | |||
supposed to be waiting on permanent/well-known identifiers). If a | connections (as these are supposed to be waiting on permanent/well- | |||
node changes network and comes back to a previously visited one, the | known identifiers). If a node changes network and comes back to a | |||
temporary addresses that the node would use will be different, which | previously visited one, the temporary addresses that the node would | |||
might be an issue in certain networks where addresses are used for | use will be different, which might be an issue in certain networks | |||
operational purposes (e.g., filtering or authentication). [RFC7217], | where addresses are used for operational purposes (e.g., filtering or | |||
summarized next, partially addresses the problems aforementioned. | authentication). [RFC7217], summarized next, partially addresses the | |||
problems aforementioned. | ||||
[RFC7217] describes a method to generate IIDs that are stable for | [RFC7217] describes a method to generate IIDs that are stable for | |||
each network interface within each subnet but change as a host moves | each network interface within each subnet but change as a host moves | |||
from one network to another. This method enables the "stability" | from one network to another. This method enables the "stability" | |||
properties of the IIDs specified in [RFC4291] to be kept, while still | properties of the IIDs specified in [RFC4291] to be kept, while still | |||
mitigating address-scanning attacks and preventing correlation of the | mitigating address-scanning attacks and preventing correlation of the | |||
activities of a host as it moves from one network to another. The | activities of a host as it moves from one network to another. The | |||
method defined to generate the IPv6 IID is based on computing a hash | method defined to generate the IPv6 IID is based on computing a hash | |||
function that takes the following as input: information that is | function that takes the following as input: information that is | |||
stable and associated to the interface (e.g., a local IID), stable | stable and associated to the interface (e.g., a local IID), stable | |||
information associated to the visited network (e.g., IEEE 802.11 | information associated to the visited network (e.g., the IEEE 802.11 | |||
SSID), the IPv6 prefix, a secret key, and some other additional | Service Set Identifier (SSID)), the IPv6 prefix, a secret key, and | |||
information. This basically ensures that a different IID is | some other additional information. This basically ensures that a | |||
generated when one of the input fields changes (such as the network | different IID is generated when one of the input fields changes (such | |||
or the prefix) but that the IID is the same within each subnet. | as the network or the prefix) but that the IID is the same within | |||
each subnet. | ||||
To mitigate the privacy threats posed by the use of MAC-derived IIDs, | To mitigate the privacy threats posed by the use of MAC-derived IIDs, | |||
[RFC8064] recommends that nodes implement [RFC7217] as the default | [RFC8064] recommends that nodes implement [RFC7217] as the default | |||
scheme for generating stable IPv6 addresses with SLAAC. | scheme for generating stable IPv6 addresses with SLAAC. | |||
In addition to the documents above, [RFC8947] proposes a DHCPv6 | In addition to the documents above, [RFC8947] proposes a DHCPv6 | |||
extension that: | extension that: | |||
| allows a scalable approach to link-layer address assignments where | | allows a scalable approach to link-layer address assignments where | |||
| preassigned link-layer address assignments (such as by a | | preassigned link-layer address assignments (such as by a | |||
skipping to change at line 435 ¶ | skipping to change at line 436 ¶ | |||
| designed to minimize disclosure of identifying information. | | designed to minimize disclosure of identifying information. | |||
[RFC7844] also indicates that the link-layer address, IP address, and | [RFC7844] also indicates that the link-layer address, IP address, and | |||
DHCP identifier shall evolve in synchrony. | DHCP identifier shall evolve in synchrony. | |||
6. Taxonomy of MAC Address Selection Policies | 6. Taxonomy of MAC Address Selection Policies | |||
This section documents different policies for MAC address selection. | This section documents different policies for MAC address selection. | |||
Some OSes might use a combination of multiple policies. | Some OSes might use a combination of multiple policies. | |||
Note about the naming convention used: The "M" in "MAC" is included | | Note about the naming convention used: The "M" in "MAC" is | |||
in the acronym but not the "A" from "Address". This allows one to | | included in the acronym but not the "A" from "Address". This | |||
talk about a PVOM Address or PNGM Address. | | allows one to talk about a "PVOM address" or "PNGM address". | |||
6.1. Per-Vendor OUI MAC Address (PVOM) | 6.1. Per-Vendor OUI MAC (PVOM) Address | |||
This form of MAC address selection is the historical default. | This form of MAC address selection is the historical default. | |||
The vendor obtains an OUI from the IEEE. This is a 24-bit prefix | The vendor obtains an OUI from the IEEE. This is a 24-bit prefix | |||
(including two upper bits that are set specifically) that is assigned | (including two upper bits that are set specifically) that is assigned | |||
to the vendor. The vendor generates a unique 24-bit value for the | to the vendor. The vendor generates a unique 24-bit value for the | |||
lower 24 bits, forming the 48-bit MAC address. It is not unusual for | lower 24 bits, forming the 48-bit MAC address. It is not unusual for | |||
the 24-bit value to be taken as an incrementing counter, assigned at | the 24-bit value to be used as an incrementing counter that was | |||
the factory, and burnt into non-volatile storage. | assigned at the factory and burnt into non-volatile storage. | |||
Note that 802.15.4 uses 64-bit MAC addresses, and the IEEE assigns | Note that IEEE Std 802.15.4 [IEEE_802.15.4] uses 64-bit MAC | |||
32-bit prefixes. The IEEE has indicated that there may be a future | addresses, and the IEEE assigns 32-bit prefixes. The IEEE has | |||
Ethernet specification that uses 64-bit MAC addresses. | indicated that there may be a future Ethernet specification that uses | |||
64-bit MAC addresses. | ||||
6.2. Per-Device Generated MAC Address (PDGM) | 6.2. Per-Device Generated MAC (PDGM) Address | |||
This form of MAC address is randomly generated by the device, usually | This form of MAC address is randomly generated by the device, usually | |||
upon first boot. The resulting MAC address is stored in non-volatile | upon first boot. The resulting MAC address is stored in non-volatile | |||
storage and is used for the rest of the device lifetime. | storage and is used for the rest of the device lifetime. | |||
6.3. Per-Boot Generated MAC Address (PBGM) | 6.3. Per-Boot Generated MAC (PBGM) Address | |||
This form of MAC address is randomly generated by the device each | This form of MAC address is randomly generated by the device each | |||
time the device is booted. The resulting MAC address is *not* stored | time the device is booted. The resulting MAC address is *not* stored | |||
in non-volatile storage. It does not persist across power cycles. | in non-volatile storage. It does not persist across power cycles. | |||
This case may sometimes be a PDGM where the non-volatile storage is | This case may sometimes be a PDGM address where the non-volatile | |||
no longer functional (or has failed). | storage is no longer functional (or has failed). | |||
6.4. Per-Network Generated MAC Address (PNGM) | 6.4. Per-Network Generated MAC (PNGM) Address | |||
This form of MAC address is generated each time a new network | This form of MAC address is generated each time a new network | |||
attachment is created. | attachment is created. | |||
This is typically used with Wi-Fi (802.11) networks where the network | This is typically used with Wi-Fi networks (i.e., 802.11 networks) | |||
is identified by an SSID Name. The generated address is stored in | where the network is identified by an SSID Name. The generated | |||
non-volatile storage, indexed by the SSID. Each time the device | address is stored in non-volatile storage, indexed by the SSID. Each | |||
returns to a network with the same SSID, the device uses the saved | time the device returns to a network with the same SSID, the device | |||
MAC address. | uses the saved MAC address. | |||
It is possible to use PNGM for wired Ethernet connections through | It is possible to use a PNGM address for wired Ethernet connections | |||
some passive observation of network traffic (such as STP | through some passive observation of network traffic (such as the | |||
[IEEE_802.1D], the Link Layer Discovery Protocol (LLDP) | Spanning Tree Protocol (SPT) [IEEE_802.1D], the Link Layer Discovery | |||
[IEEE_802.1AB], DHCP, or Router Advertisements) to determine which | Protocol (LLDP) [IEEE_802.1AB], DHCP, or Router Advertisements) to | |||
network has been attached. | determine which network has been attached. | |||
6.5. Per-Period Generated MAC Address (PPGM) | 6.5. Per-Period Generated MAC (PPGM) Address | |||
This form of MAC address is generated periodically, typically around | This form of MAC address is generated periodically, typically around | |||
every twelve hours. Like PNGM, it is used primarily with Wi-Fi. | every twelve hours. Like PNGM addresses, it is used primarily with | |||
Wi-Fi. | ||||
When the MAC address changes, the station disconnects from the | When the MAC address changes, the station disconnects from the | |||
current session and reconnects using the new MAC address. This will | current session and reconnects using the new MAC address. This will | |||
involve a new WPA/802.1x session: new Extensible Authentication | involve a new WPA/802.1x session, as well as obtaining (or | |||
Protocol (EAP), TLS, etc. negotiations. A new DHCP, SLAAC will be | refreshing) a new IP address (e.g., using DHCP or SLAAC). | |||
done. | ||||
If DHCP is used, then a new DHCP Unique Identifier (DUID) is | If DHCP is used, then a new DHCP Unique Identifier (DUID) is | |||
generated so as to not link to the previous connection; this usually | generated so as to not link to the previous connection; this usually | |||
results in the allocation of new IP addresses. | results in the allocation of new IP addresses. | |||
6.6. Per-Session Generated MAC Address (PSGM) | 6.6. Per-Session Generated MAC (PSGM) Address | |||
This form of MAC address is generated on a per-session basis. How a | This form of MAC address is generated on a per-session basis. How a | |||
session is defined is implementation-dependent, for example, a | session is defined is implementation-dependent, for example, a | |||
session might be defined by logging in to a portal, VPN, etc. Like | session might be defined by logging in to a portal, VPN, etc. Like | |||
PNGM, PSGM is used primarily with Wi-Fi. | PNGM and PPGM addresses, it is used primarily with Wi-Fi. | |||
Since the address only changes when a new session is established, | Since the address only changes when a new session is established, | |||
there is no disconnection/reconnection involved. | there is no disconnection/reconnection involved. | |||
7. OS Current Practices | 7. OS Current Practices | |||
By default, most modern OSes (especially mobile ones) do implement | By default, most modern OSes (especially mobile ones) do implement | |||
some MAC address randomization policies. Since the mechanism and | some MAC address randomization policies. Since the mechanism and | |||
policies that OSes implement can evolve with time, the content is now | policies that OSes implement can evolve with time, the content is now | |||
hosted at [OS_current_practices]. For completeness, a snapshot of | hosted at [OS_current_practices]. For completeness, a snapshot of | |||
skipping to change at line 570 ¶ | skipping to change at line 572 ¶ | |||
the taxonomy introduced in Section 6), performs address randomization | the taxonomy introduced in Section 6), performs address randomization | |||
per new connection (PSGM), performs address randomization daily (PPGM | per new connection (PSGM), performs address randomization daily (PPGM | |||
with a period of 24 hours), supports configuration per SSID, supports | with a period of 24 hours), supports configuration per SSID, supports | |||
address randomization for scanning, and supports address | address randomization for scanning, and supports address | |||
randomization for scanning by default. | randomization for scanning by default. | |||
+=================+===============+=========+=========+=====+ | +=================+===============+=========+=========+=====+ | |||
| OS | Linux (Debian | Android | Windows | iOS | | | OS | Linux (Debian | Android | Windows | iOS | | |||
| | "bookworm") | 10 | 10 | 14+ | | | | "bookworm") | 10 | 10 | 14+ | | |||
+=================+===============+=========+=========+=====+ | +=================+===============+=========+=========+=====+ | |||
| Random per net. | Y | Y | Y | Y | | | Random. per | Y | Y | Y | Y | | |||
| (PNGM) | | | | | | | net. (PNGM) | | | | | | |||
+-----------------+---------------+---------+---------+-----+ | +-----------------+---------------+---------+---------+-----+ | |||
| Random per | Y | N | N | N | | | Random. per | Y | N | N | N | | |||
| connec. (PSGM) | | | | | | | connec. (PSGM) | | | | | | |||
+-----------------+---------------+---------+---------+-----+ | +-----------------+---------------+---------+---------+-----+ | |||
| Random daily | N | N | Y | N | | | Random. daily | N | N | Y | N | | |||
| (PPGM) | | | | | | | (PPGM) | | | | | | |||
+-----------------+---------------+---------+---------+-----+ | +-----------------+---------------+---------+---------+-----+ | |||
| SSID config. | Y | N | N | N | | | SSID config. | Y | N | N | N | | |||
+-----------------+---------------+---------+---------+-----+ | +-----------------+---------------+---------+---------+-----+ | |||
| Random. for | Y | Y | Y | Y | | | Random. for | Y | Y | Y | Y | | |||
| scan | | | | | | | scan | | | | | | |||
+-----------------+---------------+---------+---------+-----+ | +-----------------+---------------+---------+---------+-----+ | |||
| Random. for | N | Y | N | Y | | | Random. for | N | Y | N | Y | | |||
| scan by default | | | | | | | scan by default | | | | | | |||
+-----------------+---------------+---------+---------+-----+ | +-----------------+---------------+---------+---------+-----+ | |||
skipping to change at line 627 ¶ | skipping to change at line 629 ¶ | |||
* Mitigating the problem of location privacy while minimizing the | * Mitigating the problem of location privacy while minimizing the | |||
impact on upper layers of the protocol stack | impact on upper layers of the protocol stack | |||
* Providing the means for network operators to authenticate devices | * Providing the means for network operators to authenticate devices | |||
and authorize network access, despite the MAC addresses changing | and authorize network access, despite the MAC addresses changing | |||
according some pattern | according some pattern | |||
* Providing the means for the device not to use MAC addresses that | * Providing the means for the device not to use MAC addresses that | |||
it is not authorized to use or that are currently in use | it is not authorized to use or that are currently in use | |||
A major conclusion of the work in IEEE Std 802E concerned the | A major conclusion of the work in IEEE Std 802E [IEEE_802E] concerned | |||
difficulty of defending privacy against adversaries of any | the difficulty of defending privacy against adversaries of any | |||
sophistication. Individuals can be successfully tracked by | sophistication. Individuals can be successfully tracked by | |||
fingerprinting, using aspects of their communication other than MAC | fingerprinting, using aspects of their communication other than MAC | |||
addresses or other permanent identifiers. | addresses or other permanent identifiers. | |||
10. Informative References | 10. Informative References | |||
[contact_tracing_paper] | [contact_tracing_paper] | |||
Leith, D. J. and S. Farrell, "Contact Tracing App Privacy: | Leith, D. J. and S. Farrell, "Contact Tracing App Privacy: | |||
What Data Is Shared By Europe's GAEN Contact Tracing | What Data Is Shared By Europe's GAEN Contact Tracing | |||
Apps", IEEE INFOCOM 2021 - IEEE Conference on Computer | Apps", IEEE INFOCOM 2021 - IEEE Conference on Computer | |||
skipping to change at line 672 ¶ | skipping to change at line 674 ¶ | |||
[IEEE_802.11aq] | [IEEE_802.11aq] | |||
IEEE, "IEEE Standard for Information technology-- | IEEE, "IEEE Standard for Information technology-- | |||
Telecommunications and information exchange between | Telecommunications and information exchange between | |||
systems Local and metropolitan area network--Specific | systems Local and metropolitan area network--Specific | |||
requirements Part 11: Wireless LAN Medium Access Control | requirements Part 11: Wireless LAN Medium Access Control | |||
(MAC) and Physical Layer (PHY) Specifications Amendment 5: | (MAC) and Physical Layer (PHY) Specifications Amendment 5: | |||
Preassociation Discovery", IEEE Std 802.11aq-2018, | Preassociation Discovery", IEEE Std 802.11aq-2018, | |||
DOI 10.1109/IEEESTD.2018.8457463, August 2018, | DOI 10.1109/IEEESTD.2018.8457463, August 2018, | |||
<https://doi.org/10.1109/IEEESTD.2018.8457463>. | <https://doi.org/10.1109/IEEESTD.2018.8457463>. | |||
[IEEE_802.15.4] | ||||
IEEE, "IEEE Standard for Low‐Rate Wireless Networks", IEEE | ||||
Std 802.15.4-2024, DOI 10.1109/IEEESTD.2024.10794632, | ||||
December 2024, | ||||
<https://doi.org/10.1109/IEEESTD.2024.10794632>. | ||||
[IEEE_802.1AB] | [IEEE_802.1AB] | |||
IEEE, "IEEE Standard for Local and metropolitan area | IEEE, "IEEE Standard for Local and metropolitan area | |||
networks - Station and Media Access Control Connectivity | networks - Station and Media Access Control Connectivity | |||
Discovery", IEEE Std 802.1AB-2016, | Discovery", IEEE Std 802.1AB-2016, | |||
DOI 10.1109/IEEESTD.2016.7433915, March 2016, | DOI 10.1109/IEEESTD.2016.7433915, March 2016, | |||
<https://doi.org/10.1109/IEEESTD.2016.7433915>. | <https://doi.org/10.1109/IEEESTD.2016.7433915>. | |||
[IEEE_802.1AEdk] | [IEEE_802.1AEdk] | |||
IEEE, "IEEE Standard for Local and metropolitan area | IEEE, "IEEE Standard for Local and metropolitan area | |||
networks-Media Access Control (MAC) Security - Amendment | networks-Media Access Control (MAC) Security - Amendment | |||
4: MAC Privacy protection", IEEE Std 802.1AEdk-2023, | 4: MAC Privacy protection", IEEE Std 802.1AEdk-2023, | |||
DOI 10.1109/IEEESTD.2023.10225636, August 2023, | DOI 10.1109/IEEESTD.2023.10225636, August 2023, | |||
<https://doi.org/10.1109/IEEESTD.2023.10225636>. | <https://doi.org/10.1109/IEEESTD.2023.10225636>. | |||
[IEEE_802.1D] | [IEEE_802.1D] | |||
IEEE, "IEEE Standard for Local and metropolitan area | IEEE, "IEEE Standard for Local and metropolitan area | |||
networks: Media Access Control (MAC) Bridges", IEEE Std | networks: Media Access Control (MAC) Bridges", IEEE Std | |||
802.1D-2004, DOI 10.1109/IEEESTD.2004.94569, June 2004, | 802.1D-2004, DOI 10.1109/IEEESTD.2004.94569, June 2004, | |||
<https://ieeexplore.ieee.org/document/1309630>. | <https://doi.org/10.1109/IEEESTD.2004.94569>. | |||
[IEEE_802c] | [IEEE_802c] | |||
IEEE, "IEEE Standard for Local and Metropolitan Area | IEEE, "IEEE Standard for Local and Metropolitan Area | |||
Networks:Overview and Architecture--Amendment 2: Local | Networks:Overview and Architecture--Amendment 2: Local | |||
Medium Access Control (MAC) Address Usage", IEEE Std 802c- | Medium Access Control (MAC) Address Usage", IEEE Std 802c- | |||
2017, DOI 10.1109/IEEESTD.2017.8016709, August 2017, | 2017, DOI 10.1109/IEEESTD.2017.8016709, August 2017, | |||
<https://doi.org/10.1109/IEEESTD.2017.8016709>. | <https://doi.org/10.1109/IEEESTD.2017.8016709>. | |||
[IEEE_802E] | [IEEE_802E] | |||
IEEE, "IEEE Recommended Practice for Privacy | IEEE, "IEEE Recommended Practice for Privacy | |||
skipping to change at line 864 ¶ | skipping to change at line 872 ¶ | |||
regarding address randomization. | regarding address randomization. | |||
The authors would also like to thank Jerome Henry, Hai Shalom, | The authors would also like to thank Jerome Henry, Hai Shalom, | |||
Stephen Farrell, Alan DeKok, Mathieu Cunche, Johanna Ansohn | Stephen Farrell, Alan DeKok, Mathieu Cunche, Johanna Ansohn | |||
McDougall, Peter Yee, Bob Hinden, Behcet Sarikaya, David Farmer, | McDougall, Peter Yee, Bob Hinden, Behcet Sarikaya, David Farmer, | |||
Mohamed Boucadair, Éric Vyncke, Christian Amsüss, Roman Danyliw, | Mohamed Boucadair, Éric Vyncke, Christian Amsüss, Roman Danyliw, | |||
Murray Kucherawy, and Paul Wouters for their reviews and comments on | Murray Kucherawy, and Paul Wouters for their reviews and comments on | |||
previous draft versions of this document. In addition, the authors | previous draft versions of this document. In addition, the authors | |||
would like to thank Michael Richardson for his contributions on the | would like to thank Michael Richardson for his contributions on the | |||
taxonomy section. Finally, the authors would like to thank the IEEE | taxonomy section. Finally, the authors would like to thank the IEEE | |||
802.1 Working Group for its review and comments, performed as part of | 802.1 Working Group for its review and comments (see | |||
the "Liaison statement on Randomized and Changing MAC Address" | https://datatracker.ietf.org/liaison/1884/). | |||
(https://datatracker.ietf.org/liaison/1884/). | ||||
Authors' Addresses | Authors' Addresses | |||
Juan Carlos Zúñiga | Juan Carlos Zúñiga | |||
Cisco | Cisco | |||
Montreal QC | Montreal QC | |||
Canada | Canada | |||
Email: juzuniga@cisco.com | Email: juzuniga@cisco.com | |||
Carlos J. Bernardos (editor) | Carlos J. Bernardos (editor) | |||
End of changes. 41 change blocks. | ||||
108 lines changed or deleted | 115 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |