Skip to main content

Randomized and Changing MAC Address Use Cases
draft-ietf-madinas-use-cases-09

Document Type Active Internet-Draft (madinas WG)
Authors Jerome Henry , Yiu Lee
Last updated 2024-03-14 (Latest revision 2024-02-29)
Replaces draft-henry-madinas-framework
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Informational
Formats
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-madinas-use-cases-09
Internet Engineering Task Force                                 J. Henry
Internet-Draft                                             Cisco Systems
Intended status: Informational                                    Y. Lee
Expires: 1 September 2024                                        Comcast
                                                        29 February 2024

             Randomized and Changing MAC Address Use Cases
                    draft-ietf-madinas-use-cases-09

Abstract

   To limit the privacy issues created by the association between a
   device, its traffic, its location and its user, client and client OS
   vendors have started implementing MAC address rotation.  When such a
   rotation happens, some in-network states may break, which may affect
   network connectivity and user experience.  At the same time, devices
   may continue using other stable identifiers, defeating the MAC
   rotation purposes.  This document lists various network environments
   and a set of network services that may be affected by such rotation.
   This document then examines settings where the user experience may be
   affected by in-network state disruption.  Last, this document
   examines solutions to maintain user privacy while preserving user
   quality of experience and network operation efficiency.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 1 September 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Henry & Lee             Expires 1 September 2024                [Page 1]
Internet-Draft                RCM Use Cases                February 2024

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  MAC Address as Identity: User vs. Device  . . . . . . . . . .   3
   3.  The Actors: Network Functional Entities and Human Entities  .   6
     3.1.  Network Functional Entities . . . . . . . . . . . . . . .   6
     3.2.  Human-related Entities  . . . . . . . . . . . . . . . . .   7
   4.  Trust Degrees . . . . . . . . . . . . . . . . . . . . . . . .   9
   5.  Environments  . . . . . . . . . . . . . . . . . . . . . . . .   9
   6.  Network Services  . . . . . . . . . . . . . . . . . . . . . .  11
     6.1.  Device Identification and Associated Problems . . . . . .  11
     6.2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . .  13
   7.  Considerations  . . . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  IANA Considerations . . . . . . . . . . . . . . . . . . .  15
     7.2.  Security Considerations . . . . . . . . . . . . . . . . .  15
   8.  Informative References  . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   IEEE 802.11 (or 'Wi-Fi') [IEEE_802.11] technology has revolutionized
   communications and become the preferred, and sometimes the only
   technology used by devices such as laptops, tablets and Internet-of-
   Thing (IoT) devices.  Wi-Fi is an over-the-air technology, attackers
   with surveillance equipment can "monitor" WLAN packets and track the
   activity of WLAN devices.  Once the association between a device and
   its user is made, identifying the device and its activity is
   sufficient to deduce information about what the user is doing,
   without the user consent.

   To reduce the risks of correlation between a device activity and its
   owner's, multiple client and client OS vendors have started to
   implement Randomized and Changing MAC addresses (RCM).  By
   randomizing the MAC address, the persistent association between a
   given traffic flow and a single device is made more difficult,
   assuming no other visible unique identifiers or stable patterns are
   in use.  When individual devices are no longer easily identifiable,
   it also becomes difficult to associate a series of network flows with
   a particular individual using one particular device.

Henry & Lee             Expires 1 September 2024                [Page 2]
Internet-Draft                RCM Use Cases                February 2024

   However, such address change may affect the user experience and the
   efficiency of legitimate network operations.  For a long time,
   network designers and implementers relied on the assumption that a
   given machine, in a network implementing [IEEE_802] technologies,
   would be represented by a unique network MAC address that would not
   change over time, despite the existence of tools to flush out the MAC
   address to bypass some network policies.  When this assumption is
   broken, network communication may be disrupted.  For example,
   sessions established between the end-device and network services may
   break and packets in transit may suddenly be lost.  If multiple
   clients implement fast-paced RCM rotations without coordination with
   network services, these network services may become over-solicited.

   At the same time, some network services rely on the end station (as
   defined by the [IEEE_802] Standard) providing an identifier, which
   can be the MAC address or another value.  If the client implements
   MAC rotation but continues sending the same static identifier, then
   the association between a stable identifier and the station continues
   despite the RCM scheme.  There may be environments where such
   continued association is desirable, but others where the user privacy
   has more value than any continuity of network service state.

   There is a need to enumerate services that may be affected by RCM,
   and evaluate possible solutions to maintain both the quality of user
   experience and network efficiency while RCM happens and user privacy
   is reinforced.  This document presents such assessment and
   recommendations.

