Randomized and Changing MAC Address: Context, Network Impacts, and Use Cases
draft-ietf-madinas-use-cases-19

Thank you to Thomas Fossati for the GENART review.

** Section 2.1
   Additionally, upper protocol
   layers (e.g., application layer) have been designed with the
   assumption that each node on the LAN using these services will have a
   MAC address that would remain consistent over time. 

I am confused by this statement.  What application layer protocols make assumptions about MAC addresses?  I’m thinking of application layer protocols to be SMTP and HTTP.

** Section 3.2
        For
       example, several regulatory or legislative bodies can group all
       OSI layers into their functional effect of allowing network
       communication between machines. 
I don’t understand what this sentence is say.  Can it be clarified?  What are regulatory bodies doing?  Who are there bodies specifically?

** Section 3.2
       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

Why would it have to be a “personal device”?  The behavior described in this section is true of any device which passes traffic through a routing device.

** Section 4.
   1.  Full trust: there is environment 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 layer-2 broadcast domain (e.g., DHCPv4, 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 layer-2
       broadcast domain boundary.

Is an enterprise or industrial environment another example of this “full trust” environment?  Why is there a reference to a “personal device”?

** Section 4.
   2.  Selective trust: in another environment, a device may selectively
       share a persistent identity with some elements of the layer-2
       broadcast domain but not others.

What are examples if different “elements of the layer-2 broadcast domain”?  Since the context is address randomization, is the device sharing different MAC addresses?

** Section 5
       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.

Is this saying “full trust is forced because there are no other options”?

How is this scenario-B practically different from scenario-D?  The user’s device is forced to comply with whatever policies the network operator establishes as a condition of access.

** Section 6
   To the network, its top priority is to provide the
   best Quality of Experience to its users.

Is this statement universally true for the use cases identified in the previous section.  Couldn’t one argue that certain public guest networks are to collect revenue from a captive audience?

** Section 6.1
   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.)
…
As such, the standard suggests that the
   infrastructure should keep the context for a device for a while after
   the device was last seen.

Could more be said about the notional cost/resource impact of RCM “breaking flows”?  Doesn’t this presuppose some number of devices rapidly cycling MACs?  Let’s assume a coffee shop scenario – how many times is one expecting a device to change its MAC while having an active flow?  How long is the infrastructure keeping all of these MAC to cause resource exhaustion?

** Section 6.1
   Aggressive MAC randomization from many devices in
   a short time interval may cause the layer-2 switch to exhaust its
   resources, holding in memory traffic for a device whose port location
   can no longer be found.

What is “aggressive MAC randomization”?  Is that every day?  Hour?

** Section 6.1
   For the RCM device, these effects translate into session
   discontinuity and return traffic losses.

From the user perspective, how significant of a problem is this?  Isn’t there some tradeoff to be made about occasional traffic losses for gained privacy?

** Section 6.1
   In wireless contexts, 802.1X [IEEE_802.1X] authenticators rely on the
   device and user identity validation provided by an AAA server to
   change the interface from a blocking state to a forwarding state.
   The MAC address is used to verify that the device is in the
   authorized list, and to retrieve 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.  Consequently, MAC address
   randomization can disrupt the device traffic and strain the AAA
   server.

Is it common to deploy 802.1X in scenarios where heavy RCM is expected?  Revisiting the use cases from Section 5, isn’t 802.1X more commonly deployed in enterprise scenarios such as scenario-D (BYOD) and scenario-E (managed enterprises) where policy can control how much RCM is happening?  

** Section 6.2.  Why is the level of “network support expectation” medium for scenario-B.  This is a managed network.  Why isn’t it “high”?  What’s the difference?

** Section 6.2.  What is the difference between simple/medium/complex?  Why can’t scenario-A be “simple”?

** Section 6.2
   Home users typically expect the network operator to protect the home
   network from external threats (i.e., attacks from the Internet).

What is the basis of this assertion?  If it were the case, the personal “anti-virus”/end-point market would seemingly be much smaller than it is.

** Section 6.2
   On the other end of the spectrum, Public Wi-Fi is often viewed as
   completely untrusted, with users not expecting to trust other users
   or actors inside or outside the layer-2 domain. 

   Privacy is one of
   the major concerns for users. 

Could this be substantiated? Does the average user know to exercise caution on public Wi-Fi?

# Internet AD comments for draft-ietf-madinas-use-cases-16
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S6.1

* "with SLAAC defined in [RFC6620]"

  SLAAC is defined in 4862.  6620 is a SAVI doc and doesn't define SLAAC
  per se.

## Nits

### Abstract

* "and its user in Wi-Fi [IEEE_802.11] network" ->
  "and its user in Wi-Fi [IEEE_802.11] networks"

### S3.2

* "They can use the MAC address to represent an identified device."

  Consider "They may use" or "They often use", to avoid the appearance
  of approving of  the use of MAC addresses as identifiers that might come
  with some interpretations of the word "can".

Thanks for this interesting document, I enjoyed reading it.

One nit: “temporal” is not a synonym for “temporary”. It seems like you mean the latter in the four places you use the former.

Thanks to Marco Tiloca for his ARTART review.

Thanks for this document. Thanks to Tommy Pauly for the TSVART review, I agree it has do not involve transport protocol related issues.