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

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

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:

 

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