Re: [STDS-802-11-TGM] 11me/D0.0 CID 193 (per-whatness of RCs)

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

In the comment, it is posited that “this is perhaps tx not rx though”. How does the concept of traffic class / priority apply to received packets/frames/streams, and why would that be relevant to replay detection?

Also, “The receiver shall maintain a separate set of replay counters…” is interesting but generally not testable. How receivers implement replay detection is an internal matter and should not be mandated. Yes, it’s obvious that one way to do it is to implement separate replay counters for each …, but unless you scan the silicon with an electron microscope, you’ll never know exactly how the detection functionality was implemented. At best, you could make all suppliers check the PICS box that says they are conformant to that specification and of course they’d do it because they know you can neither prove nor enforce it. At worst, you could require the recipient of a replayed packet to “transmit something to someone” which you could then (almost) test, but that simply introduces a force multiplier into the DoS underway which would not be particularly wise.

My two cents …

From: Mark Rison [mailto:m.rison@xxxxxxxxxxx]
Sent: Thursday, August 26, 2021 5:05 AM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] 11me/D0.0 CID 193 (per-whatness of RCs)

Sorry, I found a mistake in my proposed resolution for CID 171:

the CCMP/GCMP replay rules also apply to unicast MMPDUs. Update:

Identifiers

Comment

Proposed change

CID 171

Mark RISON

12.5.3.4.4

It is not clear what replay counter to use for non-QoS Data frames. 5.1.1.3 suggests TID 0: "At QoS STAs associated in a QoS BSS, MSDUs with a priority of Contention are considered equivalent to MSDUs with TID 0." (this is perhaps tx not rx though)

At the end of item b) in 12.5.3.4.4 PN and replay detection and 12.5.5.4.4 PN and replay detection add "For the purposes of replay detection Data frames that have the QoS subfield of the Subtype subfield equal to 0 are treated as having TID 0.". At the start of each subclause change "To effect replay detection," to "To effect replay detection for (QoS) Data frames,"

Discussion:

12.5.3.4.4 does not explicitly cover replay counters for non-QoS Data frames:

The following processing rules are used to detect replay:

a) The receiver shall maintain a separate set of replay counters for each PTKSA, GTKSA, and protocol version value. The receiver initializes these replay counters to 0 when it resets the temporal key for a peer. The replay counter is set to the PN value of accepted CCMP MPDUs.

b) For each PTKSA, GTKSA, and protocol version value, the recipient shall maintain a separate replay counter for each TID, subject to the limitation of the number of supported replay counters indicated in the RSN Capabilities field (see 9.4.2.24 (RSNE)), and shall use the PN from a received frame to detect replayed frames. A replayed frame occurs when the PN from a received frame is less than or equal to the current replay counter value for the frame’s MSDU or A-MSDU priority and frame type.

[…]

d) The receiver shall discard any Data frame that is received with its PN less than or equal to the value

of the replay counter that is associated with the TA and priority value of the received MPDU.

However, d) (but not b)) is using the concept of a “priority value” for the MPDU, which per CID 212 is actually referring to 12.5.3.3.1 General. For PV0 this is:

If the Type field of the Frame Control field is 10 (Data frame) and there is a QoS Control field present in the MPDU header, the priority value of the MPDU is equal to the value of the TID subfield of the QoS Control field (bits 0 to 3 of the QoS Control field). If the Type field of the Frame Control field is 00 (Management frame) and the frame is a QMF, the priority value of the MPDU is equal to the value in the ACI subfield of the Sequence Number field. Otherwise, the priority value of the MPDU is equal to the fixed value 0.

and for PV1 this is:

If the MPDU is a QoS Data MPDU, the priority value of the MPDU is equal to the value of the PTID subfield of the Frame Control field. If the Type field of the Frame Control field is 001 (Management frame) and the frame is a QMF, the priority value of the MPDU is equal to the value in the ACI subfield of the Sequence Number field. Otherwise, the priority value of the MPDU is equal to the fixed value 0.

Note the former does yield 0 for (PV0) non-QoS Data frames. Also note that the reference in b) to the frame type is bogus, since b) is only about Data frames (c) is for robust Management frames).

Also, “To effect replay detection, the receiver extracts the PN from the CCMP header.” is not specific enough. It’s not so extracted for groupcast robust Management frames, which are done under BIP not CCMP (the proposed change is wrong here; this subclause also covers individually addressed robust Management frames too).

