Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGBE] [STDS-802-11-TGBH] 24/305r7-- the proposed text for 11bh feature extension for MLO

Hi Jay,

Thank you for your responses and all your efforts on this. 
Please find my follow-up responses inline below.

Thanks,
Binita

On Thu, Jun 6, 2024 at 5:54 PM <yang.zhijie@xxxxxxxxxx> wrote:

Hi Binita ,

Thanks for your comments. See my response inline in red font.





Thanks


Best Regards


Jay Yang (杨志杰)



Original
From: BinitaGupta <bingupta.ieee@xxxxxxxxx>
To: 杨志杰10343608;
Date: 2024年06月07日 08:07
Subject: Re: [STDS-802-11-TGBE] [STDS-802-11-TGBH] 24/305r7-- the proposed text for 11bh feature extension for MLO
Hi Jay,
Thank you for sharing a revised and clean version of this document. 

The version of your document that had passed SP had the IRM sent in the TA field for the MLD case. Group had aligned on that and I still think that is a simple and clean solution. The different direction taken in the document now where the IRM must only be provided in the MLD MAC Address is making it more complicated. Here is my feedback on the two approaches.

#1: Provide IRM in the TA field for MLD (and in Basic ML element where present)

--><Jay>That's conflict with 11be baseline. the current text says "An MLD uses an MLD MAC address that singly identifies the MLD . "(see  35.3.2 MLD addressing).  But there is no text to say "the affiliated STA's MAC address can singly identifies the correspond MLD if MLD MAC address is not present".

In order to compatible with 11bh draft, One way we need to change 11be baseline text, an alternative approach is to insert ML element in certain frame if it's missing. I would like to ask the group which direction we would like to go?

[Binita] 11bh defines two mechanisms for AP to recognize a client device. The Device Id and the IRM. If it is clarified that these identifiers identify a client device, and not a non-AP STA or a non-AP MLD, then we don't have any such conflict. Why can't we clarify that these identifiers identify the client device? The goal for the network is to identify if a returning client is the same device, and not identify a specific STA or the non-AP MLD. Isn't that true?


I would like to highlight that the 11be draft captures the following blue requirement in clause 35.3.1. This requires that the non-AP STA MAC address is set to the MLD MAC address for MLO ->non-MLO transition, and the MLD MAC Address is set to the non-AP STA MAC address for non-MLO ->MLO transition. With this already required, the non-AP STA and MLD MAC addresses are used in-place of each other in these cases, so why can't we extend that logic for IRM - provide IRM that was established during an MLD association as the non-AP STA MAC address in the TA field. That will be the simplest approach in my opinion - always provide IRM in the TA (does not require making any changes to the frame format for indicating IRM ). This also provides the benefit that the inclusion of IRM is not obvious in a frame (TA is always there). For frames that already include a Basic ML element (e.g. Authentication, Association Request) the IRM can be provided as the MLD MAC Address too. 

The MAC address of a non-AP EHT STA with dot11MultiLinkActivated equal to false shall be set to the
MLD MAC address of the non-AP MLD that the non-AP EHT STA is affiliated with when the non-AP EHT
STA has dot11MultiLinkActivated equal to true, and vice versa.

Again, given that we already have the text above where MLD MAC address and non-AP STA MAC address are used in-place of each other, we can argue for similar logic for IRM . Not convinced that we need a more complicated solution. 

Would like to hear feedback on this from the group, because this approach can keep the IRM solution for MLD very similar to baseline 11bh with minimal changes. We can also more easily integrate such a solution in the existing clause (as Alfred has suggested) as opposed to writing a new clause. 

#2 Providing IRM in the MLD MAC address 

Even if the group decided to go with the direction of providing IRM only in the MLD  MAC address, this should only apply for frames which are intended to be exchanged between MLDs . The Probe Request and ANQP frames are not between MLDs . In clause 35.3.14.1, the (regular) Probe Request/Response and ANQP frame are not listed as exchanged between MLDs . These are sent to AP(s) prior to association, the non-AP MLD client device does not even know whether there are AP MLDs or just non-ML APs in that region of the ESS . Hence, even if we go the other route, we don't need to add any Basic ML element in these frames. When sending these frames, the client is acting as a non-AP STA and should provide IRM in the TA field. 

--><Jay>That's conflict with 11be baseline. In subclause  35.3.4.6 (Frame exchange sequences during MLO discovery and ML setup), the current text says  (regular) probe request/response can be used by non-AP MLD to discover an AP MLD . Refer to  the cited text " Through each of its affiliated STAs , perform passive scanning by following the procedure defined in  11.1.4.2 (Passive scanning) or active scanning by following the procedure defined in 11.1.4.3  (Active scanning and probing procedures)."

[Binita] That text still means that each non-AP STA is sending a non-ML Probe Request for scanning to the corresponding AP. In clause 35.3.14.1, the (regular) Probe Request/Response are not listed between MLDs. These frames are between non-AP STA and the AP, hence must not include an ML element. In fact, including a Basic ML element in the Probe Request will conflict with the 11be baseline, since this frame is not an MLD level frame. 
 