2.  MAC Address as Identity: User vs. Device

   Any device member of a network implementing IEEE 802 technologies
   includes several operating layers.  Among them, the Media Access
   Control (MAC) layer defines rules to control how the device accesses
   the shared 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 identified, either as the target destination of a message, or
   as the source of a message (and thus the target destination of the
   answer).  Initially intended as a 48-bit (6 octets) value in the
   first versions of the [IEEE_802] Standard, other Standards under the
   [IEEE_802] umbrella then allowed this address to take an extended
   format of 64 bits (8 octets), thus enabling a larger number of MAC
   addresses to coexist as the 802 technologies became widely adopted.

   Regardless of the address length, different networks have different
   needs, and several bits of the first octet are reserved for specific
   purposes.  In particular, the first bit is used to identify the
   destination address either as an individual (bit set to 0) or a group
   address (bit set to 1).  The second bit, called the Universally or

Henry & Lee             Expires 1 September 2024                [Page 3]
Internet-Draft                RCM Use Cases                February 2024

   Locally Administered (U/L) Address Bit, indicates whether the address
   has been assigned by a local or universal administrator.  Universally
   administered addresses have this bit set to 0.  If this bit is set to
   1, the entire address (i.e., 48 bits) has been locally administered
   (clause 8.4 of [IEEE_802]).

   The intent of this provision is important for the present document.
   The [IEEE_802] Standard recognized that some devices may never change
   their attachment network and thus would not need a globally unique
   MAC address to prevent address collision against any other device in
   any other network.  To accommodate for this requirement, the second
   bit of the MAC address first octet was designed to express whether
   the address was intended to be globally unique, or locally unique.
   The address allocation method was not defined in the Standard in this
   later case, but the same clause defined that an address should be
   unique so as to avoid collision with any other device attached to the
   same network.

   It is also important to note that the purpose of the Universal
   version of the address was to avoid collisions and confusion, as any
   machine could connect to any network, and each machine needs to
   determine if it is the intended destination of a message or its
   response.  Clause 8.4 of [IEEE_802] reminds network designers and
   operators that all potential members of a network need to have a
   unique identifier in that network (if they are going to coexist in
   the network without confusion on which machine is the source or
   destination or any message).  The advantage of a universal address is
   that a node with such an address can be attached to any Local Area
   Network (LAN) in the world with an assurance that its address is
   unique in that network.

   With the rapid development of wireless technologies and mobile
   devices, this scenario became very common.  With a vast majority of
   networks implementing [IEEE_802] radio technologies at the access,
   the MAC address of a wireless device can appear anywhere on the
   planet and collisions should still be avoided.  However, the same
   evolution brought the distinction between two types of devices that
   the [IEEE_802] Standard generally referred to as ‘nodes in a
   network’. Their definition is found in the [IEEE_802E] Recommended
   Practice stated in Section 6.2 of [IEEE_802].  One type is a shared
   service device, which functions are used by a number of people large
   enough that the device itself, its functions or its traffic cannot be
   associated with a single or small group of people.  Examples of such
   devices include switches in a dense network, IEEE 802.11 (WLAN)
   access points in a crowded airport, task-specific (e.g., barcode
   scanners) devices, etc.  Another type is a personal device, which is
   a machine, a node, primarily used by a single person or small group
   of people, and so that any identification of the device or its

Henry & Lee             Expires 1 September 2024                [Page 4]
Internet-Draft                RCM Use Cases                February 2024

   traffic can also be associated to the identification of the primary
   user or their traffic.  Quite naturally, the identification of the
   device is trivial if the device expresses a universally unique MAC
   address.  Then, the detection of elements directly or indirectly
   identifying the user of the device (Personally Identifiable
   Information, or PII) is sufficient to tie the universal MAC address
   to a user.  Then, any detection of traffic that can be associated to
   the device becomes also associated with the known user of that device
   (Personally Correlated Information, or PCI).

   This possible identification or association presents a serious
   privacy issue, especially with wireless technologies.  For most of
   them, and in particular for 802.11, the source and destination MAC
   addresses are not encrypted even in networks that implement
   encryption (so that each machine can easily detect if it is the
   intended target of the message before attempting to decrypt its
   content, and also identify the transmitter, so as to use the right
   decryption key when multiple unicast keys are in effect).

   This identification of the user associated to a node was clearly not
   the intent of the 802 MAC address.  A logical solution to remove this
   association is to use a locally administered address instead, and
   change the address in a fashion that prevents a continuous
   association between one MAC address and some PII.  However, other
   network devices on the same LAN implementing a MAC layer also expect
   each device to be associated to a 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 machine is attempting to
   communicate with them.  Additionally, multiple layers implemented at
   upper OSI layers have been designed with the assumption that each
   node on the LAN, using these services, would have a MAC address that
   would stay the same over time, and that this document calls a
   'persistent' MAC address.  This assumption sometimes adds to the PII
   confusion, for example in the case of Authentication, Association and
   Accounting (AAA) services authenticating the user of a machine and
   associating the authenticated user to the device MAC address.  Other
   services solely focus on the machine (e.g., DHCP), but still expect
   each device to use a persistent MAC address, for example to re-assign
   the same IP address to a returning device.  Changing the MAC address
   may disrupt these services.

Henry & Lee             Expires 1 September 2024                [Page 5]
Internet-Draft                RCM Use Cases                February 2024

3.  The Actors: Network Functional Entities and Human Entities

   The risk of service disruption is thus weighted against the privacy
   benefits.  However, the plurality of actors involved in the exchanges
   tends to blur the boundaries of what privacy should be protected
   against.  It might therefore be useful to list the actors associated
   to the network exchanges, either because they actively participate to
   these exchanges, or because they can observe them.  Some actors are
   functional entities, some others are humans (or related) entities.

3.1.  Network Functional Entities

   Network communications based on IEEE 802 technologies commonly rely
   on station identifiers based on a MAC address.  This MAC address is
   utilized by several types of network functional entitities (entities,
   like applications or devices, that provide a service related to
   network operations).

   Wireless access network infrastructure devices (e.g., WLAN access
   points or controllers): these devices participate in IEEE 802 LAN
   operations.  As such, they need to identify each machine as a source
   or destination so as to successfully continue exchanging frames.
   Part of the identification includes recording, and adapting to,
   devices communication capabilities (e.g., support for specific
   protocols).  As a device changes its network attachment (roams) from
   one access point to another, the access points can exchange
   contextual information (e.g., device MAC, keying material) allowing
   the device session to continue seamlessly.  These access points can
   also inform devices further in the wired network about the roam, to
   ensure that OSI model Layer 2 frames are redirected to the new device
   access point.

   Other network devices operating at the MAC layer: many wireless
   network access devices (e.g., IEEE 802.11 access points) are
   conceived as Layer 2 devices, and as such they bridge a frame from
   one medium (e.g., IEEE 802.11 or Wi-Fi) to another (e.g., IEEE 802.3
   or Ethernet).  This means that a wireless device MAC address often
   exists on the wire beyond the wireless access device.  Devices
   connected to this wire also implement IEEE 802 technologies, and as
   such operate on the expectation that each device is associated to a
   MAC address that persists for the duration of continuous exchanges.
   For example, switches and bridges associate MAC addresses to
   individual ports (so as to know which port to send a frame intended
   for a particular MAC address).  Similarly, authentication,
   authorization and accounting (AAA) services can validate the identity
   of a device and use the device MAC address as a first pointer to the
   device identity (before operating further verification).  Similarly,
   some networking devices offer Layer-2 filtering policies that may

Henry & Lee             Expires 1 September 2024                [Page 6]
Internet-Draft                RCM Use Cases                February 2024

   rely on the connected MAC addresses. 802.1X-enabled devices may also
   selectively block the data portion of a port until a connecting
   device is authenticated.  These services then use the MAC address as
   a first pointer to the device identity to allow or block data
   traffic.  This list is not exhaustive.  Multiple services are defined
   for 802.3 networks, and multiple services defined by the IEEE 802.1
   working group are also applicable to 802.3 networks.  Wireless access
   points may also connect to other mediums than 802.3, which also
   implements mechanism under the umbrella of the general 802 Standard,
   and therefore expect the unique and persistent association of a MAC
   address to a device.

   Network devices operating at upper layers: some network devices
   provide functions and services above the MAC layer.  Some of them
   also operate a MAC layer function: for example, routers provide IP
   forwarding services, but rely on the device MAC address to create the
   appropriate frame structure.  Other devices and services operate at
   upper layers, but also rely upon the 802 principle of unique MAC-to-
   device mapping.  For example, DHCP services with IPv4 commonly
   provide a single IP address per MAC address (they do not assign more
   than one IP address per MAC address, and assign a new IP address to
   each new requesting MAC address).  ARP and reverse-ARP services
   commonly expect that, once an IP-to-MAC mapping has been established,
   this mapping is valid and unlikely to change for the cache lifetime.
   DHCP services with IPv6 commonly do not assign the same IP address to
   two different requesting MAC addresses.  Hybrid services, such as
   EoIP, also assume stability of the device-to-MAC-and-IP mapping for
   the duration of a given session.

3.2.  Human-related Entities

   Networks do no operate without humans actively involved at one or
   more points of the network lifecycle.  Humans may actively
   participate to the network structure and operations, or be observers.

   Over the air (OTA) observers: as the transmitting or receiving MAC
   address is usually not encrypted in wireless 802-technologies
   exchanges, and as any protocol-compatible device in range of the
   signal can read the frame header, OTA observers are able to read
   individual transmissions MAC addresses.  Some wireless technologies
   also support techniques to establish distances or positions, allowing
   the observer, in some cases, to uniquely associate the MAC address to
   a physical device and it associated location.  It can happen that an
   OTA observer has a legitimate reason to monitor a particular device,
   for example for IT support operations.  However, it is difficult to
   control if another actor also monitors the same station with the goal
   of obtaining PII or PCI.

Henry & Lee             Expires 1 September 2024                [Page 7]
Internet-Draft                RCM Use Cases                February 2024

   Wireless access network operators: some wireless access networks are
   only provided devices matching specific requirements, such as device
   type (e.g., IoT-only networks, factory operational networks).
   Therefore, operators can attempt to identify the devices (or the
   users) connecting to the networks under their care.  They can use the
   MAC address to represent an identified device.

   Network access providers: wireless access networks are often
   considered beyond the first 2 layers of the OSI model.  For example,
   several regulatory or legislative bodies can group all OSI layers
   into their functional effect of allowing network communication
   between machines.  In this context, entities operating access
   networks can see their liability associated to the activity of
   devices communicating through the networks that these entities
   operate.  In other contexts, operators assign network resources based
   on contractual conditions (e.g., fee, bandwidth fair share).  In
   these scenarios, these operators may attempt to identify the devices
   and the users of their networks.  They can use the MAC address to
   represent an identified device.

   Over the wire internal (OTWi) observers: because the device wireless
   MAC address continues to be present over the wire if the
   infrastructure connection device (e.g., access point) functions as a
   Layer 2 bridge, observers may be positioned over the wire and read
   transmission MAC addresses.  Such capability supposes that the
   observer has access to the wired segment of the broadcast domain
   where the frames are exchanged.  In most networks, such capability
   requires physical access to an infrastructure wired device in the
   broadcast domain (e.g., switch closet), and is therefore not
   accessible to all.

   Over the wired external (OTWe) observers: beyond the broadcast
   domain, frames headers are removed by a routing device, and a new
   Layer 2 header is added before the frame is transmitted to the next
   segment.  The personal device MAC address is not visible anymore,
   unless a mechanism copies the MAC address into a field that can be
   read while the packet travels onto the next segment (e.g., pre-
   [RFC4941] and pre- [RFC7217] IPv6 addresses built from the MAC
   address).  Therefore, unless this last condition exists, OTWe
   observers are not able to see the device MAC address.