Proposed changes:

Change 12.5.3.4.4 PN and replay detection as follows:

To effect replay detection for Data or individually addressed robust Management frames (see 12.5.4.6 (BIP reception) for group addressed robust Management and protected Beacon frames), the receiver extracts the PN from the CCMP header.

[…]

The following processing rules are used to detect replay:

b) For each PTKSA, GTKSA, and protocol version value, the recipient shall maintain a separate replay counter for each ~~TID~~MPDU priority value (see 12.5.3.3.1), subject to the limitation of the number of supported replay counters indicated in the RSN Capabilities field (see 9.4.2.24 (RSNE)), and shall use the PN from a received frame to detect replayed frames. A replayed frame occurs when the PN from a received frame is less than or equal to the current replay counter value for the ~~frame’s MSDU or A-MSDU~~MPDU priority value ~~and frame type~~.

[…]

d) The receiver shall discard any Data frame that is received with its PN less than or equal to the value of the replay counter that is associated with the TA and MPDU priority value ~~of the received MPDU~~.

Change 12.5.5.4.4 PN and replay detection as follows:

a) The receiver shall maintain a separate set of replay counters for each PTKSA and GTKSA. The receiver initializes these replay counters to 0 when it resets the temporal key for a peer. The replay counter is set to the PN value of accepted GCMP MPDUs.

b) For each PTKSA and GTKSA, the recipient shall maintain a separate replay counter for each ~~TID~~MPDU priority value (see 12.5.3.3.1), subject to the limitation of the number of supported replay counters indicated in the RSN Capabilities field (see 9.4.2.24 (RSNE)), and shall use the PN from a received frame to detect replayed frames. A replayed frame occurs when the PN from a received frame is less than or equal to the current replay counter value for the ~~frame’s MSDU or A-MSDU~~MPDU priority value ~~and frame type~~.

[…]

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: Thursday, 26 August 2021 15:29
To: 'M Montemurro' <montemurro.michael@xxxxxxxxx>
Cc: 'stds-802-11-tgm' <STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>; 'Nehru Bhandaru' <nehru.bhandaru@xxxxxxxxxxxx>; Harkins, Daniel (daniel.harkins@xxxxxxx) <daniel.harkins@xxxxxxx>
Subject: RE: [STDS-802-11-TGM] 11me/D0.0 CID 193 (per-whatness of RCs)

> Document 11-21/829 is already on the agenda for the August 30 teleconference as you requested a number of weeks ago.

Ah, yes, thanks.

> Also, I'll assign this comment to you as well since its now in a similar scope area to your interpretation of CID 166.

OK, will add 171 (assigned to Nehru in 21/0684r5) to 21/0829 forthwith.

For the avoidance of doubt: CID 166 is assigned to Dan in 21/0684r5.

In fact here it is (disclaimer: not a submission, can ignore, will put in a

document with Submission in the bottom left, etc.):

Identifiers

Comment

Proposed change

CID 171

Mark RISON

12.5.3.4.4

Discussion:

12.5.3.4.4 does not explicitly cover replay counters for non-QoS Data frames:

The following processing rules are used to detect replay:

[…]

d) The receiver shall discard any Data frame that is received with its PN less than or equal to the value

of the replay counter that is associated with the TA and priority value of the received MPDU.

However, d) (but not b)) is using the concept of a “priority value” for the MPDU, which per CID 212 is actually referring to 12.5.3.3.1 General. For PV0 this is:

and for PV1 this is:

Note the former does yield 0 for (PV0) non-QoS Data frames. Also note that the reference in b) to the frame type is bogus, since b) is only about Data frames (c) is for robust Management frames).

Also, “To effect replay detection, the receiver extracts the PN from the CCMP header.” is not specific enough. It’s only so extracted for unicast frames, not for groupcast frames, which are done under BIP not CCMP (the proposed change is wrong here; this subclause does cover robust Management frames too).

Proposed changes:

Change 12.5.3.4.4 PN and replay detection as follows:

To effect replay detection for individually addressed Data or robust Management frames, the receiver extracts the PN from the CCMP header.

[…]

The following processing rules are used to detect replay:

[…]

Change 12.5.5.4.4 PN and replay detection as follows:

To effect replay detection for individually addressed Data or robust Management frames, the receiver extracts the PN from the GCMP header. […] The following processing rules are used to detect replay:

[…]

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: Thursday, 26 August 2021 05:46
To: Mark Rison <m.rison@xxxxxxxxxxx>
Cc: stds-802-11-tgm <STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGM] 11me/D0.0 CID 193 (per-whatness of RCs)

Hey Mark,

Also, I'll assign this comment to you as well since its now in a similar scope area to your interpretation of CID 166.

REVme SEC adhoc comments

171

12.5.3.4.4

On Wed, Aug 25, 2021 at 11:45 AM M Montemurro <montemurro.michael@xxxxxxxxx> wrote:

Hi Mark,

Document 11-21/829 is already on the agenda for the August 30 teleconference as you requested a number of weeks ago.

Cheers,

Mike

On Wed, Aug 25, 2021 at 4:21 AM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

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

Hello,

I am quite bewildered by all this procedural wibbling. However, to try to

move past it and focus on substance, let me try again with a preamble and

further details in the Discussion section:

Below is my proposed resolution for CID 193, which was assigned to me on

Monday 23 August. It is a copy from the draft of 21/0829 on my hard drive,

which is not yet on Mentor, but will be, and has "Submission" in the

bottom left corner of every page. This post is made to gain a broader

audience, and is not intended to and does not replace discussion in a TGme

meeting, or incorporation of feedback and tracking of revisions on Mentor.

You are free to ignore this post if you do not find it useful/interesting

(similarly to how NOTEs in the 802.11 spec can just be ignored).

Mr Chair, please indicate when there will be agenda time for presentation

of the submission (from 21/0829 on Mentor, to be uploaded).

Identifiers

Comment

Proposed change

CID 193

Mark RISON

12.5.3.4.1

2577.30

"The decryption processing prevents replay of MPDUs by validating that the PN in the

MPDU is greater than the replay counter maintained for the session." should be ... "and TID" or "and AC" to allow for reordering across TIDs/ACs, where the receiver has indicated support for multiple replay counters (so maybe better as "(or the replay counter corresponding to the TID, if more than one replay counter is supported)" Or actually, since in 802.11 (unlike WMM) you allocate TIDs up to the max num replay counters supported, maybe just say "replay counter maintained for the session for that TID"?)

Change to "The decryption processing prevents replay of MPDUs by validating that the PN in the

MPDU is greater than the replay counter maintained for the session for that TID." Ditto at 2587.36. At 2577.49 change "the PN in the CCMP

header is greater than the replay counter maintained for the session and TID/ACI." to "the PN in the MPDU is greater than the replay counter maintained for the session for that TID."

Discussion:

As the comment points out, in 802.11 (as opposed to WMM) for Data frames you use TIDs up to the max number of replay counters supported, at which point you can’t use any other TIDs for that SA (though this is clearer for CCMP than for GCMP):

12.5.3.3.7 CCM originator processing

A transmitter shall not use an IEEE 802.11 MSDU or A-MSDU priority if this would cause the total number of priorities used during the lifetime of the SA to exceed the number of replay counters supported by the receiver (for a pairwise SA) or all the receivers (for a group SA) for that SA. The transmitter shall not reorder CCMP protected frames that are transmitted to the same RA within a replay counter, but may reorder frames across replay counters. One possible reason for reordering frames is the IEEE 802.11 MSDU or A-MSDU priority.

12.5.5.3.6 GCM originator processing

A transmitter shall not use IEEE 802.11 MSDU or A-MSDU priorities without ensuring that the receiver supports the required number of replay counters. The transmitter shall not reorder GCMP protected frames that are transmitted to the same RA within a replay counter, but may reorder frames across replay counters. One possible reason for reordering frames is the IEEE 802.11 MSDU or A-MSDU priority.

The number of replay counters supported for each PTKSA and GTKSA is indicated in the RSN Capabilities field of the RSNE: it can be 1, 2, 4 or 16 (see Table 9-152—PTKSA/GTKSA replay counters usage). Therefore as pointed out in the comment, the _expression_ “the replay counter maintained for the session” only works if the receiver is only capable of 1 RC per SA and requires further qualification otherwise (this is already done for PV1 (in 12.5.3.4.1.b).6)) but not for PV0 (whether CCMP or GCMP)).