Only the Multi-link probe request/response preassoc frame is exchanged between MLDs . That can include a Basic ML element if we go the direction of providing IRM in the MLD  MAC Address.

We should also explicitly capture the text for use of IRM when transitioning from MLO ->non-MLO and vice versa along the following line, and this should be a 'may' requirement as Jay had in a previous version, and not just a NOTE. A NOTE is weaker than a may requirement.

(MLO to non-MLO case)

A non-AP MLD that previously provided an IRM to an AP MLD in an ESS and later associates with an AP within the same ESS , may provide that IRM as the MAC address in the TA field in the preassoc frames, Authentication and Association Request frames if it intends to be identified by the AP in that ESS .


(non-MLO to MLO case):

A non-AP STA that previously provided an IRM to an AP in an ESS and later associates with an AP MLD within the same ESS , may provide that IRM as its MLD MAC address in the Basic Multi-Link element if it intends to be identified by the AP MLD in that ESS .

--><Jay> Using normative text is OK, but Mike's proposed text looks better,right?

[Binita] 11bh baseline has normative "may" text for IRM, and similar normative text should also be used for MLD case. NOTE should not replace the normative text. Also, the NOTE does not convey that the IRM which was provided for the MLD earlier can now be used for the TA field for the non-AP STA and vice versa. We need normative text to cover those rules.


Also, even in this case, clients can have a simple logic of providing IRM in both the TA field and the MLD MAC Address field. Note that the TA field also has to be RCM to avoid tracking, hence it makes sense to provide IRM in TA as well. Note that this does not conflict with MLD MAC address logic, because the MLD MAC Address can be set to one of the STA MAC address. 
--><Jay> That's a pretty ideas, but we need to change 11be baseline to support that.
[Binita] As long as we clarify that IRM is for identifying the device, then we can define the rule that a non-AP MLD device can provide IRM in the TA and MLD MAC address (where applicable). Don't see a need to make any changes to 11be baseline. 



Would be good to hear more feedback on the direction which group wants to take on this #1 or #2. Based on the direction chosen, I can provide more detailed in-line feedback. 

--><Jay> Same question, To compatible with 11bh draft, do we need to change 11be baseline at this moment as 11be already pass the initial SA ballot?

[Binita] See above. We don't need to make any changes to 11be baseline, if we clarify that IRM is for the client device (not for a non-AP STA or a non-AP MLD).  


I also agree with Alfred that we should integrate MLD specific text in the existing clause, instead of duplicating a lot of the text in a new clause. The only difference is the PASN part, and that may not remain the case in future, so it is better to have a single clause from now itself. 

--><Jay> It's not a easy job to identify each sentence to understand whether it's relevant to PASN authentcation or not. And then seperate it carefully.  I'm fine if you or any other members can help to make it now. 

[Binita] Understand that this could lead to some more work. I'll leave this to Alfred and other members to further comment, but I think we should follow similar approach as we have done for other baseline feature enhancements to MLD, and not create an exception in this case and duplicate the entire clause. 

Thanks,
Binita

On Thu, Jun 6, 2024 at 4:22 PM Jay Yang <yang.zhijie@xxxxxxxxxx> wrote:

Hi Alfred,


Thanks for your comments. Let me clarify it.

In 11bh baseline,  4HS, FILS authentication and PASN authentication scenarios are involved for the usage of 11bh feature. While 11be baseline only define MLO 4HS and MLO FILS authentication. That's, MLO PASN is still missing(Maybe TGbk can address it). Based on the direction your suggested, we have to use "for MLO " and, "for non-MLO " to duplicate the text if we encounter the text relevant to PASN . While text relevant to PASN is scattered in different kinds of palces in  latest11bh draft. To void messing up the situation and void a bunch of new potential comments, the simple and easy way is to have two new subclauses .

Once any TG or draft define MLO PASN , we could merge the text back to original subclause , perhaps such Job will be done in 11mf. I also consult to some experienced security expert on the writing style in subclause 12, he also agreed with this.

Hope such explanation can address you concern, and welcome further comments.




Thanks


Best Regards


Jay Yang (杨志杰)



Original
From: AlfredAsterjadhi <asterjadhi@xxxxxxxxx>
Date: 2024年06月07日 01:30
Subject: Re: [STDS-802-11-TGBE] [STDS-802-11-TGBH] 24/305r7-- the proposed text for 11bh feature extension for MLO
Jay, 
Thanks for the doc. From a quick review it seems that there are two newly added subclauses to clause 12 which are kind of copy paste of their non-MLD counterparts. I suggest we use the same style we have been using for other subclauses that are modified from baseline. Please use other clauses in 12 as references. That way we minimize the newly added text to the draft and also narrow the reviewing in scope to new changes. 

Regards,

Alfred

On Thu, Jun 6, 2024 at 9:05 AM Joseph Levy <000019588066c6b7-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

Hi Jay and Mike – thank you for this.  I started a detailed review – see attached, where I provided some editorial corrections in the definitions clause.  During my review it became clear to me that there is a potential critical issue exposed by the proposed changes.

 