Henry & Lee             Expires 1 September 2024                [Page 8]
Internet-Draft                RCM Use Cases                February 2024

4.  Trust Degrees

   The surface of PII exposures that can drive MAC address randomization
   depends on (1) the environment where the device operates, (2) the
   presence and nature of other devices in the environment, and (3) the
   type of network the device is communicating through.  Therefore, a
   device can express an identifier (such as a MAC address) that can
   persist over time if trust with the environment is established, or
   that can be temporal if an identifier is required for a service in an
   environment where trust has not been established.  Trust is not a
   binary currency.  Thus it is useful to distinguish what trust a
   personal device may establish with the different entities at play in
   a network domain where a MAC address may be visible:

   1.  Full trust: there are environments where a personal device
       establishes a trust relationship and can share a persistent
       device identity with the access network devices (e.g., access
       point and WLAN Controller), the services beyond the access point
       in the L2 broadcast domain (e.g., DHCP, AAA), without fear that
       observers or network actors may access PII that would not be
       shared willingly.  The personal device (or its user) also has
       confidence that its identity is not shared beyond the L2
       broadcast domain boundary.

   2.  Selective trust: in other environments, a device may not be
       willing to share a persistent identity with some elements of the
       Layer 2 broadcast domain, but may be willing to share a
       persistent identity with other elements.  That persistent
       identity may or may not be the same for different services.

   3.  Zero trust: in other environments, a device may not be willing to
       share any persistent identity with any local entity reachable
       through the AP, and may express a temporal identity to each of
       them.  That temporal identity may or not be the same for
       different services.

5.  Environments

   The trust relationship depends on the relationship between the user
   of a personal device and the operator of a network service that the
   personal device may use.  Thus, it is useful to observe the typical
   trust structure of common environments:

   A.  Residential settings under the control of the user: this is
       typical of a home network with Wi-Fi in the LAN and Internet
       connection.  In this environment, traffic over the Internet does
       not expose the MAC adddress of internal devices if it is not
       copied to another field before routing happens.  The wire segment

Henry & Lee             Expires 1 September 2024                [Page 9]
Internet-Draft                RCM Use Cases                February 2024

       within the broadcast domain is under the control of the user, and
       is therefore usually not at risk of hosting an eavesdropper.
       Full trust is typically established at this level among users and
       with the network elements.  The device trusts the access point
       and all L2 domain entities beyond the access point.  However,
       unless the user has full access control over the physical space
       where the Wi-Fi transmissions can be detected, there is no
       guarantee that an eavesdropper would not be observing the
       communications.  As such, it is common to assume that, even in
       this environment, full trust cannot be achieved.

   B.  Managed residential settings: examples of this type of
       environment include shared living facilities and other collective
       environments where an operator manages the network for the
       residents.  The OTA exposure is similar to that of a home.  A
       number of devices larger than in a standard home may be present,
       and the operator may be requested to provide IT support to the
       residents.  Therefore, the operator may need to identify a device
       activity in real time, but may also need to analyze logs so as to
       understand a past reported issue.  For both activities, a device
       identification associated to the session is needed.  Full trust
       is often established in this environment, at the scale of a
       series of a few sessions, not because it is assumed that no
       eavesdropper would observe the network activity, but because it
       is a common condition for the managed operations.

   C.  Public guest networks: public hotspots, such as in shopping
       malls, hotels, stores, trains stations and airports are typical
       of this environment.  The guest network operator may be legally
       mandated to identify devices or users or may have the option to
       leave all devices and users untracked.  In this environment,
       trust is commonly not established with any element of the L2
       broadcast domain (Zero trust model by default).

   D.  Enterprises (with BYOD): users may be provided with corporate
       devices or may bring their own devices.  The devices are not
       directly under the control of a corporate IT team.  Trust may be
       established as the device joins the network.  Some enterprise
       models will mandate full trust, others, considering the BYOD
       nature of the device, will allow selective trust.

   E.  Managed enterprises: in this environment, users are typically
       provided with corporate devices, and all connected devices are
       managed, for example through a Mobile Device Management (MDM)
       profile installed on the device.  Full trust is created as the
       MDM profile is installed.