In addition to this, there are replay counters for MFP (one for each of individually addressed robust Management and individually addressed robust PV1 Management) and for QMF (one for each ACI of individually addressed robust Management -- it’s not clear whether this is also used for individually addressed robust PV1 management or whether there’s a separate set of 4), when enabled:

12.5.3.4.4 PN and replay detection

If dot11RSNAProtectedManagementFramesActivated is true, the recipient shall maintain a single replay counter for received individually addressed robust Management frames that are received with the To DS subfield equal to 0, and a single replay counter for received individually addressed robust PV1 Management frames and shall use the PN from the received frame to detect replays. If dot11QMFActivated is also true, the recipient shall maintain an additional replay counter for each ACI for received individually addressed robust Management frames and robust PV1 Management frames that are received with the To DS subfield equal to 1. The QMF receiver shall use the ACI encoded in the Sequence Number field of the received frame to select the replay counter to use for the received frame, and shall use the PN from the received frame to detect replays.

It would appear that the MFP/QMF counters are not subject to any maximum per SA limit, i.e. there are always 1/4 of them respectively per SA, irrespective of the number of replay counters support signalled in the RSN Capabilities field of the RSNE.

In addition to this, there are a bazillion replay counters for group addressed robust Management frames under MFP and under QMF, when enabled; see 12.5.4.6 BIP reception.

So the replay counters are per-ACI for QMFs under MFP, per-TID for Data frames (but up to maximum total number per SA) and a singleton for non-QMF robust Management frames under MFP and (if individually addressed) not sent to an AP.

Also note the subtle “the PN in the CCMP header” for PV1, cf. “the PN in the MPDU” for PV0. This is because for PV1 the CCMP header is constructed locally, not actually carried in the MPDU:

12.5.3.2 CCMP MPDU format

The CCMP header is not included in secure PV1 MPDUs, but constructed locally at the STA as defined in 12.5.3.3.6 (Construct CCMP header for PV1 MPDUs).

12.5.3.3.6 Construct CCMP header for PV1 MPDUs

The CCMP header is not present in secure PV1 MPDUs, but constructed locally at the STA as follows:

The proposed change from “in the CCMP header” to “in the MPDU” missed this point; it would be helpful to be more explicit about this.

Note PV1 is not supported with GCMP, so we don’t need to worry about that. [Having said that, I can’t find the specific statement in the spec!]

Proposed changes:

Change 12.5.5.3.6 GCM originator processing as follows:

A transmitter shall not use an IEEE 802.11 MSDU or A-MSDU priorit~~ies without ensuring that the receiver supports the required number of replay countersy~~ if this would cause the total number of priorities used during the lifetime of the SA to exceed the number of replay counters supported by the receiver (for a pairwise SA) or all the receivers (for a group SA) for that SA. The transmitter shall not reorder GCMP protected frames that are transmitted to the same RA within a replay counter, but may reorder frames across replay counters. One possible reason for reordering frames is the IEEE 802.11 MSDU or A-MSDU priority.

Change 12.5.3.4.1 General (under 12.5.3.4 CCMP decapsulation) as follows:

5) The decryption processing prevents replay of MPDUs by validating that the PN in the MPDU is greater than the replay counter maintained for the session, and TID (for Data frames) or ACI (for QMFs).

            […]

6) The decryption processing prevents replay of MPDUs by validating that the PN in the locally constructed CCMP header (see 12.5.3.3.6) is greater than the replay counter maintained for the session, and TID/ (for Data frames) or ACI (for QMFs).

Change 12.5.5.4.1 General (under 12.5.5.4 GCMP decapsulation) as follows:

e) The decryption processing prevents replay of MPDUs by validating that the PN in the MPDU is greater than the replay counter maintained for the session, and TID (for Data frames) or ACI (for QMFs).

Change “TID/ACI” to “TID (for Data frames) or ACI (for QMFs)” at:

·         2571.47 (“1) When the sequence number of the MPDU is less than the previous sequence number and satisfies the BPN update conditions in 12.5.3.3.6 (Construct CCMP header for PV1 MPDUs) for that TID/ACI, increment the base PN so that the PN never repeats for the same temporal key and TID/ACI.” in 12.5.3.3(.1) CCMP cryptographic encapsulation)

·         2572.37 (“For PV1 MPDUs, the PN shall never repeat for a series of encrypted MPDUs using the same temporal key and TID/ACI.” in 12.5.3.3.2 PN processing)

