**Session Date/Time:** 11 May 2023 14:00

# [MADINAS](../wg/madinas.html)

## Summary

This interim meeting of the MADINAS Working Group focused on the advancement of the Best Current Practice (BCP) document, a key chartered item. Discussion revolved around two candidate BCP drafts and a proposed structure for MADINAS documents, aiming to establish a clear path forward for adoption. An important update was also provided by Mark R. Hamilton on the progress of IEEE 802.11bh, which is addressing MAC address randomization from an 802.11 perspective. The meeting highlighted the need for continued discussion on the mailing list to refine document scope, address "requirements" definitions, and formalize collaboration with IEEE.

## Key Discussion Points

*   **Welcome and Logistics**
    *   Chairs Carlos Bernardos (UC3M) and Michael Church (Cisco) opened the meeting, reminding participants of the IETF Notewell.
    *   Michael Church volunteered to take notes, with Juan Carlos and another volunteer assisting.
    *   The agenda focused primarily on the BCP document discussion, followed by an IEEE 802.11bh status update.

*   **BCP Document Discussion - `draft-henry-madinas-bcp-network-rcm`**
    *   Jerome Henry presented this draft (co-authored with Emiliana).
    *   The document derives from moving Section 7 out of the use cases document into a BCP.
    *   It summarizes RCM (Randomized and Changing MAC) expected practices across various environments (home, managed residential, enterprise).
    *   It also details how technologies like WPA2/3, 802.1X, and OWE (Opportunistic Wireless Encryption) can protect data payload but not the MAC address itself.
    *   **Next Steps**: Jerome suggested studying unification with Michael Church's BCP document and allowing time for the BCP to take shape, potentially leading to refinements in the use case framework document.

*   **BCP Document Discussion - `draft-church-madinas-bcp`**
    *   Michael Church presented, reviewing MADINAS charter items related to RCM impact, non-MAC identities, and BCP recommendations.
    *   **Pre-association vs. Association**: Michael highlighted that MAC address randomization applies to two distinct phases: pre-association (probing) and association. Policies for these may differ, and chipset limitations might affect the ability to change MACs between these phases.
    *   **Proposed Document Structure**:
        *   **Use Cases Document**: Should detail how static MAC addresses have been traditionally used, potentially drawing from IEEE work (e.g., airport security queue sizing). He suggested dropping "requirements" from the title of the existing use cases document to avoid confusion with architectural requirements.
        *   **RCM Document**: Should analyze the impact of different RCM policies on the documented use cases.
        *   **BCP Document**: Should recommend changes to network or service operation to mitigate the impact of RCM without compromising user privacy.
    *   **Discussion on "Requirements"**: Juan Carlos questioned the definition of "requirements" in this context. Michael clarified that these are high-level descriptions of what a use case needs to function (e.g., identifying a user in a managed network) rather than formal IETF standard-track requirements.
    *   **Discussion on User Consent and Tracking**: Amelia strongly emphasized that BCPs should consider user consent regarding tracking. Network service providers might not have the right to track individuals without explicit consent (e.g., grocery store path tracking). Mark R. Hamilton suggested framing the discussion using "dimensions" of tracking:
        *   Anonymous vs. Identified tracking.
        *   Trackable by third parties vs. only by the network operator.
        *   Duration of tracking (e.g., lifetime of a randomized MAC address).
        *   This helps in categorizing concerns and requirements for solutions.

*   **IEEE 802.11bh Status Update**
    *   Mark R. Hamilton (presenting as an individual, not an IEEE representative) provided an update.
    *   **Split Work in IEEE**:
        *   **TGbh**: Focuses on reacting to devices using randomized MACs that disrupt existing 802.11 facilities. The goal is to restore functionality without leaking new stable identities. Draft 1.0 is nearing completion.
        *   **TGbi**: Addresses the broader scope of leaking personal information and tracking beyond TGbh. This work is still in early discussion stages.
    *   **TGbh Mechanisms (Draft 1.0)**:
        *   **Device ID**: The network allocates a unique identifier to a device, typically after a secure negotiation (e.g., 802.1X). This ID is communicated securely, preventing third-party snooping. An optional opaque blob can be used for pre-association.
        *   **Identifiable MAC Address**: The device, after establishing a secure connection with a known network, informs the network of the *next* randomized MAC address it will use. This allows the network to recognize the device even if its MAC address changes, while the device retains control over the rotation frequency. This can facilitate pre-association behaviors (e.g., using a recognizable MAC for probing a known network, while using fully random MACs for general scanning).
    *   TGbh leverages work from 802.11az for pre-association authentication and secure information exchange.
    *   **Collaboration**: Mark emphasized the value of collaborating on use cases and problem dimensions. He expressed willingness to share TGbh Draft 1.0 with MADINAS as soon as it's finalized (expected next week), working with the chairs and Dorothy Stanley (802.11 chair) to navigate copyright and privacy rules.

## Decisions and Action Items

*   **Decision**: Due to time constraints and the limited audience in the interim, further discussion on BCP document direction, unification, and collaboration with IEEE will continue on the MADINAS mailing list.
*   **Action Item (Mark R. Hamilton and MADINAS Chairs)**: Facilitate the sharing of IEEE 802.11bh Draft 1.0 (once approved) with the MADINAS Working Group members. This may involve formal liaison or agreed-upon mechanisms for sharing copyrighted material.
*   **Action Item (BCP Authors - Jerome Henry, Emiliana, Michael Church)**: Continue internal discussions regarding the potential merging or unification of the two BCP drafts and post updates to the MADINAS mailing list for wider WG input.
*   **Action Item (MADINAS WG Participants)**: Engage in further discussion on the mailing list regarding the proposed document structure, the definition and scope of "requirements" in MADINAS documents, and the implications of the IEEE 802.11bh update.

## Next Steps

*   The chairs will work with Mark R. Hamilton to enable the MADINAS WG to review the upcoming IEEE 802.11bh Draft 1.0 document.
*   BCP authors are encouraged to continue their discussions on unifying the existing BCP drafts and propose a clear path forward for WG adoption.
*   The mailing list will be the primary forum for ongoing technical discussions on document content, requirements, and inter-WG collaboration.