Comparing SMD Roaming and Enhanced FT Roaming Approaches

April 2024 doc.: IEEE 802.11-24/0655r0 Thoughts on SMD Roaming and FT Roaming Date: 2024-04-02 Authors: Name Binita Gupta Affiliations Cisco Systems Address San Diego, CA, USA Phone email binitag@cisco.com brianh@cisco.com Brian Hart Cisco Systems mmsmith@cisco.com Malcolm Smith Cisco Systems sorr@cisco.com Stephen Orr Cisco Systems Submission Slide 1 Binita Gupta et al (Cisco Systems)

April 2024 doc.: IEEE 802.11-24/0655r0 Introduction Several UHR presentations have covered seamless roaming improvements. Two different categories of proposals been presented based on roaming within a mobility domain: Seamless roaming within an SMD (single/seamless mobility domain) that covers multiple non- collocated AP MLDs Enhancement to existing FT roaming within an FT mobility domain In this presentation we compare the key aspects of SMD roaming and enhanced FT roaming approaches and propose a way forward Submission Slide 2 Binita Gupta et al (Cisco Systems)

April 2024 doc.: IEEE 802.11-24/0655r0 Recap - SMD Roaming Several presentations have proposed the SMD roaming architecture [1-9] Key aspects of SMD roaming architecture: A non-AP MLD seamlessly roams across AP MLDs that are part of an SMD (Single/Seamless Mobility Domain) - remains in state 4 during and after roaming (TGbn motion passed). Non-AP MLD establishes an association with the SMD, does not need to reassociate with target AP when roaming. Seamless roaming is executed using dynamic add/delete links operation. Each AP MLD has its own connection to DS, during roaming DS mapping changes from serving to target AP MLD. Non-AP MLD can initiate transfer of near static context (e.g. SCS, TWT etc) in advance to one or more neighbor APs to prepare candidate target APs for roaming (roaming prep), to shorten UL data pause during roaming Dynamic context (SN, PN, BA context ) is transferred when non-AP MLD roams to a target AP, triggers DS mapping change from serving to target AP MLD) (roaming execution) Buffered DL data can be delivered to/fetched by the non-AP MLD by/from the serving AP MLD even after DS mapping change for a period, to minimize data loss PMK and PTK are pairwise keys between the logical SMD entity (covering multiple AP MLDs) and the non-AP MLD. PTK can get rekeyed after (or before) roaming to minimize sharing of PTK between source and target APs. Next, we present some high-level call flows for SMD roaming highlighting key aspects Submission Slide 3 Binita Gupta et al (Cisco Systems)

April 2024 doc.: IEEE 802.11-24/0655r0 SMD Roaming flow (1) SMD Target AP MLD MLD Serving AP MLD Target AP STA (Re)Association Request/Response (Initial association with SMD) Initial SMD Association 802.1X/EAP Auth (skipped for PSK/SAE) PMK PMK generated generated 4-way handshake Candidate Target AP MLDs prepare for accepting the non-AP MLD on the links indicated. PTK generated PTK generated Roaming Prep (across multiple target AP MLDs) Single req/resp exchange to initiate near static context transfer to multiple neighboring AP MLDs Roaming preparation request (requested links with candidate target AP MLDs) Roaming context transfer (links, near static context, capabilities) *PMK/PTK Installed Roaming preparation response *Alternatively, PTK could be installed at the roaming execution time Resource reservation could be considered for a bounded time on candidate target AP MLDs, when roaming prep is performed close to actual roaming. The roaming execution should be triggered within the time bound. Submission Slide 4 Binita Gupta et al (Cisco Systems)