·         2575.59 (“The locally stored BPN shall be incremented by 1 when the sequence number of the MPDU is less than the previous sequence number for that TID/ACI if any of the following two conditions is satisfied:” in 12.5.3.3.6 Construct CCMP header for PV1 MPDUs)

Proposed resolution:

REVISED

Make the changes shown under “Proposed changes” for CID 193 in <this document>, which address the issues raised by the commenter. Note to the commenter: there is no PN in PV1 MPDUs; instead the PN is generated locally.

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: Jon Rosdahl <jrosdahl@xxxxxxxx>
Sent: Wednesday, 25 August 2021 05:08
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] 11me/D0.0 CID 193 (per-whatness of RCs)

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

Mark,

The reflector is for the technical discussion.

Mentor is where we post the submissions.

the lower left corner of the document has the word "submission"...

The reason for "posting" to the reflector is to gain a broader audience than those on the teleconference.

so I don't see any conflict in his request.

Jon

-----------------------------------------------------------------------------

Jon Rosdahl                         Engineer, Senior Staff
IEEE 802 Executive Secretary Qualcomm Technologies, Inc.
office: 801-492-4023                  10871 North 5750 West
cell:   801-376-6435       Highland, UT 84003

A Job is only necessary to eat!
A Family is necessary to be happy!!

On Tue, Aug 24, 2021 at 1:25 PM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

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

OK, so on Monday you complained that I hadn't posted something to

the reflector and now you're complaining that I have posted something

to the reflector. What is the rule for what should and shouldn't

be posted to the reflector, and when?

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: Wednesday, 25 August 2021 04:19
To: Mark Rison <m.rison@xxxxxxxxxxx>
Cc: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx; Jouni Malinen (jouni@xxxxxxxxxxxxxxxx) <jouni@xxxxxxxxxxxxxxxx>; mark.hamilton2152@xxxxxxxxx
Subject: Re: 11me/D0.0 CID 193 (per-whatness of RCs)

Hey Mark,

One thing I would also like to clarify is that a submission means a document posted to a mentor. In that way, we can incorporate feedback and track revisions properly.

Thanks,

Mike

On Tue, Aug 24, 2021 at 3:10 PM M Montemurro <montemurro.michael@xxxxxxxxx> wrote:

Hey Mark,

You are the commenter. Your discussion in your previous email on this thread goes beyond what is in the Comment and Proposed Resolution fields for the comment. Given that this comment is a Security adhoc comment, I am assigning it back to the commenter and marking it "Submission Required".

With respect to the scope of the comment, I'm assigning it to you so that you can solicit feedback from the group. We haven't had an initial LB yet so personally I don't see whether it matters whether we try to do things before or after D1.0.

Cheers,

Mike

On Tue, Aug 24, 2021 at 2:44 PM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

Hello Mike,

> Based on your response below, I'm going to mark this comment "Submission Required" and assign it to you.

Err, this was assigned to me on Monday, and this is my submission!

What more are you expecting from me?

> My personal opinion based on this analysis is that your suggested resolution goes way beyond the scope of the comment or the proposed resolution.

I suppose it goes slightly beyond in part. I would say the stuff I now

highlight in green and cyan below is within the scope of the comment,

and in yellow arguably not. But why wait until D1.0 to sort out the

stuff in yellow?

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: Wednesday, 25 August 2021 02:20
To: Mark Rison <m.rison@xxxxxxxxxxx>
Cc: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx; Jouni Malinen (jouni@xxxxxxxxxxxxxxxx) <jouni@xxxxxxxxxxxxxxxx>; mark.hamilton2152@xxxxxxxxx
Subject: Re: 11me/D0.0 CID 193 (per-whatness of RCs)

Hi Mark,

Based on your response below, I'm going to mark this comment "Submission Required" and assign it to you.

My personal opinion based on this analysis is that your suggested resolution goes way beyond the scope of the comment or the proposed resolution.

Cheers,

Mike

On Tue, Aug 24, 2021 at 11:31 AM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

Hello,

This turned out to be a bit worse than I expected! Please tell me of

any mistakes or omissions in the following.

Identifiers

Comment

Proposed change

CID 193

Mark RISON

12.5.3.4.1

2577.30

"The decryption processing prevents replay of MPDUs by validating that the PN in the

