rfc9797v1.txt | rfc9797.txt | |||
---|---|---|---|---|
skipping to change at line 15 ¶ | skipping to change at line 15 ¶ | |||
ISSN: 2070-1721 Comcast | ISSN: 2070-1721 Comcast | |||
June 2025 | June 2025 | |||
Randomized and Changing Media Access Control (MAC) Addresses: Context, | Randomized and Changing Media Access Control (MAC) Addresses: Context, | |||
Network Impacts, and Use Cases | Network Impacts, and Use Cases | |||
Abstract | Abstract | |||
To limit the privacy issues created by the association between a | To limit the privacy issues created by the association between a | |||
device, its traffic, its location, and its user in IEEE 802 networks, | device, its traffic, its location, and its user in IEEE 802 networks, | |||
client and client Operating System vendors have started implementing | client vendors and client OS vendors have started implementing Media | |||
Media Access Control (MAC) address randomization. This technology is | Access Control (MAC) address randomization. This technology is | |||
particularly important in Wi-Fi networks (defined in IEEE 802.11) due | particularly important in Wi-Fi networks (defined in IEEE 802.11) due | |||
to the over-the-air medium and device mobility. When such | to the over-the-air medium and device mobility. When such | |||
randomization happens, some in-network states may break, which may | randomization happens, some in-network states may break, which may | |||
affect network connectivity and user experience. At the same time, | affect network connectivity and user experience. At the same time, | |||
devices may continue using other stable identifiers, defeating the | devices may continue using other stable identifiers, defeating the | |||
purpose of MAC address randomization. | purpose of MAC address randomization. | |||
This document lists various network environments and a range of | This document lists various network environments and a range of | |||
network services that may be affected by such randomization. This | network services that may be affected by such randomization. This | |||
document then examines settings where the user experience may be | document then examines settings where the user experience may be | |||
skipping to change at line 133 ¶ | skipping to change at line 133 ¶ | |||
communication may be disrupted. For example, sessions established | communication may be disrupted. For example, sessions established | |||
between the end device and the network services may break, and | between the end device and the network services may break, and | |||
packets in transit may suddenly be lost. If multiple clients | packets in transit may suddenly be lost. If multiple clients | |||
implement aggressive (e.g., once an hour or shorter) MAC address | implement aggressive (e.g., once an hour or shorter) MAC address | |||
randomization without coordination with network services, some | randomization without coordination with network services, some | |||
network services, such as MAC address caching in the AP and the | network services, such as MAC address caching in the AP and the | |||
upstream Layer 2 switch, may not be able to handle the load, which | upstream Layer 2 switch, may not be able to handle the load, which | |||
may result in an unexpected network interruption. | may result in an unexpected network interruption. | |||
At the same time, some network services rely on the end station (as | At the same time, some network services rely on the end station (as | |||
defined by [IEEE_802], also called in this document device, or | defined by [IEEE_802]) to provide an identifier, which can be the MAC | |||
machine) providing an identifier, which can be the MAC address or | address or another value. This document also refers to the end | |||
another value. If the client implements MAC address randomization | station as a "device" or "machine". If the client implements MAC | |||
but continues sending the same static identifier, then the | address randomization but continues sending the same static | |||
association between a stable identifier and the station continues | identifier, then the association between a stable identifier and the | |||
despite the RCM scheme. There may be environments where such | station continues despite the RCM scheme. There may be environments | |||
continued association is desirable, but there may be others where | where such continued association is desirable, but there may be | |||
user privacy has more value than any continuity of network service | others where user privacy has more value than any continuity of | |||
state. | network service state. | |||
It is useful for implementations of client and network devices to | It is useful for implementations of client and network devices to | |||
enumerate services that may be affected by RCM and to evaluate | enumerate services that may be affected by RCM and to evaluate | |||
possible frameworks to maintain both the quality of user experience | possible frameworks to maintain both the quality of user experience | |||
and network efficiency while RCM happens and user privacy is | and network efficiency while RCM happens and user privacy is | |||
strengthened. This document presents these assessments and | strengthened. This document presents these assessments and | |||
recommendations. | recommendations. | |||
Although this document mainly discusses MAC address randomization in | Although this document mainly discusses MAC address randomization in | |||
Wi-Fi networks [IEEE_802.11], the same principles can be easily | Wi-Fi networks [IEEE_802.11], the same principles can be easily | |||
extended to any IEEE 802.3 networks [IEEE_802.3]. | extended to any IEEE 802 networks [IEEE_802.3]. | |||
This document is organized as follows: | This document is organized as follows: | |||
* Section 2 discusses the current status of using MAC address as | * Section 2 discusses the current status of using MAC address as | |||
identity. | identity. | |||
* Section 3 discusses various actors in the network that will be | * Section 3 discusses various actors in the network that will be | |||
impacted by MAC address randomization. | impacted by MAC address randomization. | |||
* Section 4 examines the degrees of trust between personal devices | * Section 4 examines the degrees of trust between personal devices | |||
skipping to change at line 175 ¶ | skipping to change at line 175 ¶ | |||
* Section 5 discusses various network environments that will be | * Section 5 discusses various network environments that will be | |||
impacted. | impacted. | |||
* Section 6 analyzes some existing network services that will be | * Section 6 analyzes some existing network services that will be | |||
impacted. | impacted. | |||
* Appendix A includes some existing frameworks. | * Appendix A includes some existing frameworks. | |||
2. MAC Address as Identity: User vs. Device | 2. MAC Address as Identity: User vs. Device | |||
In IEEE 802.3 technologies [IEEE_802.3], the Media Access Control | In IEEE 802 [IEEE_802] technologies, the Media Access Control (MAC) | |||
(MAC) layer defines rules to control how a device accesses the shared | layer defines rules to control how a device accesses the shared | |||
medium. In a network where a machine can communicate with one or | medium. In a network where a machine can communicate with one or | |||
more other machines, one such rule is that each machine needs to be | more other machines, one such rule is that each machine needs to be | |||
identified as either the target destination of a message or the | identified as either the target destination of a message or the | |||
source of a message (and the target destination of the answer). | source of a message (and the target destination of the answer). | |||
Initially intended as a 48-bit (6-octet) value in the first versions | Initially intended as a 48-bit (6-octet) value in the first versions | |||
of [IEEE_802.3], other standards under the IEEE 802.3 umbrella allow | of IEEE 802, other standards under the IEEE 802 [IEEE_802] umbrella | |||
this address to take an extended format of 64 bits (8 octets), which | allow this address to take an extended format of 64 bits (8 octets), | |||
enabled a larger number of MAC addresses to coexist as IEEE 802.3 | which enabled a larger number of MAC addresses to coexist as IEEE 802 | |||
technologies became widely adopted. | technologies became widely adopted. | |||
Regardless of the address length, different networks have different | Regardless of the address length, different networks have different | |||
needs, and several bits of the first octet are reserved for specific | needs, and several bits of the first octet are reserved for specific | |||
purposes. In particular, the first bit is used to identify the | purposes. In particular, the first bit is used to identify the | |||
destination address as an individual (bit set to 0) or a group | destination address as an individual (bit set to 0) or a group | |||
address (bit set to 1). The second bit, called the Universal/Local | address (bit set to 1). The second bit, called the Universal/Local | |||
(U/L) address bit, indicates whether the address has been assigned by | (U/L) address bit, indicates whether the address has been assigned by | |||
a universal or local administrator. Universally administered | a universal or local administrator. Universally administered | |||
addresses have this bit set to 0. If this bit is set to 1, the | addresses have this bit set to 0. If this bit is set to 1, the | |||
entire address is considered to be locally administered (see Clause | entire address is considered to be locally administered (see Clause | |||
8.4 of [IEEE_802]). Note that universally administered MAC addresses | 8.4 of [IEEE_802]). Note that universally administered MAC addresses | |||
are required to register to IEEE, while locally administered MAC | are required to be registered with the IEEE, while locally | |||
addresses are not. | administered MAC addresses are not. | |||
The intent of this provision is important for the present document. | The intent of this provision is important for the present document. | |||
[IEEE_802] recognizes that some devices (e.g., smart thermostats) may | [IEEE_802] recognizes that some devices (e.g., smart thermostats) may | |||
never change their attachment network and will not need a globally | never change their attachment network and will not need a globally | |||
unique MAC address to prevent address collision against any other | unique MAC address to prevent address collision against any other | |||
device in any other network. The U/L bit can be set to signal to the | device in any other network. The U/L bit can be set to signal to the | |||
network that the MAC address is intended to be locally unique (not | network that the MAC address is intended to be locally unique (not | |||
globally unique). [IEEE_802] did not initially define the MAC | globally unique). [IEEE_802] did not initially define the MAC | |||
address allocation schema when the U/L bit is set to 1. It states | address allocation schema when the U/L bit is set to 1. It states | |||
the address must be unique in a given broadcast domain (i.e., the | the address must be unique in a given broadcast domain (i.e., the | |||
skipping to change at line 258 ¶ | skipping to change at line 258 ¶ | |||
Personally Identifiable Information (PII)) is enough to link the MAC | Personally Identifiable Information (PII)) is enough to link the MAC | |||
address to that user. Then, any detection of traffic that can be | address to that user. Then, any detection of traffic that can be | |||
associated with the device will also be linked to the known user of | associated with the device will also be linked to the known user of | |||
that device (i.e., Personally Correlated Information (PCI)). | that device (i.e., Personally Correlated Information (PCI)). | |||
2.1. Privacy of MAC Addresses | 2.1. Privacy of MAC Addresses | |||
The possible identification or association presents a privacy issue, | The possible identification or association presents a privacy issue, | |||
especially with wireless technologies. For most of them | especially with wireless technologies. For most of them | |||
([IEEE_802.11] in particular), the source and destination MAC | ([IEEE_802.11] in particular), the source and destination MAC | |||
addresses are not encrypted, even in networks that implement | addresses are not encrypted even in networks that implement | |||
encryption. Thus, each machine can easily detect if it is the | encryption. This lack of encryption allows each machine to easily | |||
intended target of the message before attempting to decrypt its | detect if it is the intended target of the message before attempting | |||
content, and also identify the transmitter, to use the right | to decrypt its content and also helps identify the transmitter in | |||
decryption key when multiple unicast keys are in effect. | order to use the right decryption key when multiple unicast keys are | |||
in effect. | ||||
This identification of the user associated with a node was clearly | This identification of the user associated with a node was clearly | |||
not the intent of the IEEE 802 MAC address. A logical solution to | not the intent of the IEEE 802 MAC address. A logical solution to | |||
remove this association is to use a locally administered address | remove this association is to use a locally administered address | |||
instead and change the address in a fashion that prevents a | instead and change the address in a fashion that prevents a | |||
continuous association between one MAC address and some PII. | continuous association between one MAC address and some PII. | |||
However, other network devices on the same LAN implementing a MAC | However, other network devices on the same LAN implementing a MAC | |||
layer also expect each device to be associated with a MAC address | layer also expect each device to be associated with a MAC address | |||
that would persist over time. When a device changes its MAC address, | that would persist over time. When a device changes its MAC address, | |||
other devices on the same LAN may fail to recognize that the same | other devices on the same LAN may fail to recognize that the same | |||
skipping to change at line 308 ¶ | skipping to change at line 309 ¶ | |||
utilized by several types of network functional entities such as | utilized by several types of network functional entities such as | |||
applications or devices that provide a service related to network | applications or devices that provide a service related to network | |||
operations. | operations. | |||
1. Wireless access network infrastructure devices (e.g., WLAN access | 1. Wireless access network infrastructure devices (e.g., WLAN access | |||
points or controllers): These devices participate in IEEE 802 LAN | points or controllers): These devices participate in IEEE 802 LAN | |||
operations. As such, they need to identify each machine as a | operations. As such, they need to identify each machine as a | |||
source or destination to successfully continue exchanging frames. | source or destination to successfully continue exchanging frames. | |||
As a device changes its network attachment (roams) from one | As a device changes its network attachment (roams) from one | |||
access point to another, the access points can exchange | access point to another, the access points can exchange | |||
contextual information (e.g., device MAC and keying material), | contextual information (e.g., device MAC address and keying | |||
allowing the device session to continue seamlessly. These access | material), allowing the device session to continue seamlessly. | |||
points can also inform devices further in the wired network about | These access points can also inform devices further in the wired | |||
the roam to ensure that Layer 2 frames are redirected to the new | network about the roam to ensure that Layer 2 frames are | |||
device access point. | redirected to the new device access point. | |||
2. Other network devices operating at the MAC layer: Many wireless | 2. Other network devices operating at the MAC layer: Many wireless | |||
network access devices (e.g., access points [IEEE_802.11]) are | network access devices (e.g., access points [IEEE_802.11]) are | |||
conceived as Layer 2 devices, and as such, they bridge a frame | conceived as Layer 2 devices, and as such, they bridge a frame | |||
from one medium (e.g., Wi-Fi [IEEE_802.11]) to another (e.g., | from one medium (e.g., Wi-Fi [IEEE_802.11]) to another (e.g., | |||
Ethernet [IEEE_802.3]). This means that the MAC address of a | Ethernet [IEEE_802.3]). This means that the MAC address of a | |||
wireless device often exists on the wire beyond the wireless | wireless device often exists on the wire beyond the wireless | |||
access device. Devices connected to this wire also implement | access device. Devices connected to this wire also implement | |||
IEEE 802.3 technologies [IEEE_802.3], and as such, they operate | IEEE 802.3 technologies [IEEE_802.3], and as such, they operate | |||
on the expectation that each device is associated with a MAC | on the expectation that each device is associated with a MAC | |||
address that persists for the duration of continuous exchanges. | address that persists for the duration of continuous exchanges. | |||
For example, switches and bridges associate MAC addresses to | For example, switches and bridges associate MAC addresses to | |||
individual ports (so as to know to which port to send a frame | individual ports (so as to know to which port to send a frame | |||
intended for a particular MAC address). Similarly, AAA services | intended for a particular MAC address). Similarly, AAA services | |||
can validate the identity of a device and use the device's MAC | can validate the identity of a device and use the device MAC | |||
address as the first pointer to the device identity (before | address as the first pointer to the device identity (before | |||
operating further verification). Similarly, some networking | operating further verification). Similarly, some networking | |||
devices offer Layer 2 filtering policies that may rely on the | devices offer Layer 2 filtering policies that may rely on the | |||
connected MAC addresses. IEEE 802.1X-enabled devices | connected MAC addresses. IEEE 802.1X-enabled devices | |||
[IEEE_802.1X] may also selectively put the interface in a | [IEEE_802.1X] may also selectively put the interface in a | |||
blocking state until a connecting device is authenticated. These | blocking state until a connecting device is authenticated. These | |||
services then use the MAC address as the first pointer to the | services then use the MAC address as the first pointer to the | |||
device identity to allow or block data traffic. This list is not | device identity to allow or block data traffic. This list is not | |||
exhaustive. Multiple services are defined for IEEE 802.3 | exhaustive. Multiple services are defined for Ethernet networks | |||
networks [IEEE_802.3], and multiple services defined by the IEEE | [IEEE_802.3], and multiple services defined by the IEEE 802.1 | |||
802.1 Working Group are also applicable to IEEE 802.3 networks | working group are also applicable to Ethernet networks | |||
[IEEE_802.3]. Wireless access points may also connect to mediums | [IEEE_802.3]. Wireless access points may also connect using | |||
other than [IEEE_802.3] (e.g., the Data-Over-Cable Service | other mediums (e.g., the Data-Over-Cable Service Interface | |||
Interface Specification (DOCSIS) [DOCSIS]), which also implements | Specification (DOCSIS) [DOCSIS]) that implement mechanisms under | |||
mechanisms under the umbrella of the general IEEE 802 standard | the umbrella of the general 802 Standard and therefore expect the | |||
and therefore expect the unique and persistent association of a | unique and persistent association of a MAC address to a device. | |||
MAC address to a device. | ||||
3. Network devices operating at upper layers: Some network devices | 3. Network devices operating at upper layers: Some network devices | |||
provide functions and services above the MAC layer. Some of them | provide functions and services above the MAC layer. Some of them | |||
also operate a MAC layer function. For example, routers provide | also operate a MAC layer function. For example, routers provide | |||
IP forwarding services but rely on the device MAC address to | IP forwarding services but rely on the device MAC address to | |||
create the appropriate frame structure. Other devices and | create the appropriate frame structure. Other devices and | |||
services operate at upper layers but also rely upon the IEEE 802 | services operate at upper layers but also rely upon the IEEE 802 | |||
principles of unique MAC-to-device mapping. For example, the | principles of unique MAC-to-device mapping. For example, the | |||
Address Resolution Protocol (ARP) [RFC826] and Neighbor Discovery | Address Resolution Protocol (ARP) [RFC826] and Neighbor Discovery | |||
Protocol (NDP) [RFC4861] use a MAC address to create the mapping | Protocol (NDP) [RFC4861] use a MAC address to create the mapping | |||
skipping to change at line 369 ¶ | skipping to change at line 369 ¶ | |||
service and traffic forwarding may be disrupted. | service and traffic forwarding may be disrupted. | |||
3.2. Human-Related Entities | 3.2. Human-Related Entities | |||
Humans may actively participate in the network structure and | Humans may actively participate in the network structure and | |||
operations or be observers at any point of the network lifecycle. | operations or be observers at any point of the network lifecycle. | |||
Humans could be users of wireless devices or people operating | Humans could be users of wireless devices or people operating | |||
wireless networks. | wireless networks. | |||
1. Over-the-Air (OTA) observers: The transmitting or receiving MAC | 1. Over-the-Air (OTA) observers: The transmitting or receiving MAC | |||
address is usually not encrypted in wireless exchanges in IEEE | address is usually not encrypted in wireless exchanges using IEEE | |||
802 technologies, and any protocol-compatible device in range of | 802 technologies, and any protocol-compatible device in range of | |||
the signal can read the frame header. As such, OTA observers are | the signal can read the frame header. As such, OTA observers are | |||
able to read the MAC addresses of individual transmissions. Some | able to read the MAC addresses of individual transmissions. Some | |||
wireless technologies also support techniques to establish | wireless technologies also support techniques to establish | |||
distances or positions, allowing the observer, in some cases, to | distances or positions, allowing the observer, in some cases, to | |||
uniquely associate the MAC address with a physical device and its | uniquely associate the MAC address with a physical device and its | |||
associated location. An OTA observer may have a legitimate | associated location. An OTA observer may have a legitimate | |||
reason to monitor a particular device, for example, for IT | reason to monitor a particular device, for example, for IT | |||
support operations. However, another actor might also monitor | support operations. However, another actor might also monitor | |||
the same device to obtain PII or PCI. | the same device to obtain PII or PCI. | |||
skipping to change at line 424 ¶ | skipping to change at line 424 ¶ | |||
5. Over-the-Wired external (OTWe) observers: Beyond the broadcast | 5. Over-the-Wired external (OTWe) observers: Beyond the broadcast | |||
domain, frame headers are removed by a routing device, and a new | domain, frame headers are removed by a routing device, and a new | |||
Layer 2 header is added before the frame is transmitted to the | Layer 2 header is added before the frame is transmitted to the | |||
next segment. The device MAC address is not visible anymore | next segment. The device MAC address is not visible anymore | |||
unless a mechanism copies the MAC address into a field that can | unless a mechanism copies the MAC address into a field that can | |||
be read while the packet travels to the next segment (e.g., IPv6 | be read while the packet travels to the next segment (e.g., IPv6 | |||
addresses built from the MAC address prior to the use of the | addresses built from the MAC address prior to the use of the | |||
methods defined in [RFC4941] and [RFC7217]). Therefore, unless | methods defined in [RFC4941] and [RFC7217]). Therefore, unless | |||
this last condition exists, OTWe observers are not able to see | this last condition exists, OTWe observers are not able to see | |||
the device's MAC address. | the device MAC address. | |||
4. Degrees of Trust | 4. Degrees of Trust | |||
The surface of PII exposures that can drive MAC address randomization | The surface of PII exposures that can drive MAC address randomization | |||
depends on (1) the environment where the device operates, (2) the | depends on (1) the environment where the device operates, (2) the | |||
presence and nature of other devices in the environment, and (3) the | presence and nature of other devices in the environment, and (3) the | |||
type of network the device is communicating through. Consequently, a | type of network the device is communicating through. Consequently, a | |||
device can use an identifier (such as a MAC address) that can persist | device can use an identifier (such as a MAC address) that can persist | |||
over time if trust with the environment is established, or it can use | over time if trust with the environment is established, or it can use | |||
an identifier that is temporary if an identifier is required for a | an identifier that is temporary if an identifier is required for a | |||
service in an environment where trust has not been established. Note | service in an environment where trust has not been established. Note | |||
that trust is not binary. It is useful to distinguish what trust a | that trust is not binary. It is useful to distinguish what trust a | |||
personal device may establish with the different entities at play in | personal device may establish with the different entities at play in | |||
a network domain where a MAC address may be visible: | a network domain where a MAC address may be visible: | |||
1. Full trust: There is an environment where a device establishes a | 1. Full trust: The device establishes a trust relationship and | |||
trust relationship, and the device can share its persistent MAC | shares its persistent MAC address with the access network devices | |||
address with the access network devices (e.g., access point and | (e.g., access point and WLAN controller). The network provides | |||
WLAN controller). The network provides necessary security | necessary security measures to prevent observers or network | |||
measures to prevent observers or network actors from accessing | actors from accessing PII. The device (or its user) also has | |||
PII. The device (or its user) also has confidence that its MAC | confidence that its MAC address is not shared beyond the Layer 2 | |||
address is not shared beyond the Layer 2 broadcast domain | broadcast domain boundary. | |||
boundary. | ||||
2. Selective trust: In another environment, depending on the | 2. Selective trust: Depending on the predefined privacy policies, a | |||
predefined privacy policies, a device may decide to use one | device may decide to use one pseudo-persistent MAC address for a | |||
pseudo-persistent MAC address for a set of network elements and | set of network elements and another pseudo-persistent MAC address | |||
another pseudo-persistent MAC address for another set of network | for another set of network elements. Examples of privacy | |||
elements. Examples of privacy policies can be a combination of | policies can be a combination of Service Set Identifier (SSID) | |||
Service Set Identifier (SSID) and Basic Service Set Identifier | and Basic Service Set Identifier (BSSID), a particular time of | |||
(BSSID), a particular time of day, or a preset time duration. | day, or a preset time duration. | |||
3. Zero trust: In another environment, a device may randomize its | 3. Zero trust: A device may randomize its MAC address with any local | |||
MAC address with any local entity reachable through the AP. It | entity reachable through the AP. It may generate a temporary MAC | |||
may generate a temporary MAC address to each of them. That | address to each of them. That temporary MAC address may or may | |||
temporary MAC address may or may not be the same for different | not be the same for different services. | |||
services. | ||||
5. Environments | 5. Environments | |||
The trust relationship depends on the relationship between the user | The trust relationship depends on the relationship between the user | |||
of a personal device and the operator of a network service that the | of a personal device and the operator of a network service that the | |||
personal device may use. It is useful to observe the typical trust | personal device may use. It is useful to observe the typical trust | |||
structure of common environments: | structure of common environments: | |||
(A) Residential settings under the control of the user: This is a | (A) Residential settings under the control of the user: This is a | |||
typical home network with Wi-Fi in the LAN and Internet in the | typical home network with Wi-Fi in the LAN and Internet in the | |||
skipping to change at line 488 ¶ | skipping to change at line 486 ¶ | |||
and with the network elements. Note that "Full trust" in this | and with the network elements. Note that "Full trust" in this | |||
context is referring to the MAC address persistency. It does | context is referring to the MAC address persistency. It does | |||
not extend to full trust between applications or devices. The | not extend to full trust between applications or devices. The | |||
device trusts the access point and all Layer 2 domain entities | device trusts the access point and all Layer 2 domain entities | |||
beyond the access point, where the Wi-Fi transmissions can be | beyond the access point, where the Wi-Fi transmissions can be | |||
detected, but there is no guarantee that an eavesdropper will | detected, but there is no guarantee that an eavesdropper will | |||
not observe the communications. As such, even in this | not observe the communications. As such, even in this | |||
environment, it is common to assume that attackers may still be | environment, it is common to assume that attackers may still be | |||
able to monitor unencrypted information such as MAC addresses. | able to monitor unencrypted information such as MAC addresses. | |||
If a device decides to not fully trust the network, it might | If a device decides to not fully trust the network, it might | |||
apply any necessary policy to protect its identity. Most | apply any necessary policy to protect its identity. Most users | |||
devices in the network only require simple connectivity so that | connecting to a residential network only expect simple Internet | |||
the network services are simple. For network support, it is | connectivity services, so the network services are simple. If | |||
also simple. It is usually related to Internet connectivity. | users have issues connecting to the network or accessing the | |||
Internet, they expect limited to no technical support. | ||||
(B) Managed residential settings: Examples of this type of | (B) Managed residential settings: Examples of this type of | |||
environment include shared living facilities and other | environment include shared living facilities and other | |||
collective environments where an operator manages the network | collective environments where an operator manages the network | |||
for the residents. The OTA exposure is similar to (A). The | for the residents. The OTA exposure is similar to (A). The | |||
operator may be requested to provide IT support to the residents | operator may be requested to provide IT support to the residents | |||
and may need to identify device activity in real time or analyze | and may need to identify device activity in real time or analyze | |||
logs. The infrastructure is shared and covers a larger area | logs. The infrastructure is shared and covers a larger area | |||
than in (A); residents may connect to the network from different | than in (A); residents may connect to the network from different | |||
locations. For example, they may regularly connect to the | locations. For example, they may regularly connect to the | |||
skipping to change at line 593 ¶ | skipping to change at line 592 ¶ | |||
Different network environments provide different levels of network | Different network environments provide different levels of network | |||
services, from simple to complex. At its simplest level, a network | services, from simple to complex. At its simplest level, a network | |||
can provide a wireless connecting device with basic IP communication | can provide a wireless connecting device with basic IP communication | |||
service (e.g., DHCPv4 [RFC2131] or Stateless Address | service (e.g., DHCPv4 [RFC2131] or Stateless Address | |||
Autoconfiguration (SLAAC) [RFC4862]) and an ability to connect to the | Autoconfiguration (SLAAC) [RFC4862]) and an ability to connect to the | |||
Internet (e.g., DNS service or relay and routing in and out through a | Internet (e.g., DNS service or relay and routing in and out through a | |||
local gateway). The network can also offer more advanced services, | local gateway). The network can also offer more advanced services, | |||
such as managed instant messaging service, file storage, printing, | such as managed instant messaging service, file storage, printing, | |||
and/or local web service. Larger and more complex networks can also | and/or local web service. Larger and more complex networks can also | |||
incorporate more advanced services, from AAA to AR/VR applications. | incorporate more advanced services, from AAA to Augmented Reality | |||
To the network, its top priority is to provide the best quality of | (AR) or Virtual Reality (VR) applications. To the network, its top | |||
experience to its users. Often the network contains policies that | priority is to provide the best quality of experience to its users. | |||
help to make a forwarding decision based on the network conditions, | Often the network contains policies that help to make a forwarding | |||
the device, and the user identity associated to the device. For | decision based on the network conditions, the device, and the user | |||
example, in a hospital private network, the network may contain a | identity associated to the device. For example, in a hospital | |||
policy to give highest priority to doctors' Voice-Over-IP packets. | private network, the network may contain a policy to give highest | |||
In another example, an enterprise network may contain a policy to | priority to doctors' Voice-Over-IP packets. In another example, an | |||
allow applications from a group of authenticated devices to use | enterprise network may contain a policy to allow applications from a | |||
Explicit Congestion Notification (ECN) [RFC3168] for congestion and/ | group of authenticated devices to use Explicit Congestion | |||
or Differentiated Services Code Point (DSCP) [RFC8837] for | Notification (ECN) [RFC3168] for congestion and/or Differentiated | |||
classification to signal the network for a specific network policy. | Services Code Point (DSCP) [RFC8837] for classification to signal the | |||
In this configuration, the network is required to associate the data | network for a specific network policy. In this configuration, the | |||
packets to an identity to validate the legitimacy of the marking. | network is required to associate the data packets to an identity to | |||
Before RCM, many network systems used a MAC address as a persistent | validate the legitimacy of the marking. Before RCM, many network | |||
identity to create an association between user and device. After | systems used a MAC address as a persistent identity to create an | |||
implementing RCM, the association is broken. | association between user and device. After implementing RCM, the | |||
association is broken. | ||||
6.1. Device Identification and Associated Problems | 6.1. Device Identification and Associated Problems | |||
Wireless access points and controllers use the MAC address to | Wireless access points and controllers use the MAC address to | |||
validate the device connection context, including protocol | validate the device connection context, including protocol | |||
capabilities, confirmation that authentication was completed, quality | capabilities, confirmation that authentication was completed, quality | |||
of service or security profiles, and encryption keying material. | of service or security profiles, and encryption keying material. | |||
Some advanced access points and controllers also include upper layer | Some advanced access points and controllers also include upper layer | |||
functions whose purpose is covered below. A device changing its MAC | functions whose purpose is covered below. A device changing its MAC | |||
address, without another recorded device identity, would cause the | address, without another recorded device identity, would cause the | |||
skipping to change at line 698 ¶ | skipping to change at line 698 ¶ | |||
disrupt the stability of these mappings for these peers if the change | disrupt the stability of these mappings for these peers if the change | |||
occurs within the caching period. Note that this behavior is against | occurs within the caching period. Note that this behavior is against | |||
standard operation and existing privacy recommendations. | standard operation and existing privacy recommendations. | |||
Implementations must avoid changing the MAC address while maintaining | Implementations must avoid changing the MAC address while maintaining | |||
the previously assigned IP address without consulting the network. | the previously assigned IP address without consulting the network. | |||
Routers keep track of which MAC address is on which interface so that | Routers keep track of which MAC address is on which interface so that | |||
they can form the proper Data Link header when forwarding a packet to | they can form the proper Data Link header when forwarding a packet to | |||
a segment where MAC addresses are used. MAC address randomization | a segment where MAC addresses are used. MAC address randomization | |||
can cause MAC address cache exhaustion but also the need for frequent | can cause MAC address cache exhaustion but also the need for frequent | |||
Address Resolution Protocol (ARP), Reverse Address Resolution | Address Resolution Protocol (ARP) [RFC826], Reverse Address | |||
Protocol (RARP) [RFC826], and Neighbor Solicitation and Neighbor | Resolution Protocol (RARP) [RFC903], and Neighbor Solicitation and | |||
Advertisement [RFC4861] exchanges. | Neighbor Advertisement [RFC4861] exchanges. | |||
In residential settings (environment type A in Section 5), policies | In residential settings (environment type A in Section 5), policies | |||
can be in place to control the traffic of some devices (e.g., | can be in place to control the traffic of some devices (e.g., | |||
parental control or blocklist filters). These policies are often | parental control or blocklist filters). These policies are often | |||
based on the device's MAC address. MAC address randomization removes | based on the device MAC address. MAC address randomization removes | |||
the possibility for such control. | the possibility for such control. | |||
In residential settings (environment type A) and in enterprises | In residential settings (environment type A) and in enterprises | |||
(environment types D and E), device recognition and ranging may be | (environment types D and E), device recognition and ranging may be | |||
used for IoT-related functionalities (e.g., door unlock, preferred | used for IoT-related functionalities (e.g., door unlock, preferred | |||
light and temperature configuration, etc.) These functions often | light and temperature configuration, etc.) These functions often | |||
rely on the detection of the device's wireless MAC address. MAC | rely on the detection of the device wireless MAC address. MAC | |||
address randomization breaks the services based on such models. | address randomization breaks the services based on such models. | |||
In managed residential settings (environment type B) and in | In managed residential settings (environment type B) and in | |||
enterprises (environment types D and E), the network operator is | enterprises (environment types D and E), the network operator is | |||
often requested to provide IT support. With MAC address | often requested to provide IT support. With MAC address | |||
randomization, real-time support is only possible if the user can | randomization, real-time support is only possible if the user can | |||
provide the current MAC address. Service improvement support is not | provide the current MAC address. Service improvement support is not | |||
possible if the MAC address that the device had at the time of the | possible if the MAC address that the device had at the time of the | |||
reported issue (in the past) is not known at the time the issue is | reported issue (in the past) is not known at the time the issue is | |||
reported. | reported. | |||
In industrial environments, policies are associated with each group | In managed enterprise environments, policies are associated with each | |||
of objects, including IoT devices. MAC address randomization may | group of objects, including IoT devices. MAC address randomization | |||
prevent an IoT device from being identified properly and thus lead to | may prevent an IoT device from being identified properly and thus | |||
network quarantine and disruption of operations. | lead to network quarantine and disruption of operations. | |||
7. IANA Considerations | 7. IANA Considerations | |||
This document has no IANA actions. | This document has no IANA actions. | |||
8. Security Considerations | 8. Security Considerations | |||
Privacy considerations are discussed throughout this document. | Privacy considerations are discussed throughout this document. | |||
9. Informative References | 9. Informative References | |||
skipping to change at line 761 ¶ | skipping to change at line 761 ¶ | |||
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 Networks--Specific | Systems - Local and Metropolitan Area Networks--Specific | |||
Requirements - Part 11: Wireless LAN Medium Access Control | Requirements - Part 11: Wireless LAN Medium Access Control | |||
(MAC) and Physical Layer (PHY) Specifications", IEEE | (MAC) and Physical Layer (PHY) Specifications", IEEE | |||
Std 802.11-2020, DOI 10.1109/IEEESTD.2021.9363693, 26 | Std 802.11-2020, DOI 10.1109/IEEESTD.2021.9363693, 26 | |||
February 2021, | February 2021, | |||
<https://ieeexplore.ieee.org/document/9363693>. | <https://ieeexplore.ieee.org/document/9363693>. | |||
[IEEE_802.11bh] | [IEEE_802.11bh] | |||
IEEE, "IEEE Draft 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 Networks--Specific | Systems Local and Metropolitan Area Networks--Specific | |||
Requirements - Part 11: Wireless LAN Medium Access Control | Requirements - Part 11: Wireless LAN Medium Access Control | |||
(MAC) and Physical Layer (PHY) Specifications Amendment 8 | (MAC) and Physical Layer (PHY) Specifications Amendment 1: | |||
: Operation with Randomized and Changing MAC Addresses", | Operation with Randomized and Changing MAC Addresses", | |||
IEEE P802.11bh/D1.0, 19 July 2023, | IEEE Std 802.11bh-2024, DOI 10.1109/IEEESTD.2025.11023005, | |||
<https://ieeexplore.ieee.org/document/10214483>. | 3 June 2025, | |||
<https://ieeexplore.ieee.org/document/11023005>. | ||||
[IEEE_802.11i] | [IEEE_802.11i] | |||
IEEE, "IEEE 802.11i-2004 - Wireless LAN Medium Access | IEEE, "IEEE 802.11i-2004 - Wireless LAN Medium Access | |||
Control (MAC) and Physical Layer (PHY) specifications: | Control (MAC) and Physical Layer (PHY) specifications: | |||
Amendment 6: Medium Access Control (MAC) Security | Amendment 6: Medium Access Control (MAC) Security | |||
Enhancements", IEEE Std 802.11i-2004, | Enhancements", IEEE Std 802.11i-2004, | |||
DOI 10.1109/10.1109/IEEESTD.2004.94585, 24 July 2004, | DOI 10.1109/10.1109/IEEESTD.2004.94585, 24 July 2004, | |||
<https://ieeexplore.ieee.org/document/1318903>. | <https://ieeexplore.ieee.org/document/1318903>. | |||
[IEEE_802.1X] | [IEEE_802.1X] | |||
skipping to change at line 907 ¶ | skipping to change at line 908 ¶ | |||
the hospitality industry, which includes but is not limited to | the hospitality industry, which includes but is not limited to | |||
hotels, stadiums, restaurants, concert halls, and hospitals. | hotels, stadiums, restaurants, concert halls, and hospitals. | |||
A.2. OpenRoaming | A.2. OpenRoaming | |||
In order to alleviate some of the limitations listed above, the | In order to alleviate some of the limitations listed above, the | |||
Wireless Broadband Alliance (WBA) OpenRoaming standard introduces an | Wireless Broadband Alliance (WBA) OpenRoaming standard introduces an | |||
intermediate trusted relay between local venues (places where some | intermediate trusted relay between local venues (places where some | |||
public Wi-Fi is available) and sources of identity [WBA-OPENROAMING]. | public Wi-Fi is available) and sources of identity [WBA-OPENROAMING]. | |||
The federation structure extends the type of authorities that can be | The federation structure extends the type of authorities that can be | |||
used as identity sources (compared to the traditional enterprise- | used as identity sources (compared to the typical enterprise-based | |||
based IEEE 802.1X scheme for Wi-Fi [IEEE_802.1X]) and facilitates the | IEEE 802.1X scheme for Wi-Fi [IEEE_802.1X]) and facilitates the | |||
establishment of trust between local networks and an identity | establishment of trust between local networks and an identity | |||
provider. Such a procedure increases the likelihood that one or more | provider. Such a procedure increases the likelihood that one or more | |||
identity profiles for the user or the device will be recognized by a | identity profiles for the user or the device will be recognized by a | |||
local network. At the same time, authentication does not occur to | local network. At the same time, authentication does not occur to | |||
the local network. This may offer the possibility for the user or | the local network. This may offer the possibility for the user or | |||
the device to keep their identity obfuscated from the local network | the device to keep their identity obfuscated from the local network | |||
operator, unless that operator specifically expresses the requirement | operator, unless that operator specifically expresses the requirement | |||
to disclose such identity (in which case the user has the option to | to disclose such identity (in which case the user has the option to | |||
accept or decline the connection and associated identity exposure). | accept or decline the connection and associated identity exposure). | |||
skipping to change at line 950 ¶ | skipping to change at line 951 ¶ | |||
It is worth noting that, as part of collaborations between the IETF | It is worth noting that, as part of collaborations between the IETF | |||
MADINAS Working Group and WBA around OpenRoaming, some RADIUS privacy | MADINAS Working Group and WBA around OpenRoaming, some RADIUS privacy | |||
enhancements have been proposed in the IETF RADEXT Working Group. | enhancements have been proposed in the IETF RADEXT Working Group. | |||
For instance, [RADIUS] describes good practices in the use of | For instance, [RADIUS] describes good practices in the use of | |||
Chargeable-User-Identity (CUI) between different visited networks, | Chargeable-User-Identity (CUI) between different visited networks, | |||
making it better suited for public Wi-Fi and hospitality use cases. | making it better suited for public Wi-Fi and hospitality use cases. | |||
A.3. Proprietary RCM Schemes | A.3. Proprietary RCM Schemes | |||
Most client device operating system vendors offer RCM schemes that | Most client OS vendors offer RCM schemes that are enabled by default | |||
are enabled by default (or easy to enable) on client devices. With | (or easy to enable) on client devices. With these schemes, the | |||
these schemes, the device changes its MAC address, when not | device changes its MAC address, when not associated, after having | |||
associated, after having used a given MAC address for a semi-random | used a given MAC address for a semi-random duration window. These | |||
duration window. These schemes also allow for the device to manifest | schemes also allow for the device to manifest a different MAC address | |||
a different MAC address in different SSIDs. | in different SSIDs. | |||
Such a randomization scheme enables the device to limit the duration | Such a randomization scheme enables the device to limit the duration | |||
of exposure of a single MAC address to observers. In | of exposure of a single MAC address to observers. In | |||
[IEEE_802.11bh], MAC address randomization is not allowed during a | [IEEE_802.11bh], MAC address randomization is not allowed during a | |||
given association session, and MAC address randomization can only | given association session, and MAC address randomization can only | |||
occur through disconnection and reconnection. Authentication may | occur through disconnection and reconnection. Authentication may | |||
then need to reoccur, with an associated cost of service disruption | then need to reoccur, with an associated cost of service disruption | |||
and additional load on the venue and identity provider | and additional load on the venue and identity provider | |||
infrastructure, directly proportional to the frequency of the | infrastructure, directly proportional to the frequency of the | |||
randomization. The scheme is also not intended to protect from the | randomization. The scheme is also not intended to protect from the | |||
End of changes. 25 change blocks. | ||||
104 lines changed or deleted | 105 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |