Re: [STDS-802-11-TGM] 11me/D0.0 CID 587 (MFPC/MFPR horror)

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

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.

I'm not sure what you mean by "how the non-AP STA sets MFPR iff the non-AP STA sets MFPC=1".

If MFPC=1 at the non-AP STA, then the STA is in full control:

it can set MFPR=1 and then refuse to associate with an AP that does

not set MFPC=1, or it can set MFPR=0 and then associate with any AP

that doesn't signal the invalid MFPC+MFPR combination. In all cases

PMF is used iff MFPC=1 on both sides.

>> 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.

OK. As I said initially I do agree "No action" is unclear, and anyway

I can't work out the logic behind which combinations are "No action"

(the first in the table makes sense from the perspective of an AP

that conforms to the standard prior to 802.11w, but the second does

not, and some situations where a STA that conforms to the standard

prior to 802.11w should similarly result in "No action" don't

(e.g. 1100)).

Would some "should"s do the trick?

That seems potentially one reasonable option for discussion.

OK, how about this (I'm leaning towards the "N/A" option in the

"[or N/A?]" cells, since I don't think we're in the business of

defining the behaviour for non-compliant devices or their peers;

in fact maybe all the rows with "shall not use" should just become

one big "Reserved")?

AP MFPC	AP MFPR	STA MFPC	STA MFPR	Non-AP 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_POLICY_VIOLATION (see NOTE) [or N/A?]	N/A
1	1	0	0	The STA should not associate with the AP (see NOTE)	The AP shall reject associations from the STA with the Status Code ROBUST_MANAGEMENT_POLICY_VIOLATION	N/A
0 or 1	0 or 1	0	1	The STA shall not use this combination	N/A	N/A
0	1	0	0	The STA should not associate with the AP (see NOTE) [or N/A?]	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 [or N/A?]	The AP shall not use this combination	N/A
NOTE—STAs conformant with previous revisions of this standard might not ascribe a meaning to the MFPC and MFPR subfields.

Similarly, here is what Table 12-6—Robust management frame selection in an IBSS

might say. Per some other comments, this table should be extended to apply to

TDLS (and maybe also PBSS and MBSS?) -- though TDLS postdates PMF so shouldn't

need the waiver (ditto PBSS). Same N/A and "shall not use" considerations as above.

STA MFPC	STA MFPR	Peer STA MFPC	Peer STA MFPR	STA action	Peer STA action	PMF used?
0	0	0	0	The STA may exchange data with the peer STA	The peer STA may exchange data with the STA	No
0	0	1	0	The STA may exchange data with the peer STA	The peer STA may exchange data with the STA	No
1	0	0	0	The STA may exchange data with the peer STA	The peer STA may exchange data with the STA	No
1	0 or 1	1	0 or 1	The STA may exchange data with the peer STA	The peer STA may exchange data with the STA	Yes
1	1	0	0	The STA shall not exchange data nor establish a security association with the peer STA	The peer STA should not exchange data with the STA and should reject security association attempts from the STA with the Status Code ROBUST_MANAGEMENT_POLICY_VIOLATION (see NOTE) [or N/A?]	N/A
0	0	1	1	The STA should not exchange data nor establish a security association with the peer STA (see NOTE)	The peer STA shall not exchange data with the STA and shall reject security association attempts from the STA with the Status Code ROBUST_MANAGEMENT_POLICY_VIOLATION	N/A
0	1	0 or 1	0 or 1	The STA shall not use this combination	N/A	N/A
0	0	0	1	The STA should not exchange data nor establish a security association with the peer STA (see NOTE) [or N/A?]	The peer STA shall not use this combination	N/A
0 or 1	0 or 1 (not 0 if STA MFPC also 0)	0	1	The STA shall not exchange data nor establish a security association with the peer STA [or N/A?]	The peer STA shall not use this combination	N/A
NOTE—STAs conformant with previous revisions of this standard might not ascribe a meaning to the MFPC and MFPR subfields.

See also CIDs 199, 200, 202:

CID 199

12.6.3

There is information on how MFP is negotiated for infrastructure BSS (Table 12-5--Robust management frame selection in an infrastructure BSS) and for IBSS (Table 12-6--Robust management frame selection in an IBSS) but not for TDLS. More generally, the use of MFP on a TDLS direct link is lacking (there's just "After receiving a Deauthentication frame or a Disassociation frame from the AP, a Deauthentication frame with Reason Code LEAVING_NETWORK_DEAUTH shall be transmitted via the direct path to all TDLS peer STAs that are in the awake state, if management frame protection has not been negotiated on the TDLS direct link." buried in 11.20.5 TDLS direct-link teardown)

Change "Table 12-6--Robust management frame selection in an IBSS" to "Table 12-6--Robust management frame selection in an IBSS or between TDLS peer STAs". In that table change "The peer STA shall not" to "The STA shall not". At 2598.50 change "An STA" to "A STA" and after that sentence add "A TDLS STA shall use Table 12-6 and the
values of the MFPC and MFPR bits advertised in the RSNEs to determine if it may establish a TDLS link with another a TDLS peer STA."

CID 200

12.6.19

This subclause talks of "associated STA" but MFP can be used with IBSS and TDLS too

Change "associated STA" to "associated or peer STA" throughout this subclause

CID 202

11.20.4

2321.20

"If enabled, management frame protection shall only be used as a required feature (MFPR) in an IBSS." -- what does this mean? It might be trying to say that in an IBSS if you're going to do MFP you have to set MFPR, but that's contradicted by Table 12-6--Robust management frame selection in an IBSS. Even with the "only" (a word that always massively increases the risk of ambiguity) it's not clear what it might be trying to say

Delete the cited sentence

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

ROYAUME UNI WWW: http://www.samsung.com/uk

From: Thomas Derham <thomas.derham@xxxxxxxxxxxx>
Sent: Saturday, 24 April 2021 01:40
To: Mark Rison <m.rison@xxxxxxxxxxx>
Cc: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] 11me/D0.0 CID 587 (MFPC/MFPR horror)

Thanks Mark.