MPDU is greater than the replay counter maintained for the session." should be ... "and TID" or "and AC" to allow for reordering across TIDs/ACs, where the receiver has indicated support for multiple replay counters (so maybe better as "(or the replay counter corresponding to the TID, if more than one replay counter is supported)" Or actually, since in 802.11 (unlike WMM) you allocate TIDs up to the max num replay counters supported, maybe just say "replay counter maintained for the session for that TID"?)

Change to "The decryption processing prevents replay of MPDUs by validating that the PN in the

MPDU is greater than the replay counter maintained for the session for that TID." Ditto at 2587.36. At 2577.49 change "the PN in the CCMP

header is greater than the replay counter maintained for the session and TID/ACI." to "the PN in the MPDU is greater than the replay counter maintained for the session for that TID."

Discussion:

As the comment points out, in 802.11 (as opposed to WMM) you use TIDs up to the max number of replay counters supported, at which point you can’t use any other TIDs for that SA (though this is clearer for CCMP than for GCMP):

12.5.3.3.7 CCM originator processing

A transmitter shall not use an IEEE 802.11 MSDU or A-MSDU priority if this would cause the total number of priorities used during the lifetime of the SA to exceed the number of replay counters supported by the receiver (for a pairwise SA) or all the receivers (for a group SA) for that SA. The transmitter shall not reorder CCMP protected frames that are transmitted to the same RA within a replay counter, but may reorder frames across replay counters. One possible reason for reordering frames is the IEEE 802.11 MSDU or A-MSDU priority.

12.5.5.3.6 GCM originator processing

A transmitter shall not use IEEE 802.11 MSDU or A-MSDU priorities without ensuring that the receiver supports the required number of replay counters. The transmitter shall not reorder GCMP protected frames that are transmitted to the same RA within a replay counter, but may reorder frames across replay counters. One possible reason for reordering frames is the IEEE 802.11 MSDU or A-MSDU priority.

The number of replay counters supported for each PTKSA and GTKSA is indicated in the RSN Capabilities field of the RSNE: it can be 1, 2, 4 or 16 (see Table 9-152—PTKSA/GTKSA replay counters usage).

In addition to this, there are replay counters for PMF (one for each of individually addressed robust Management and individually addressed robust PV1 Management) and for QMF (one for each ACI of individually addressed robust Management -- it’s not clear whether this is also used for individually addressed robust PV1 management or whether there’s a separate set of 4), when enabled:

12.5.3.4.4 PN and replay detection

If dot11RSNAProtectedManagementFramesActivated is true, the recipient shall maintain a single replay counter for received individually addressed robust Management frames that are received with the To DS subfield equal to 0, and a single replay counter for received individually addressed robust PV1 Management frames and shall use the PN from the received frame to detect replays. If dot11QMFActivated is also true, the recipient shall maintain an additional replay counter for each ACI for received individually addressed robust Management frames and robust PV1 Management frames that are received with the To DS subfield equal to 1. The QMF receiver shall use the ACI encoded in the Sequence Number field of the received frame to select the replay counter to use for the received frame, and shall use the PN from the received frame to detect replays.

It would appear that the PMF/QMF counters are not subject to any maximum per SA limit.

In addition to this, there are a bazillion replay counters for group addressed robust Management frames under PMF and under QMF, when enabled; see 12.5.4.6 BIP reception.

Also note the subtle “the PN in the CCMP header” for PV1, cf. “the PN in the MPDU” for PV0. This is because for PV1 the CCMP header is constructed locally, not actually carried in the MPDU:

12.5.3.2 CCMP MPDU format

The CCMP header is not included in secure PV1 MPDUs, but constructed locally at the STA as defined in 12.5.3.3.6 (Construct CCMP header for PV1 MPDUs).

12.5.3.3.6 Construct CCMP header for PV1 MPDUs

The CCMP header is not present in secure PV1 MPDUs, but constructed locally at the STA as follows:

The proposed change missed this point; it would be helpful to be more explicit about this.

Note PV1 is not supported with GCMP, so we don’t need to worry about that. [Having said that, I can’t find the specific statement in the spec!]

Proposed changes:

Change 12.5.5.3.6 GCM originator processing as follows:

A transmitter shall not use an IEEE 802.11 MSDU or A-MSDU priorit~~ies without ensuring that the receiver supports the required number of replay countersy~~ if this would cause the total number of priorities used during the lifetime of the SA to exceed the number of replay counters supported by the receiver (for a pairwise SA) or all the receivers (for a group SA) for that SA.. The transmitter shall not reorder GCMP protected frames that are transmitted to the same RA within a replay counter, but may reorder frames across replay counters. One possible reason for reordering frames is the IEEE 802.11 MSDU or A-MSDU priority.

Change “TID/ACI” to “TID (for frames other than QMFs) or ACI (for QMFs)” at:

·         2571.47 (“1) When the sequence number of the MPDU is less than the previous sequence number and satisfies the BPN update conditions in 12.5.3.3.6 (Construct CCMP header for PV1 MPDUs) for that TID/ACI, increment the base PN so that the PN never repeats for the same temporal key and TID/ACI.” in 12.5.3.3(.1) CCMP cryptographic encapsulation)

·         2572.37 (“For PV1 MPDUs, the PN shall never repeat for a series of encrypted MPDUs using the same temporal key and TID/ACI.” in 12.5.3.3.2 PN processing)

·         2575.59 (“The locally stored BPN shall be incremented by 1 when the sequence number of the MPDU is less than the previous sequence number for that TID/ACI if any of the following two conditions is satisfied:” in 12.5.3.3.6 Construct CCMP header for PV1 MPDUs)

Change 12.5.3.4.1 General (under 12.5.3.4 CCMP decapsulation) as follows:

5) The decryption processing prevents replay of MPDUs by validating that the PN in the MPDU is greater than the replay counter maintained for the session and TID (for frames other than QMFs) or ACI (for QMFs).

            […]

6) The decryption processing prevents replay of MPDUs by validating that the PN in the locally constructed CCMP header (see 12.5.3.3.6) is greater than the replay counter maintained for the session and TID/ (for frames other than QMFs) or ACI (for QMFs).

Change 12.5.5.4.1 General (under 12.5.5.4 GCMP decapsulation) as follows:

e) The decryption processing prevents replay of MPDUs by validating that the PN in the MPDU is greater than the replay counter maintained for the session and TID (for frames other than QMFs) or ACI (for QMFs).

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, 23 August 2021 23:11
To: 'STDS-802-11-TGM@xxxxxxxxxxxxxxxxx' <STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>
Subject: FW: [STDS-802-11-TGM] Reminder: REVme teleconference on Aug 23 at 10am ET

Hello,

> The motions are slides 10-15 of this document: https://mentor.ieee.org/802.11/dcn/21/11-21-0758-07-000m-revme-motions.pptx

A couple of things I've spotted, in the hope they can be patched up in advance

of the motions rather than going through all the pulling rigmarole:

- Stephen: I don't see the stuff highlighted in red in

“Motion-EDITOR1-D” tab (4 CIDs) in https://mentor.ieee.org/802.11/dcn/21/11-21-0738-04-000m-revme-wg-cc35-editor1-ad-hoc-comments.xlsx,

CID 571: On Page 2567 & 2568 $2569 of D0.1, upper box, change "Advertisement Server" to “"Advertisement server". 5 instances in figure 11-40, figure 11-41 figure 11-42, 11-43, and Figure11-44. In those 5 figures, also change "Advertisement Server" to "advertisement server" in message flow boxes.

- Mike: two issues highlighted

“Security Motion C” tab (9 CIDs) in https://mentor.ieee.org/802.11/dcn/21/11-21-0690-05-000m-revme-cc35-sec-comments.xlsx,

193 missing CCMP header -> MPDU at 2577.49. [though on further reflection maybe this should refer to the "locally constructed CCMP header"]

Also, are both per-TID and per-ACI possible for both PV0 and PV1 for CCMP, but only TID for GCMP?

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: Saturday, 21 August 2021 00:05
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] Reminder: REVme teleconference on Aug 23 at 10am ET

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

Now with corrected month. Sorry about that.:-)

On Fri, Aug 20, 2021 at 10:59 AM M Montemurro <montemurro.michael@xxxxxxxxx> wrote:

Hello everyone,

I just wanted you remind you that we have a teleconference on Monday where we will be running motions:

The agenda document is posted here: https://mentor.ieee.org/802.11/dcn/21/11-21-1214-04-000m-july-august-teleconference-agenda.docx

The motions are slides 10-15 of this document: https://mentor.ieee.org/802.11/dcn/21/11-21-0758-07-000m-revme-motions.pptx

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

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

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