Henry & Lee             Expires 1 September 2024               [Page 10]
Internet-Draft                RCM Use Cases                February 2024

6.  Network Services

   Different network environments provide different levels of network
   services, from simple to complex.  At its simplest level, a network
   can provide to a wireless connecting device basic address allocation
   service (DHCP) and an ability to connect to the Internet (e.g., DNS
   service or relay, and routing in and out through a local gateway).
   The network can also offer more advanced services, such as file
   storage, printing or local web service.  Larger and more complex
   networks can also incorporate a multiplicity of more advanced
   services, from authentication (AAA), to quality of experience (QoE)
   monitoring and management.  These services are often accompanied with
   network performance management services.  Different levels of
   services may call for different relationships with the device, or its
   user, identity.  For example, there is usually no need to identify
   the device or its user for a public network to provide a DHCP-sourced
   IP address to a connecting station, or accept a station using its
   self-generated IP address (e.g., using SLAAC [RFC4862] ).  However,
   there may be a need, in an enterprise private network, to identify
   devices in order to provide adapted quality of services (e.g., to
   prioritize identified voice traffic coming from a smartphone over
   keepalive data coming from an IoT endpoint).  The same type of
   network may have a need to limit the effect of IP address spoofing
   and invalid reuse through mechanisms like SAVI [RFC6620] .

6.1.  Device Identification and Associated Problems

   Many network functional devices offering a service to a personal
   device use the device MAC address to maintain service continuity.

   Wireless access points and controllers use the MAC address to
   validate the device connection context, including protocol
   capabilities, confirmation that authentication was completed, QoS or
   security profiles, encryption key material.  Some advanced access
   points and controllers also include upper layer functions which
   purpose is covered below.  A device changing its MAC address, without
   another recorded device identity, would cause the access point and
   the controller to lose these parameters.  As such, the Layer 2
   infrastructure does not know that the device (with its new MAC
   address) is authorized to communicate through the network.  The
   encryption keying material is not identified anymore (causing the
   access point to fail decrypting the device traffic, and fail
   selecting the right key to send encrypted traffic to the device).  In
   short, the entire context needs to be rebuilt, and a new session
   restarted.  The time consumed by this procedure breaks any flow that
   needs continuity or short delay between packets on the device (e.g.,
   real-time audio, video, AR/VR, etc.)  The 802.11i Standard recognizes
   that a device may leave the network and come back after a short time