April 2024 doc.: IEEE 802.11-24/0655r0 SMD Roaming flow (2) SMD Serving AP MLD Target AP MLD STA UL/DL data Make-Before-Break roaming DL remains active with serving AP. UL paused. Drain UL data Roaming Execution Roaming request (PMF protected) Roaming context transfer (*SN, PN, BA context) Dual DL data connection, to minimize roaming data outage and data loss ^Initiate DS mapping update Open 802.1X port Roaming response (PMF protected) UL/DL data Buffered DL data Same PTK used by serving and Target AP MLD during roaming transition Client maintain a single PTK during roaming Buffered DL data delivered/timeout #PTK rekeyed by Target AP MLD after roaming to mitigate PTK sharing concern PTK rekeying New PTK generated New PTK generated *PN sent is incremented (e.g. by 1000) to account for future packets arrival at the source AP and ensure PN is never reused. Same for SN sent. ^Until DS mapping is updated in the backhaul, DL data keeps flowing to the serving AP and will get delivered as buffered DL data. Target AP starts accepting UL data after DS mapping update has been initiated. #Another option is for PTK to be rekeyed just before roaming (when possible) to mitigate PTK sharing concern. Submission Slide 5 Binita Gupta et al (Cisco Systems)

April 2024 doc.: IEEE 802.11-24/0655r0 SMD Roaming through Target AP MLD SMD Serving AP MLD Target AP MLD STA UL/DL data Roaming Execution STA RSSI drops Select a target AP MLD to roam Only 2 messages exchanged for roaming through target AP MLD Roaming Request (PMF protected) Fetch PMK and PTK Roaming Context transfer (SN, PN, BA context, near static context, capabilities, ) Same PTK used by Target AP MLD during roaming Roaming Req/Resp is protected Initiate DS mapping update Roaming Response (PMF protected) Client maintains a single PTK during roaming UL/DL data PTK rekeyed by Target AP MLD after roaming to mitigate PTK sharing concern PTK rekeying New PTK generated New PTK generated Binita Gupta et al (Cisco Systems) Submission Slide 6

April 2024 doc.: IEEE 802.11-24/0655r0 Key benefits of SMD roaming Simple architecture requiring association only once with a single mobility domain (covering multiple AP MLDs), and then achieving seamless roaming thereafter using add/delete links Simpler client implementation to maintain only a single PTK during roaming Architecture enables Dual DL data connection with both serving and target AP MLD during roaming to minimize roaming data outage and data loss Supports secure roaming through the target AP MLD with PMF protected roaming exchange During last minute/panic roam, avoids the need to establish a new PTK and provides more efficient and more reliable seamless roaming experience Can leverage existing PTK rekeying to regenerate a new PTK after roaming - to mitigate concerns on PTK sharing Note: PTK is pairwise between logical SMD entity and non-AP MLD, and conceptually used at the SMD level, with SMD entity functions split across AP MLDs of that SMD. This is similar to the split-MAC controller/WLC based architecture deployed today in enterprises where MAC functions are split between WLC and AP, and PTK can be shared between the two entity. Submission Slide 7 Binita Gupta et al (Cisco Systems)

April 2024 doc.: IEEE 802.11-24/0655r0 Recap - Enhanced FT Roaming Some UHR presentations have proposed reusing and enhancing FT for improved roaming support: [10] proposes using and enhancing FT signaling for seamless roaming [11] proposes using FT key hierarchy as the basis for maintaining separate PTKs per AP MLD for seamless roaming At a high level, enhanced FT approach includes: 1. Continue to use FT key hierarchy- PMK-R0, PMK-R1s and per AP MLD PTK 2. Enhance FT to support Reassoc Req/Resp exchange through serving AP MLD, to minimize data interruption 3. Enhance FT to add context transfer for data continuity (e.g. transfer of SN, BA context, ) 4. Enhance FT to add transfer of other near static context (SCS, TWT agreements etc.) to avoid reestablishing these context with target AP MLD 5. Support data forwarding from serving AP to target AP MLD (in some cases) 6. [11] also proposes adding a new key across all AP MLDs of the FT mobility domain to send secure FT over-the-air messages when roaming through target AP. This results in a new key hierarchy. We believe that with all the proposed enhancements, enhanced FT will look very different than current FT. Hence, there is no strong reason to be constrained by FT architecture to achieve seamless roaming. Next, we present high-level call flows for enhanced FT roaming highlighting key aspects/challenges. Submission Slide 8 Binita Gupta et al (Cisco Systems)

