Thanks for these updates. I will review your and Alfred's responses and
provide feedback.
Separate from this, I've also discussed the draft proposal with colleagues,
and have the following additional comments/questions:
- It is not entirely clear for a Trigger frame (a) whether the User Info fields
with the PN come before those with the MIC (b) whether they can have any
other User Info fields between them or (c) whether they can have any other
User Info fields among them. And if the answers are yes, no and no respectively,
why do we have to have different AID12s for the fields with the PN and
those with the MIC?
- In the case of MU-BAR Trigger frames, the length of the Trigger Dependent
User Info fields is variable, specifically a function of the information
in the BAR Control field, which is the first field in the TDUI. However,
for the User Info fields carrying part of the PN or MIC, there is no
Bar Control field (the TDUI is just 0). So how is the length of the
Trigger Dependent User Info fields for the User Info fields carrying the
PN or MIC in an MU-BAR Trigger frame determined? (I think there's the
same problem for Ranging frames.)
- The use of PNs is not clear:
* For unicast, it says "The non-AP STA and the AP shall maintain a PN"
and it's not clear whether this means an AP shall have or just can have
a single PN for all its STAs (or can have one per peer)
* For unicast, it is not clear what the PN is initialised to, except
that the 4 msbs are 1 (which I assume means all-ones, though this is
ambiguous). What about the 44 lsbs? Can they be all-ones too (I think
not)?
* How does "A single PN space" differ from "A single PN [counter]"?
* It is not clear when PNs are incremented. I think it'd be much better
to be like 12.5.2.3.1 General where it explicitly says that the PN is
preincremented -- and then if you do that then you can initialise
to 0 not 1
- Is 32 us padding going to be sufficient for all implementations, or
should higher padding durations be supported?
- The PN is included in the MIC twice, both as the part of the frame
the MIC is computed over, and as part of the nonce -- is this intentional
and desirable?
- The CIGTK key hierarchy is not clear: "A STA shall use bits 0–255 of
the CIGTK as the GMAC-256 key for protecting group addressed Control frames."
but how many bits does a CIGTK have and what are the rest of the bits
used for?
- The fields over which the MIC is calculated are duplicated in 12.5.x.6
and in 12.5.x.7. This should be specified in one place only
- Why "the non-negative integer inserted into the PN field" rather than
just "the PN field"?
- 9.3.1.22 refers to the "Control MIC field" but there is no such field
in a Trigger frame (only in a BlockAckReq frame)
- There's some weird terminology with a "verifier". I realise this is
also in the baseline but I'll complain in comment collection for those
and this should not be made wider
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
1 Cambridge Square, Cambridge CB4 0AE Fax: +44 1223 434601
ROYAUME UNI WWW:
http://www.samsung.com/uk
From: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Sent: Wednesday, 12 March 2025 18:48
To: Mark Rison <m.rison@xxxxxxxxxxx>; STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11] Solicit feedback for document 11-25/260
Hi Mark,
Thanks for the detailed comments.
I have worked with Alfred to accommodate your suggested editorial revision. The latest revision is uploaded to reflect the changes.
Best,
Po-Kai
From: *** IEEE STDS-802-11 List *** <STDS-802-11@xxxxxxxxxxxxxxxxx>
On Behalf Of Mark Rison
Sent: Wednesday, March 12, 2025 4:05 AM
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] Solicit feedback for document 11-25/260
--- This message came from the IEEE 802.11 Working Group Reflector ---
Thank you for this, Po-Kai. I attach my comments, which are a mix of
technical and editorial.
I continue to have a more general concern that this is adding a
lot of complexity (and consequently likelihood of interop problems)
and overhead for an attack of dubious significance (there are
better/easier ways to DoS or to cause power consumption at a victim).
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
1 Cambridge Square, Cambridge CB4 0AE Fax: +44 1223 434601
ROYAUME UNI WWW:
http://www.samsung.com/uk
From: *** IEEE STDS-802-11 List *** <STDS-802-11@xxxxxxxxxxxxxxxxx>
On Behalf Of Huang, Po-kai
Sent: Tuesday, 11 March 2025 12:46
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11] Solicit feedback for document 11-25/260
--- This message came from the IEEE 802.11 Working Group Reflector ---
Hi,
I presented document 11-25/260 in revmf session yesterday and I am working on addressing the comments received during the presentation.
As instructed, I send this email to see if there are further feedbacks for the document.
Please let me know if you have further feedbacks.
Best,
Po-Kai
To unsubscribe from the STDS-802-11 list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1
|
|
To unsubscribe from the STDS-802-11 list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1
To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1