Henry & Lee             Expires 1 September 2024               [Page 11]
Internet-Draft                RCM Use Cases                February 2024

   window.  As such, the standard suggests that the infrastructure
   should keep the context for a device for a while after the device was
   last seen.  MAC address rotation in this context can cause resource
   exhaustion on the wireless infrastructure and the flush of contexts,
   including for devices that are simply in temporal sleep mode.

   Other devices in the Layer 2 broadcast domain also use the MAC
   address to know whether and where to forward frames.  MAC rotation
   can cause these devices to exhaust their resources, holding in memory
   traffic for a device which port location can no longer be found.  As
   these infrastructure devices also implement a cache (to remember the
   port position of each known device), too frequent MAC rotation can
   cause resources exhaustion and the flush of older MAC addresses,
   including for devices that did not rotate their MAC.  For the RCM
   device, these effects translate into session discontinuity and return
   traffic losses.

   In wireless contexts, 802.1X authenticators rely on the device and
   user identity validation provided by a AAA server to open their port
   to data transmission.  The MAC address is used to verify that the
   device is in the authorized list, and the associated key used to
   decrypt the device traffic.  A change in MAC address causes the port
   to be closed to the device data traffic until the AAA server confirms
   the validity of the new MAC address.  Therefore, MAC rotation can
   interrupt the device traffic, and cause a strain on the AAA server.

   DHCP servers, without a unique identification of the device, lose
   track of which IP address is validly assigned.  Unless the RCM device
   releases the IP address before the rotation occurs, DHCP servers are
   at risk of scope exhaustion, causing new devices (and RCM devices) to
   fail to obtain a new IP address.  Even if the RCM device releases the
   IP address before the rotation occurs, the DHCP server typically
   holds the released IP address for a certain duration, in case the
   leaving MAC would return.  As the DHCP server cannot know if the
   release is due to a temporal disconnection or a MAC rotation, the
   risk of scope address exhaustion exists even in cases where the IP
   address is released.

   Network devices using self-assigned IPv6 addresses (e.g., with SLAAC
   defined in [RFC6620] ) use mechanisms like DAD to and ND to establish
   the association between a target IP address and a MAC address, and
   may cache this association in memory.  Changing the MAC address, even
   through a disconnection-reconnection phase, without changing the IP
   address, may disrupt the stability of these mappings, if the change
   occurs within the caching period.

Henry & Lee             Expires 1 September 2024               [Page 12]
Internet-Draft                RCM Use Cases                February 2024

   Routers keep track of which MAC address is on which interface.  MAC
   rotation can cause MAC address cache exhaustion, but also the need
   for frequent ARP and inverse ARP exchanges.

   In residential settings (environments type A in section Section 5),
   policies can be in place to control the traffic of some devices
   (e.g., parental control or block-list filters).  These policies are
   often based on the device MAC address.  Rotation of the MAC address
   removes the possibility for such control.

   In residential settings (environments type A) and in enterprises
   (environments types D and E), device recognition and ranging may be
   used for IoT-related functionalities (door unlock, preferred light
   and temperature configuration, etc.)  These functions often rely on
   the detection of the device wireless MAC address.  MAC address
   rotation breaks the services based on such model.

   In managed residential settings (environments types B) and in
   enterprises (environments types D and E), the network operator is
   often requested to provide IT support.  With MAC address rotation,
   real time support is only possible if the user is able to provide the
   current MAC address.  Service improvement support is not possible if
   the MAC address that the device had at the (past) time of the
   reported issue is not known at the time the issue is reported.

   In industrial environments, policies are associated to each group of
   objects, including IoT.  MAC address rotation may prevent an IoT
   device from being identified properly, thus leading to network
   quarantine and disruption of operations.

6.2.  Use Cases

   Section 6.1 discusses different environments, different settings, and
   the expectations of users and network operators.  Table 1 summarizes
   the expected degree of trust, network admin responsibility,
   complexity of supported network services and network support
   expectation from the user for the different use cases.

