--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Thanks Mark.The original motivation of the comment was to clarify whether or not there is any meaning, from a protocol perspective, in how the non-AP STA sets MFPR iff the non-AP STA sets MFPC=1. But to answer that question, we first need to agree/clarify what behaviors the current standard requires (on the AP) with respect to the MFPR value (from the STA). Of course, other related clarifications could be beneficial too.
>> On what basis do you say "cannot be expected" here? It seems to me that the 802.11-2020 spec does in fact expect exactly that.
The current standard says “No action”. I don’t know whether that means “take no action when the association request [with the invalid PMF configuration] is received” (and therefore do not respond), or whether it means “take no action based on the values of the PMF bits” (and therefore, in terms of responding to the association request, do whatever you were planning to do regardless of MFP values), or something else. In any case, I assume the intent when this table was introduced was not to retrospectively add new requirements on legacy STAs.
Would some "should"s do the trick?
That seems potentially one reasonable option for discussion.
Thanks -Thomas
Ah, now I see what the comment is about! I think this table needs to be compatible with 802.11 devices that support RSNA but don’t support PMF, and therefore set MFPC=0 and MFPR=0. Such APs cannot be expected to identify a MFP policy violation made by the STA, and so might or might not accept the (invalid) request from the STA (in row 6). On what basis do you say "cannot be expected" here? It seems to me that the 802.11-2020 spec does in fact expect exactly that. So are you basically proposing a spec change to support devices that don't comply with the 2020 spec? Or is the argument that MFPC/MFPR was introduced after the initial RSN Capabilities stuff, and not introduced in a backward-compatible way? The same might be true for a STA that does not support MFP and encounters an AP with an invalid policy (final row). Would some "should"s do the trick? AP MFPC | AP MFPR | STA MFPC | STA MFPR | STA action | AP action | PMF used? | 0 | 0 | 0 | 0 | The STA may associate with the AP | The AP may accept associations from the STA | No | 0 | 0 | 1 | 0 | The STA may associate with the AP | The AP may accept associations from the STA | No | 1 | 0 | 0 | 0 | The STA may associate with the AP | The AP may accept associations from the STA | No | 1 | 0 or 1 | 1 | 0 or 1 | The STA may associate with the AP | The AP may accept associations from the STA | Yes | 0 | 0 | 1 | 1 | The STA shall not associate with the AP | The AP should reject associations from the STA with the Status Code
ROBUST_MANAGEMENT_P
OLICY_VIOLATION
[or N/A?] | N/A | 1 | 1 | 0 | 0 | The STA should not associate with the AP | The AP shall reject associations from the STA with the Status Code
ROBUST_MANAGEMENT_P
OLICY_VIOLATION | N/A | 0 | 0 | 0 | 1 | The STA shall not use this combination | The AP should reject associations from the STA with the Status Code
ROBUST_MANAGEMENT_P
OLICY_VIOLATION [or N/A?] | N/A | 0 or 1 | 0 or 1 (not 0 if AP MFPC also 0) | 0 | 1 | The STA shall not use this combination | The AP shall reject associations from the STA with the Status Code
ROBUST_MANAGEMENT_P
OLICY_VIOLATION [or N/A?] | N/A | 0 | 1 | 0 | 0 | The STA should not associate with the AP | The AP shall not use this combination | N/A | 0 | 1 | 0 or 1 | 0 or 1 (not 0 if STA MFPC also 0) | The STA shall not associate with the AP | The AP shall not use this combination | N/A |
Thanks, Mark -- Mark RISON, Standards Architect, WLAN English/Esperanto/Français Samsung Cambridge Solution Centre Tel: +44 1223 434600 Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601 --- This message came from the IEEE 802.11 Task Group M Technical Reflector --- Thanks for this discussion. I think this table needs to be compatible with 802.11 devices that support RSNA but don’t support PMF, and therefore set MFPC=0 and MFPR=0. Such APs cannot be expected to identify a MFP policy violation made by the STA, and so might or might not accept the (invalid) request from the STA (in row 6). The same might be true for a STA that does not support MFP and encounters an AP with an invalid policy (final row).
> d. Feedback request - Dan Harkins – CID 587 I don't even understand Table 12-5—Robust management frame selection in an infrastructure BSS: - What does "No action" mean under "AP action"? That's basically why I'm asking for time. I want to see if there's some consensus about what the behavior should be. - Why is the AP behaviour not the same for all the "The STA shall not [try to] associate with the AP" cases, specifically "The AP shall reject associations from the STA with the Status Code ROBUST_MANAGEMENT_POLICY_VIOLATION"? At least the ones where the AP isn't advertising an invalid combination! Well if you can make the case that they should all be the same then I'd like to hear it. In fact, if you think you know how the CID should be resolved and what the necessary clarification is I'll be happy to reassign the CID to you. Lemme know. Well, just thinking aloud, how about: AP MFPC | AP MFPR | STA MFPC | STA MFPR | STA action | AP action | PMF used? | 0 | 0 | 0 | 0 | The STA may associate with the AP | The AP may accept associations from the STA | No | 0 | 0 | 1 | 0 | The STA may associate with the AP | The AP may accept associations from the STA | No | 1 | 0 | 0 | 0 | The STA may associate with the AP | The AP may accept associations from the STA | No | 1 | 0 or 1 | 1 | 0 or 1 | The STA may associate with the AP | The AP may accept associations from the STA | Yes | 0 | 0 | 1 | 1 | The STA shall not associate with the AP | The AP shall reject associations from the STA with the Status Code
ROBUST_MANAGEMENT_P
OLICY_VIOLATION
[or N/A?] | N/A | 1 | 1 | 0 | 0 | The STA shall not associate with the AP | The AP shall reject associations from the STA with the Status Code
ROBUST_MANAGEMENT_P
OLICY_VIOLATION [or N/A?] | N/A | 0 or 1 | 0 or 1 | 0 | 1 | The STA shall not use this combination | The AP shall reject associations from the STA with the Status Code
ROBUST_MANAGEMENT_P
OLICY_VIOLATION [or N/A?] | N/A | 0 | 1 | 0 or 1 | 0 or 1 | The STA shall not associate with the AP | The AP shall not use this combination | N/A |
Mark RISON, Standards Architect, WLAN English/Esperanto/Français Samsung Cambridge Solution Centre Tel: +44 1223 434600 Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601 - That table covers 13 combinations, so what about the other 3? I think these are 0001, 0100, 0101 (all invalid at the AP and/or STA). This is also true for Table 12-6—Robust management frame selection So I agree with the comment that there is a need to "Clarify since it is a frequent source of confusion"! Mark RISON, Standards Architect, WLAN English/Esperanto/Français Samsung Cambridge Solution Centre Tel: +44 1223 434600 Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601 --- This message came from the IEEE 802.11 Task Group M Technical Reflector --- I just wanted to remind everyone that REVme will meet on Monday at 10am ET. The full agenda doc is posted here: The agenda for the CC35 comment resolutions (the bulk of the meeting) will be: a Document 11-21/695r0 – Michael Montemurro (Huawei) – CIDs 51-80 (20 min)
b. https://www.ieee802.org/11/email/stds-802-11-tgm/msg02118.html– Mark Rison (Samsung) – CIDs (remaining time to 1hr)
c. Document <> - Edward Au (Huawei) – Editor 2 CIDs
d. Feedback request - Dan Harkins – CID 587
e. Document 11-21/688r0 - Ganesh Venkatesan (Intel) – CIDs <>
"the object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." – Marcus Aurelius
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
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
|