| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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
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> 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 |