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

[Mark Rison <m.rison@xxxxxxxxxxx>]

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

Thanks, Dan.

 

I would like to suggest using the following table, as I think it is

more systematically laid out and easier to follow (and the last two

rows of the table in 21/0735r0 overlap and are unclear as to the

N/A behaviour; plus there is no explanation of the "should"):

 

Non-AP STA MFPC	Non-AP STA MFPR	Non-AP STA action	AP MFPC	AP MFPR	AP action	PMF used?
0	0	The STA may associate with the AP	0	0	The AP may accept associations from the STA	No
1	0	The STA may associate with the AP	0	0	The AP may accept associations from the STA	No
0	0	The STA may associate with the AP	1	0	The AP may accept associations from the STA	No
1	0 or 1	The STA may associate with the AP	1	0 or 1	The AP may accept associations from the STA	Yes
1	1	The STA shall not associate with the AP	0	0	N/A	N/A
0	0	The STA should not associate with the AP (see NOTE)	1	1	The AP shall reject associations from the STA with the Status Code ROBUST_MANAGEMENT_POLICY_VIOLATION	N/A
0	1	The STA shall not use this combination				N/A
			0	1	The AP shall not use this combination	N/A
NOTE—STAs conformant with a previous revision of this standard might not ascribe a meaning to the MFPC and MFPR subfields.

 

I also suggest making the following changes:

 

- On page 1094:

 

— Bit 6: MFPR. A STA sets this bit to 1 to advertise that protection of robust Management frames is

mandatory. A STA sets this bit to 1 when dot11RSNAProtectedManagementFramesActivated is

true and dot11RSNAUnprotectedManagementFramesAllowed is false; otherwise it sets this bit to 0.

If a STA sets this bit to 1, then that STA only allows RSNAs with STAs that provide Management

Frame Protection.

— Bit 7: MFPC . A STA sets this bit to 1 when dot11RSNAProtectedManagementFramesActivated is

true to advertise that protection of robust Management frames is enabled.

 

->

 

— Bit 6: MFPR. A STA sets this bit to 1 when dot11RSNAProtectedManagementFramesActivated is

true and dot11RSNAUnprotectedManagementFramesAllowed is false

to advertise that protection of robust Management frames is

mandatory; otherwise it sets this bit to 0.

— Bit 7: MFPC. A STA sets this bit to 1 when dot11RSNAProtectedManagementFramesActivated is

true to advertise that protection of robust Management frames is enabled; otherwise it sets this bit to 0.

 

- On page 2598:

 

An AP shall use Table 12-5 (Robust management frame selection in an infrastructure BSS) and the values of

the MFPC and MFPR bits advertised in the RSNEs to determine if it may associate with a non-AP STA. An

non-AP STA shall use Table 12-5 (Robust management frame selection in an infrastructure BSS) and the

values of the MFPC and MFPR bits advertised in the RSNEs to determine if it may associate with an AP.

Management frame protection is enabled when dot11RSNAProtectedManagementFramesActivated is set to 1.

Management frame protection is negotiated when an AP and non-AP STA set the Management Frame

Protection Capable field to 1 in their respective RSNEs in the (re)association procedure, and both parties

confirm the Management Frame Protection Capable bit set to 1 in the 4-way handshake, FT 4-way handshake,

FT fast BSS transition protocol, or the (Re)Association Request and (Re)Association Response frames of FILS

authentication.

 

->

 

An AP shall use Table 12-5 (Robust management frame selection in an infrastructure BSS) and the values of

the MFPC and MFPR bits advertised in the RSNEs to determine if it may accept an association request from a non-AP STA, and if so whether management frame protection is enabled. An

non-AP STA shall use Table 12-5 (Robust management frame selection in an infrastructure BSS) and the

values of the MFPC and MFPR bits advertised in the RSNEs to determine if it may request association with an AP, and if so whether management frame protection is enabled.

 

I'm not sure about the "and both parties

confirm the Management Frame Protection Capable bit set to 1 in the 4-way handshake, FT 4-way handshake,

FT fast BSS transition protocol, or the (Re)Association Request and (Re)Association Response frames of FILS

authentication."  Is it possible for either party not to confirm this?  What

happens in that case?

 

- At 2610.41 from a STA that advertised MFPC = 1 -> from any STA that advertised MFPC = 1

 

- In 12.6.20 delete "A STA with dot11RSNAProtectedManagementFramesActivated equal to true shall negotiate management

frame protection with a STA that advertised MFPC = 1."

 

I think we also need to fix the IBSS table (12-6, referred to from 12.6.5),

but note it needs to be extended for PBSS and TDLS and maybe also MBSS.  Work in progress:

 