April 2024 doc.: IEEE 802.11-24/0655r0 Enhanced FT Roaming (1) FT MD Target AP MLD MLD Serving AP MLD Target AP STA (Re)Association Request/Response (Initial association with SMD) Initial FT MD Association Scalability concern with generating large # of PMK R1s. Addressed today in implem. specific way. Simplification is desired. 802.1X/EAP Auth (skipped for PSK/SAE) PMK-R0 and PMK-R1 generated PMK-R0 and PMK-R1s generated* 4-way handshake Multiple FT Req/Resp exchange needed, with existing FT messages (leads to higher overhead) PTK1 generated PTK1 generated Roaming Prep (across multiple target AP MLDs) FT Request OTDS FT Req w/ context transfer (near static context) FT enhanced with context transfer PMK-R1 Installed PTK2 generated FT Response PMK-R1 generated PTK2 generated FT Request OTDS FT Req w/ context transfer (near static context) Client maintains multiple PTKs to support roaming preparation with multiple target AP MLDs. (leads to higher complexity) FT Response PMK-R1 Installed PTK3 generated PMK-R1 generated PTK3 generated FT Request OTDS FT Req w/ context transfer (near static context) FT Response PMK-R1 Installed PTK4 generated PMK-R1 generated PTK4 generated Binita Gupta et al (Cisco Systems) Submission Slide 9

April 2024 doc.: IEEE 802.11-24/0655r0 Enhanced FT Roaming (2a) Reassociation Request/Response exchanged OTA with target AP MLD FT MD Serving AP MLD Target AP MLD STA Client uses PTK for serving AP UL/DL data Roaming Execution Break before make roaming for data, since DL data stops with serving AP, before DL data starts with target AP. FT enhanced with context transfer Reassociation request (not PMF protected) Context transfer (SN, BA context, ) Initiate DS mapping update Data outage Reassociation response (not PMF protected) Client uses PTK for target AP UL/DL data Client can t receive buffered DL data from serving AP MLD, since associated with target AP, Buffered DL data will be lost (if not transferred) Can t support fetching of buffered DL data from serving AP, because STA needs to remain associated with both serving & target APs during roaming, does not fit with current FT architecture, where STA is associated with (in state 4) only with one AP. Buffered DL data on serving AP will be lost in cases where data can t be transferred. Also, can t mandate that data transfer is supported for all buffered data to target AP in all deployments. Submission Slide 10 Binita Gupta et al (Cisco Systems)

April 2024 doc.: IEEE 802.11-24/0655r0 Enhanced FT Roaming (2b) Reassociation Request/Response exchanged with serving AP MLD FT MD Serving AP MLD Target AP MLD STA Client uses PTK for serving AP UL/DL data Roaming Execution FT enhanced to exchange Reassoc with serving AP MLD Reassociation request (PMF protected) Client can continue to receive DL data from serving AP OTDS Reassoc w/ context transfer (SN, BA context ) Initiate DS mapping update Client uses PTK for target AP. Needs to maintain multiple keys. Reassociation response (PMF protected) FT enhanced with context transfer UL/DL data Client can t receive buffered DL data from serving AP MLD, since associated with target AP MLD. Buffered DL data after Reassoc response will be lost (if not transferred). Buffered DL data on serving AP will be lost in cases where data can t be transferred. Also, can t mandate that data transfer is supported for all buffered data to target AP in all deployments. Submission Slide 11 Binita Gupta et al (Cisco Systems)

April 2024 doc.: IEEE 802.11-24/0655r0 FT Roaming through Target AP MLD FT MD Serving AP MLD Target AP MLD STA UL/DL data STA RSSI drops Select a target AP MLD to roam Must exchange 4 messages for roaming. Longer roaming time Roaming Execution Auth Request (not PMF protected) Fetch PMK-R1 Generate PTK Auth Response (not PMF protected) Generate PMK-R1 Generate PTK FT enhanced with context transfer Roaming messages are not protected Reassociation Request (not PMF protected) Context transfer (SN, BA context, SCS, TWT etc.) Initiate DS mapping update Reassociation response (not PMF protected) UL/DL data Submission Slide 12 Binita Gupta et al (Cisco Systems)

April 2024 doc.: IEEE 802.11-24/0655r0 Key challenges with Enhanced FT roaming Supporting dual DL data connection with serving and target AP during roaming does not fit in current FT architecture, where STA is associated (and in state 4) only with one AP. This will lead to loss of buffered DL data. for cases where data can t be transferred. Also, can t mandate data transfer to target AP in all deployments, since this mandates high throughput backhaul connectivity requirements between APs which may not be possible in all deployments Enhancing FT to support dual DL will require significant FT architecture changes to support assoc with multiple AP MLDs. STA will also need to maintain multiple keys during roaming to be able to receive data both from serving AP and target AP. Complicates client implementation or with simpler clients adds to roaming delay. With simpler client implementations where multiple keys not supported (as in most current clients), FT will lead to added roaming delay associated with key negotiation and reassoc, any failures would further worsen delay, client can t continue with serving AP Unprotected roaming execution through the target AP MLD, since roaming management frames that initiate context transfer are not PMF protected. Can lead to security attacks. Rogue STAs can initiate context transfer between APs, causing possible DoS attack over the backhaul. Adding a new key for protecting OTA roaming frames require non-trivial security enhancement, need to consider rekeying for the new key, else if compromised can lead to unwanted roaming attacks by rogue STAs. Adds significant complexity. Deployment challenges: FT is disabled in many enterprise deployments due to compatibility issues with legacy clients (led to adaptive 11r). Basing seamless roaming on FT would face challenges in deployments where 11r is disabled. Scalability concerns FT has AP side scalability issue for generating 1000 s of PMKs in large enterprise deployments. It is desired to address this in UHR roaming. Clients also need to scale to maintain multiple set of PMK-R1s/PTKs. Submission Slide 13 Binita Gupta et al (Cisco Systems)

April 2024 doc.: IEEE 802.11-24/0655r0 Summary - SMD Roaming vs Enhanced FT Roaming (1) Features SMD Roaming FT Roaming (current) Enhanced FT Roaming Make-before-break data roaming Yes No Possible, but requires higher client complexity to maintain multiple keys. Dual DL data connection to minimize data loss Yes No Not possible in current FT architecture. Will cause loss of buffered DL data (where data transfer for all buffered DL data is not supported). Data transfer required from serving AP to target AP No No Yes, to avoid loss of buffered DL data Roaming preparation (to transfer near static context), minimize UL pause time Yes Single Roaming Prep Req/Resp for N neighbor APs No Possible. N x FT Req/Resp. N times higher overhead, If a new message added, then needs to be on top of FT Req/Rsp (used for FT key gen) Dynamic context transfer Yes No Possible Reassociation required No (Uses link add/delete) Yes Yes Key hierarchy Single PMK and PTK between logical SMD entity and the non-AP MLD. FT key hierarchy - PMK R0, PMK R1s, PTKs FT key hierarchy - PMK R0, PMK R1s, PTKs --If a new key is added to encrypt roaming related frames, it leads to new key hierarchy and new AKM would need to be defined. Submission Slide 14 Binita Gupta et al (Cisco Systems)