Henry & Lee             Expires 1 September 2024               [Page 13]
Internet-Draft                RCM Use Cases                February 2024

   +=============+==============+=========+==========+=================+
   |  Use Cases  |    Trust     | Network | Network  | Network Support |
   |             |    Degree    |  Admin  | Services |   Expectation   |
   +=============+==============+=========+==========+=================+
   |     Home    |    Medium    |   User  |  Medium  |       Low       |
   +-------------+--------------+---------+----------+-----------------+
   |   Managed   |    Medium    |    IT   |  Medium  |      Medium     |
   | Residential |              |         |          |                 |
   +-------------+--------------+---------+----------+-----------------+
   |    Campus   |    Medium    |    IT   | Complex  |      Medium     |
   |    (BYOD)   |              |         |          |                 |
   +-------------+--------------+---------+----------+-----------------+
   |  Enterprise |     High     |    IT   | Complex  |       High      |
   |    (MDM)    |              |         |          |                 |
   +-------------+--------------+---------+----------+-----------------+
   | Hospitality |     Low      |    IT   |  Simple  |      Medium     |
   +-------------+--------------+---------+----------+-----------------+
   | Public WiFi |     Low      |   ISP   |  Simple  |       Low       |
   +-------------+--------------+---------+----------+-----------------+

                             Table 1: Use Cases

   For example: a Home network is sometimes considered to be trusted and
   safe, where users are not worried about other users (or the home
   network admin) seeing their MAC address.  Users expect a simple
   procedure to connect to their home network.  All devices in the home
   network often trust each other.  The Home network can also include
   many IoT devices, which need to be simple to onboard and manage.  The
   home user commonly expects the network operator to protect the home
   network from external threats (attacks from the Internet).  The home
   user also commonly expects simple policy features (e.g., Parental
   Control).  Most home users do not expect to need networking skills to
   manage their home network.  Such environments may lead to full-trust
   conditions.  However, if the trust commonly exists between allowed
   actors, there is no guarantee that an eavesdropper would not be
   observing the Wi-Fi traffic from outside, thus practically limiting
   the applicability of the trust in most home scenarios.

   On the other end of the spectrum, Public Wi-Fi is often considered to
   be completely untrusted, where a user has no expectation of being
   able to trust other users or any actor inside or outside of the Layer
   2 domain.  Privacy is the number one concern for the user.  Most
   users connecting to Public Wi-Fi only require simple Internet
   connectivity service, and expect only limited to no technical
   support.

7.  Considerations

Henry & Lee             Expires 1 September 2024               [Page 14]
Internet-Draft                RCM Use Cases                February 2024

7.1.  IANA Considerations

   This memo includes no request to IANA.

7.2.  Security Considerations

   Privacy considerations are discussed throughout this document.

8.  Informative References

   [IEEE_802] IEEE 802, "IEEE Std 802 - IEEE Standard for Local and
              Metropolitan Area Networks: Overview and Architecture",
              IEEE 802 , 2014.

   [IEEE_802.11]
              IEEE 802.11 WG - 802 LAN/MAN Standards Committee, "IEEE
              802.11-2020 - Wireless LAN Medium Access Control (MAC) and
              Physical Layer (PHY) Specifications", IEEE 802.11 , 2020.

   [IEEE_802E]
              IEEE 802.1 WG - 802 LAN/MAN architecture, "IEEE 802E-2020
              - IEEE Recommended Practice for Privacy Considerations for
              IEEE 802 Technologies", IEEE 802E , 2020.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <https://www.rfc-editor.org/info/rfc4862>.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
              <https://www.rfc-editor.org/info/rfc4941>.

   [RFC5176]  Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
              Aboba, "Dynamic Authorization Extensions to Remote
              Authentication Dial In User Service (RADIUS)", RFC 5176,
              DOI 10.17487/RFC5176, January 2008,
              <https://www.rfc-editor.org/info/rfc5176>.

   [RFC6620]  Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
              SAVI: First-Come, First-Served Source Address Validation
              Improvement for Locally Assigned IPv6 Addresses",
              RFC 6620, DOI 10.17487/RFC6620, May 2012,
              <https://www.rfc-editor.org/info/rfc6620>.

Henry & Lee             Expires 1 September 2024               [Page 15]
Internet-Draft                RCM Use Cases                February 2024

   [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
              Interface Identifiers with IPv6 Stateless Address
              Autoconfiguration (SLAAC)", RFC 7217,
              DOI 10.17487/RFC7217, April 2014,
              <https://www.rfc-editor.org/info/rfc7217>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Authors' Addresses

   Jerome Henry
   Cisco Systems
   United States of America
   Email: jerhenry@cisco.com

   Yiu L. Lee
   Comcast
   1800 Arch Street
   Philadelphia, PA 19103
   United States of America
   Email: yiu_lee@comcast.com

Henry & Lee             Expires 1 September 2024               [Page 16]