STA MFPC	STA MFPR	STA action	Peer STA MFPC	Peer STA MFPR	Peer STA action	PMF used?	Valid in IBSS?
0	0	The STA may exchange data with the peer STA	0	0	The peer STA may exchange data with the STA	No	Yes
0	0	The STA may exchange data with the peer STA	1	0	The peer STA may exchange data with the STA	No	No
1	0	The STA may exchange data with the peer STA	0	0	The peer STA may exchange data with the STA	No	No
1	0 or 1	The STA may exchange data with the peer STA	1	0 or 1	The peer STA may exchange data with the STA	Yes	Only if MFPR is 1 at both STAs
1	1	The STA shall not exchange data nor establish a security association with the peer STA	0	0	N/A	N/A	N/A
0	0	The STA should not exchange data nor establish a security association with the peer STA (see NOTE)	1	1	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	N/A
0	1	The STA shall not use this combination				N/A	N/A
			0	1	The peer STA shall not use this combination	N/A	N/A
NOTE—STAs conformant with a previous revision of this standard might not ascribe a meaning to the MFPC and MFPR subfields.

 

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: Harkins, Daniel <daniel.harkins@xxxxxxx>
Sent: Monday, 26 April 2021 20:50
To: Mark Rison <m.rison@xxxxxxxxxxx>; STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Cc: Thomas Derham <thomas.derham@xxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGM] 11me/D0.0 CID 587 (MFPC/MFPR horror)

 

 

  I uploaded 11-21/0735/r0 to mentor. It should address this comment. Please take a look.

 

  Dan.

 

--

"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

 

 

 

On 4/26/21, 10:34 AM, "Mark Rison" <m.rison@xxxxxxxxxxx> wrote:

 

Hello,

 

So having re-examined my proposal, specifically

 

Non-AP STA MFPC	Non-AP STA MFPR	Non-AP STA action	AP MFPC	AP MFPR	AP action	PMF used?
0	0	The STA may associate with the AP	0	0	The AP may accept associations from the STA	No
1	0	The STA may associate with the AP	0	0	The AP may accept associations from the STA	No
0	0	The STA may associate with the AP	1	0	The AP may accept associations from the STA	No
1	0 or 1	The STA may associate with the AP	1	0 or 1	The AP may accept associations from the STA	Yes
1	1	The STA shall not associate with the AP	0	0	N/A	N/A
0	0	The STA should not associate with the AP (see NOTE)	1	1	The AP shall reject associations from the STA with the Status Code ROBUST_MANAGEMENT_POLICY_VIOLATION	N/A
0	1	The STA shall not use this combination				N/A
			0	1	The AP shall not use this combination	N/A
NOTE—STAs conformant with a previous revision of this standard might not ascribe a meaning to the MFPC and MFPR subfields.

 

in the light of the discussion today.  I think it meets all of the

key requirements discussed:

 

- Does not impose requirements on a STA (AP or not) that conforms

to a revision of the 802.11 spec before 802.11w was approved