It is my understanding that while the MAC (both upper and lower MAC for an MLD ) use the MAC address or any other ID, the MAC does not control or set the MAC address.  The MAC address is set/controlled by the SME .  So, statements on MLD behavior regarding setting or changing a MAC address should not state that the MLD is doing it, the SME and entities beyond the STA, AP, or MLD is setting or changing the MAC address. The MLDs , affiliated APs , or affiliated AP are supporting the ability. This is also true regarding the IDs (IRM or device ID).  The STA, affiliated STA, or affiliated AP may receive or transmit the MAC address or ID, the MLD which is a MAC/PHY logical entity does not it relies on the MLD MAC address in the MLD element.  Hence, I think the phrase “AP MLD ” should be changed to “affiliated AP” and “non-AP MLD ” to “affiliated STA” in most locations in this proposed comment resolution document.  I didn’t want to do all the work to update the proposed resolutions until there was agreement that this change should be done.  

 

Note the careful wording of the original clause “To mitigate this sort of traffic analysis a STA can support the ability to periodically and randomly change its MAC addresses and reset counters and seeds prior to association.”  The wording states “a STA can support” the STA MAC is not changing these things it is only supporting the SME ’s ability to change things. The SME is not wholly contained in the STA and the higher layers providing the management of the MAC address are possibly outside of the SME .   

 

This proposed change impacts the proposed changes throughout this resolution document. 

 

Also, I believe that if the proposed change is in conflict with existing text in the TGbe draft, the conflicting text in the current draft should also be corrected, because if we agree this is the correct way to proceed then the existing text it is technically incorrect. 

 

Regards,

Joseph

 

From: Jay Yang <yang.zhijie@xxxxxxxxxx>
Sent: Thursday, June 6, 2024 2:36 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [STDS-802-11-TGBH] 24/305r7-- the proposed text for 11bh feature extension for MLO

 

Hi Mike,

Thanks for the comments, your proposal is merged into the NEW Note5 in the attached document. 

Also, I clean up the mess up traces to make the document looks better,  please help review it. 

 

 

 

Thanks

 

Best Regards

 

Jay Yang (杨志杰)

 

 

Original

From: MMontemurro <montemurro.michael@xxxxxxxxx>

Date: 2024年06月06日 01:11

Subject: Re: [STDS-802-11-TGBE] [STDS-802-11-TGBH] 24/305r7-- the proposed text for 11bh feature extension for MLO

Hi Jay,

 

Thanks for the updated document. In principle I do not have issues of adding text for 1) and 2). However I don't believe all the text for 1 is required and duplicates requirements in 12.2.12.1.

 

If an MLD that uses IRM leaves a network and comes back as a STA, it would follow the procedures in 12.2.12.1. Otherwise it follows the requirements in 12.2.12.2.

 

I would say that adding the following note is sufficient:

NOTE -- When a non-AP MLD using IRM connects to an AP as a non-AP STA, it follows the procedures defined in 12.2.12.1. Similarly, when a non-AP STA using IRM connects to an AP MLD , it follows the procedures defined in 12.2.12.2.

 

This note would replace all of the text between NOTE 4 and NOTE 5 in your contribution.

 

I don't think NOTE 5 is needed at all and is actually bad practice for privacy, but I'll let it go for now.

 

Cheers,

 

Mike

 

Cheers,

 

Mike

 

 

 

On Wed, Jun 5, 2024 at 12:45 PM Alfred Asterjadhi <asterjadhi@xxxxxxxxx> wrote:

[+ TGbe reflector]

 

On Tue, Jun 4, 2024 at 8:09 PM Jay Yang <yang.zhijie@xxxxxxxxxx> wrote:

Hi TGbe , TGbh memebers ,

 

I'm still working on the task to extend 11bh feature for MLO , please help review the latest proposed text(https://mentor.ieee.org/802.11/dcn/24/11-24-0305-07-00be-cr-for-rcm-relevant-cids.docx).  In order to meet 11be timeline  and Wi-Fi industry timeline requirement , it's great appreciated if   we could reach consensus in this round.

 

See the summary of the main change in this revision as bellow:

1) According to Binita 's comments in May session, I add the case of the usage of IRM when a non-AP MLD may become a non-AP STA, or vice versa.

2) Add the extension in FILS authentication as MLO FILS authentication was included into 11be draft6.0(also, 11bh draft already define the usage of the two features in FILS authentication in draft4.0).  

 

Welcome further questions and comments.  

 

 

Thanks

 

Best Regards

 

Jay Yang (杨志杰)

 

 

To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1


 

--

Alfred Asterjadhi , PhD

IEEE802.11 TGbe /TGbn Chair,

Qualcomm Technologies Inc.

Cell #:    +1 858 263 9445

Office #: +1 858 658 5302

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1

 

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1



--
Alfred Asterjadhi , PhD
IEEE802.11 TGbe /TGbn Chair,
Qualcomm Technologies Inc.
Cell #:    +1 858 263 9445
Office #: +1 858 658 5302

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1


To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1


To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1