April 2024 doc.: IEEE 802.11-24/0655r0 Summary - SMD Roaming vs Enhanced FT Roaming (2) Features SMD Roaming FT Roaming (current) Enhanced FT Roaming Scalability concerns No (Single PMK/PTK maintained per SMD) Yes. Scale to support large # of PMK-R1s. Addressed in implem. specific way currently. Yes. Need to scale to support large # of PMK-R1s. Multiple PTKs need to be supported during roaming No. PTK is shared, can be rekeyed after roaming. Implem. specific. Most implem. delete old PTK before installing new PTK Yes. Complicates client implem. Dependency on supplicant to install keys in a timely fashion. Protected Seamless Roaming through the target AP MLD Yes Add link to target AP MLD is PMF protected using PTK No Auth frames and Reassoc Req/Rsp frames are not PMF protected No. Same as FT. If a new key is added for protecting roaming frames, it can add significant complexity including rekeying of the new key. Number of frame exchanges for roaming through target AP MLD 2 (Roaming Req/Resp for add link) 4 (FT Req/Resp, Reassoc Req/Resp) 4 (FT Req/Resp, Reassoc Req/Resp) Higher messaging overhead adds to roaming delay. Roaming reliability and robustness Provides more reliable and robust roaming since last minute/panic roam does not require PTK regeneration Less reliable and robust roaming, since last minute/panic roam would require PTK regeneration, adding to roaming delays. Less reliable and robust roaming, for same reason as FT. Submission Slide 15 Binita Gupta et al (Cisco Systems)

April 2024 doc.: IEEE 802.11-24/0655r0 Proposed Way Forward UHR should aim to provide significant improvement in roaming performance - much reduced roaming execution time, reduced roaming data outage time and reduced roaming data loss Enhanced FT has several challenges to meet these requirements: Retrieval of buffered DL data from serving AP can t be supported in FT architecture. Leads to DL data loss, unless data transfer is supported. Requires data transfer between APs to avoid roaming data loss, which can t be mandated in all deployments. Need to enhance FT architecture to enable association with multiple AP MLDs for supporting dual DL connection during roam. Clients needs to support multiple PTKs during roaming adds significant client complexity When client architecture can not support multiple keys, then it leads to added roaming delays Not always possible for client to do PTK generation in advance or just before roaming (e.g. in last minute roam), longer roaming delays SMD roaming provides many key benefits and architecture advantages: Simple architecture requiring association only once with the SMD, and then achieving seamless roaming using add/delete links Simpler client implementation to maintain only a single PTK during roaming Enables Dual DL data connection during roaming to minimize roaming data outage and roaming data loss Supports secure roaming through the target AP MLD with PMF protected roaming exchange Provides a faster, more scalable, more robust and more reliable seamless roaming solution We believe that SMD roaming is a much better solution to achieve seamless roaming improvements desired for UHR Security concerns related to PTK sharing can be mitigated by rekeying after roaming (or shortly before roaming) PTK rekeying can be initiated by either the AP or the STA. Submission Slide 16 Binita Gupta et al (Cisco Systems)

April 2024 doc.: IEEE 802.11-24/0655r0 Conclusion We covered key aspects of SMD roaming and highlighted its key benefits We captured some key aspects of enhanced FT roaming (as proposed in 11bn) and highlighted key challenges we see with enhanced FT roaming to achieve desired roaming improvements We summarized comparison between SMD roaming and enhanced FT roaming on key points We believe SMD roaming with its benefits and simpler architecture provides a much better solution for achieving seamless roaming improvements desired for UHR Submission Slide 17 Binita Gupta et al (Cisco Systems)

February 2024 doc.: IEEE 802.11-24/0655r0 References [1] 11-23-2157 Seamless roaming within a mobility domain [2] 11-22/1910 Seamless Roaming for UHR [3] 11-23/0170 Smooth Roaming [4] 11-23/1131 Thoughts on seamless roaming [5] 11-23-1416 Seamless roaming follow up [6] 11-23-1996 Improve roaming between MLDs [7] 11-23-0632 smooth-roaming-follow-up [8] 11-24-0396 Seamless roaming within a mobility domain follow up [9] 11-24-0398 Coordinated roaming through target AP MLD [10] 11-24-349, Enhanced Fast BSS Transition [11] 11-24-679 Thoughts on Functionality and Security Architecture for UHR Seamless Roaming Submission Slide 18 Binita Gupta et al (Cisco Systems)