Re: [STDS-802-11-TGBE] Updated SEC comment resolutions for LB 266

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

Hi Guogang,

I do not understand why you just point this to me. I believe when you present last time (in the minute that I cite), all the comments that are not in favor of this direction are from other members. I am also not in favor of this direction, but I do not understand why you want to just target me on this.

Best,
Po-Kai

From: huangguogang <000017b1384624cd-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, October 12, 2022 7:37 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Updated SEC comment resolutions for LB 266

Hi Po-kai,

I sent my response in the last email thread. And I didn’t get your further response any more. I can summarize my response again.

I don’t think your so-called technical issue is a real one. In order to go with Option 3, what we need to change is just to mandatorily include a Multi-link Link Information element within the frame body for the link-specific Management frame. Otherwise, it will complicate the MLO operation. Specifically,

l Obviously, it will complicate the encryption/decryption of the individually addressed frame

l It will complicate the transmission of the individually addressed Management frame. Because in that case, after the MPDU Encryption, the AP MLD shall check each individually addressed MMPDU is link-specific or not. If it is a link-specific, then the AP MLD needs to further check whether a Multi-link Link Information element is include or not. Thus the AP MLD can select a correct link to transmit this MMPDU.

l It’s not good for the non-AP MLD’s power save. Assuming that a buffered BU is a link-specific MMPDU and no Multi-link Link Information element is included, the target STA needs to wake up to retrieve it even there is an affiliated STA in the awake state.

I really don’t know why you want complicate the MLO operation.

Regards

Guogang Huang

发件人: M Montemurro [mailto:montemurro.michael@xxxxxxxxx]
发送时间: 2022年10月12日 2:15
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] Updated SEC comment resolutions for LB 266

Hi Po-kai,

Thanks for your response.

I'll update CID 13599 with the text you suggest removed.

For CID 12322, I could use the information from the minutes but I'd like to get feedback from others where the points from the minutes are sufficient to address a technical response.

I updated a revision to the document.

Cheers,

Mike

On Fri, Oct 7, 2022 at 4:12 PM Huang, Po-kai <po-kai.huang@xxxxxxxxx> wrote:

Hi Mike,

                Thanks for preparing the resolution, for CID 13599, I think since we say PTK is between two MLDs, the reply check for data should be based on two MLD for any case without the following yellow condition. This will also include TDLS between MLDs. Hence, I think we need to remove yellow below.



If the To DS or From DS subfields in the MAC header of the MPDU are not both equal to 0, and the MPDU is an individually addressed Data frame transmitted by a STA affiliated with an MLD, the receiver shall discard any Data frame that is received with a PN less than or equal to the value of the replay counter that is associated with the transmitter MLD MAC address and priority value of the received MPDU.

                For CID 12322, I sent the following email before on 08/17. Can you craft reasons based on the minutes of previous discussion?

Hi Mike,

                As I have mentioned in the call, I believe this has been brought up several times in the calls, and technical reasons/discussions are available in the past. I cite the meeting minutes for this discussion in the past below.

https://mentor.ieee.org/802.11/dcn/22/11-22-0754-02-00be-minutes-of-tgbe-2022-may-interim-mac.docx

Technical Submissions:

704r1 CR for ML Security for Individually addressed Management Frame           Guogang Huang     [2C      10]

Discussion:

C: some concerns. link specific information should be used to protect the message. By using MLD address, the link specific information is missing. The change is too late.

A: link ID is used to indicate the intended link. There should be no security issue.

C: wth link ID in the frme body, there should be no issue. But the inclusion of link ID in the frame body is not mandatory.

C: the proposal is the good method.

C: disagree with the comment. The discussion is wrong. The change is too late.

A: link ID will be always in the frame body.

C: this is not true.

SP: Do you support to accept the resolution in 11-22/704r1 for the following CIDs?

5181 and 5184

23Y, 51N, 30A

Best,

Po-kai

Best,

Po-Kai

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Friday, October 07, 2022 10:45 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] Updated SEC comment resolutions for LB 266

Hello all,

I updated the deterred resolutions and posted https://mentor.ieee.org/802.11/dcn/22/11-22-1178-04-00be-tgbe-lb266-security-comment-resolutions.docx based on discussions during the presentation of the document.

The only open comment is CID 12322. My feeling was that the consensus was to reject the comment. However to do so, I need a technical rejection reason that is responsive to the comment. I posted an email to the TGbe reflector a couple of months ago and still have not heard any feedback.

Cheers,

Mike

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