(I've highlighted this in cyan)

 

- Ensures that if a pre-802.11w STA attempts to associate with an

AP that requires MFP, the association will be denied (I've highlighted

this in yellow).  There are no situations in which there could be

doubt as to whether PMF will be used on a link

 

As discussed, it does not attempt to define AP behaviour in the

face of a nonconformant STA, i.e. a non-AP STA that has MFPR = 1

and attempts to associate with an AP that has MFPC = 0, or a STA

(AP or not) that sets MFPC = 0 and MFPR = 1.  I remain unconvinced

but persuadable that in this case we should define such behaviour.

 

During the call there was a suggestion that the STA's policy might

differ from what the STA advertises in the RSN capabilities.  I

don't think that's the case: the policy (in the MIB) and what is

advertised are directly linked:

 

— Bit 6: MFPR. A STA sets this bit to 1 to advertise that protection of robust Management frames is

mandatory. A STA sets this bit to 1 when dot11RSNAProtectedManagementFramesActivated is

true and dot11RSNAUnprotectedManagementFramesAllowed is false; otherwise it sets this bit to 0.

If a STA sets this bit to 1, then that STA only allows RSNAs with STAs that provide Management

Frame Protection.

— Bit 7: MFPC . A STA sets this bit to 1 when dot11RSNAProtectedManagementFramesActivated is

true to advertise that protection of robust Management frames is enabled.

 

I suppose we should add "; otherwise it sets this bit to 0" to the MFPC one, though.

 

Finally, I unwithdraw my withdrawal of my support for the notion that

the MFPR bit from the non-AP STA doesn't really matter over the air.

As can be seen in the table above (I've highlighted this in green),

given the only permissible combinations, the use of PMF ends up only

depending on the MFPC at both sides; it is not dependent on the MFPR

setting at the non-AP STA.

 

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: Mark Rison
Sent: Monday, 26 April 2021 07:05
To: 'Thomas Derham' <thomas.derham@xxxxxxxxxxxx>
Cc: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGM] 11me/D0.0 CID 587 (MFPC/MFPR horror)

 

Hello Thomas,

 

If the non-AP STA has PMF enabled (i.e. MFPC=1) […]

- If the peer AP has MFPC=0 and the STA decided to associate (presumably because its local policy allows a non-PMF association), then:
[…]

   - If STA set MFPR=1 (which would seem to contradict its local policy), assoc might or might not succeed (depending how ’no action’ is interpreted) and PMF is not negotiated

I don't think the STA is allowed to associate in this case:

 

 

Here are my latest ideas on how to present this.  Note I've reordered

the columns.  The row above becomes a "N/A" for the AP, since it's

a "shall not" at the notional initiator (the STA).

 

Non-AP STA MFPC	Non-AP STA MFPR	Non-AP STA action	AP MFPC	AP MFPR	AP action	PMF used?
0	0	The STA may associate with the AP	0	0	The AP may accept associations from the STA	No
1	0	The STA may associate with the AP	0	0	The AP may accept associations from the STA	No
0	0	The STA may associate with the AP	1	0	The AP may accept associations from the STA	No
1	0 or 1	The STA may associate with the AP	1	0 or 1	The AP may accept associations from the STA	Yes
1	1	The STA shall not associate with the AP	0	0	N/A	N/A
0	0	The STA should not associate with the AP (see NOTE)	1	1	The AP shall reject associations from the STA with the Status Code ROBUST_MANAGEMENT_POLICY_VIOLATION	N/A
0	1	The STA shall not use this combination				N/A
			0	1	The AP shall not use this combination	N/A
NOTE—STAs conformant with a previous revision of this standard might not ascribe a meaning to the MFPC and MFPR subfields.

 

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: Monday, 26 April 2021 03:13
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)

 

Hi Mark

 

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

 

Thanks. Yes agree, and that is essentially my point - the differences in behavior you mention above are both local policy decisions at the non-AP STA.
If the non-AP STA has PMF enabled (i.e. MFPC=1), and the STA chooses to associate with a given AP, then it might as well always set MFPR=0 - the value is essentially irrelevant to the protocol. Specifically:
- If the peer AP has MFPC=1 then assoc succeeds and PMF is negotiated (no matter whether STA’s MFPR was 0 or 1)
- If the peer AP has MFPC=0 and the STA decided to associate (presumably because its local policy allows a non-PMF association), then:
   - If STA set MFPR=0 (which would be consistent with its local policy of allowing non-PMF associations), assoc succeeds and PMF is not negotiated
   - If STA set MFPR=1 (which would seem to contradict its local policy), assoc might or might not succeed (depending how ’no action’ is interpreted) and PMF is not negotiated

Thanks
Thomas

On Apr 24, 2021, at 3:28 AM, Mark Rison <m.rison@xxxxxxxxxxx> wrote:

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


On Apr 23, 2021, at 5:06 PM, Mark Rison <m.rison@xxxxxxxxxxx> wrote:
 
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
ROYAUME UNI                             WWW: http://www.samsung.com/uk
 
From: Thomas Derham <00000ad2eabc2931-dmarc-request@xxxxxxxxxxxxxxxxx> 
Sent: Saturday, 24 April 2021 00:12
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] 11me/D0.0 CID 587 (MFPC/MFPR horror)
 
--- 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).
 
-Thomas
 



On Apr 23, 2021, at 3:58 PM, Mark Rison <m.rison@xxxxxxxxxxx> wrote:
 
> d.       Feedback request - Dan Harkins – CID 587

Having looked at 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
 
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
 
 
 
 
- 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
in an IBSS
 
So I agree with the comment that there is a need to
"Clarify since it is a frequent source of confusion"!
 
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: M Montemurro <montemurro.michael@xxxxxxxxx> 
Sent: Friday, 23 April 2021 19:13
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGM] Teleconference Reminder: Monday April 26 at 10am ET
 
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hi all,
 
I just wanted to remind everyone that REVme will meet on Monday at 10am ET. The full agenda doc is posted here:
https://mentor.ieee.org/802.11/dcn/21/11-21-0656-02-000m-april-may-revme-teleconference-agenda.docx
 
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 <>
   
Cheers,
 
Mike
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
 
--
"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