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

Re: [STDS-802-11] Discussion about control frame protection extension

--- This message came from the IEEE 802.11 Working Group Reflector ---
Hi Po-Kai,

Including the reflector so that the participants in TGmf who are interested in this proposal can understand the issue.

You presented this contribution in TGmf in March. There was no previous discussion on the issue in TGmf prior to that presentation. 

My recommendation at this point to address my comments is that the Protected Frame field in the Frame Control field. should be used in a manner consistent to how its used in the baseline. 

Secondarily, I don't think you need to make any modifications to the BA Control field since you could override the More Data field of the frame control field to signal the Key ID. 

I've provided technical comments in sufficient time for you to resolve. However it seems that you are unwilling to address them. So perhaps others could give their opinion.

Cheers,

MIke

On Thu, Apr 17, 2025 at 4:26 PM Alfred Asterjadhi <aasterja@xxxxxxxxxxxxxxxx> wrote:

Thanks Po-kai for cc-ing me and others for the discussions below.

 

 

In the early days of this proposal there were suggestions of using the Protected Frame field for such an indication and the preference was to not use it for several reasons (some of them were mentioned by Po-Kai below).

I think keeping the signaling as currently defined in the document is the safest choice from a technical perspective.

 

Regards,

 

Alfred

 

 

From: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Sent: Thursday, April 17, 2025 12:58 PM
To: M Montemurro <montemurro.michael@xxxxxxxxx>; Alfred Asterjadhi <aasterja@xxxxxxxxxxxxxxxx>
Cc: Jouni Malinen <jouni@xxxxxxxxxxxxxxxx>; Stephen McCann <stephen.mccann@xxxxxxxxxx>; laurent.cariou@xxxxxxxxx
Subject: RE: Discussion about control frame protection extension

 

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Mike,

 

                The topic of encryption vs integrity protection is discussed in IEEE meeting with submissions. Eventually, people that submit presentation to argue for encryption backdown because majority of people comment during the presentation say it is not the preferred direction to do encryption.

 

The result is that we define integrity protection for all the cases.

 

Best,

Po-Kai

 

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Thursday, April 17, 2025 11:08 AM
To: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Cc: Jouni Malinen <jouni@xxxxxxxxxxxxxxxx>; Stephen McCann <stephen.mccann@xxxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>
Subject: Re: Discussion about control frame protection extension

 

Hi Po-kai,


My request is pretty simple. I would like to see the Protected Frame bit set to 1 in individually addressed control frames.  I'm not sure where "people" are mentioned in the IEEE 802.11 standard.

 

Cheers,

 

Mike

 

On Thu, Apr 17, 2025 at 2:02 PM Huang, Po-kai <po-kai.huang@xxxxxxxxx> wrote:

Hi Mike,

 

                Ok, so we conclude on the group addressed ones.

 

                For the individually addressed, as explained, we still have the security header part, which is mandated by the current spec when that bit is set, and since we are using MIC only mechanism rather than encryption, it is not appropriate to use that bit as well. Note that encryption is discussed in the beginning, at the end majority of the people drop encryption.

 

                Hopefully, this explains why we are not using Protected Frame bit.  

 

 

Best,

Po-Kai

 

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Thursday, April 17, 2025 10:58 AM
To: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Cc: Jouni Malinen <jouni@xxxxxxxxxxxxxxxx>; Stephen McCann <stephen.mccann@xxxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>
Subject: Re: Discussion about control frame protection extension

 

Hi Po-kai,

 

I'm saying that we adopt the same requirements and Control and Data.

 

If the Control frame is individually addressed, the Protected Frame field is set to 1.

If the Control frame is group-addressed, the Protected Frame field is set to 0.

 

Cheers,

 

Mike

 

On Thu, Apr 17, 2025 at 1:55 PM Huang, Po-kai <po-kai.huang@xxxxxxxxx> wrote:

Hi Mike,

 

                Thanks for the discussion. I think I am confused on what you suggest.

 

I believe the Protected Frame field is set to 0 for group-addressed management frames. 

 

                What you mention above is correct. We never use Protected Frame field for group addressed management frame if they are protected. I cite the texts below. To use it consistently, then we do not use it for group addressed control frame right, so it is set to 0, and the current text is reflecting that. Right?

 

                For individually addressed, it is only used for cases where we have security header. Again, I cite the texts below. Hence, we are setting it to 0 in individually addressed control and that is perfectly fine right?

 

                For consistent with the spec, if you read 12.2.6, you can see that control frame is not listed, so I think the proposal algins with the current spec. Can we conclude on this part?

 

9.3.2.1.4 The frame body

The frame body consists of either of the following:

— The MSDU (or a fragment thereof), the Mesh Control field (present if the frame is transmitted by a

mesh STA and the Mesh Control Present subfield of the QoS Control field is 1, otherwise absent),

and a security header and trailer (present if the Protected Frame subfield in the Frame Control field

is 1, otherwise absent)

 

12.2.6 Requirements for the Protected Frame field

The Protected Frame field shall be set to 1 in the following:

— Data frames that are protected using the mechanisms specified in Clause 12 (Security).

— Individually addressed protected robust Management frames.(#3056)

It shall be set to 0 in all other frames.

 

Best,

Po-Kai

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Thursday, April 17, 2025 10:33 AM
To: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Cc: Jouni Malinen <jouni@xxxxxxxxxxxxxxxx>; Stephen McCann <stephen.mccann@xxxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>
Subject: Re: Discussion about control frame protection extension

 

Hi Po-kai


The definition for the Protected Frame field is as follows: "The Protected Frame subfield ((#6402)see 12.2.6 (Requirements for the Protected Frame field)) is set to 1 if

the Frame Body field contains information that has been processed by a cryptographic encapsulation

algorithm. "

 

The requirements for protection of group-addressed control frames should be consistent with group-addressed management frames. I believe the Protected Frame field is set to 0 for group-addressed management frames. 

 

My preference is that we continue to use the Protected Frame field for control frame protection and use it consistently with the baseline.

 

Cheers,

 

Mike  

 

On Thu, Apr 17, 2025 at 12:09 PM Huang, Po-kai <po-kai.huang@xxxxxxxxx> wrote:

Hi Mike,

 

                For control frame protection, we also have group addressed case like broadcast Trigger frame or broadcast M-BA to legacy station as well.  I mean that is the reason why we go all the way to have user info field in Trigger frame to carry PN and MIC. Based on your logic, we then need to set protected frame to 0, right?

 

Best,

Po-Kai

 

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Thursday, April 17, 2025 8:02 AM
To: Jouni Malinen <jouni@xxxxxxxxxxxxxxxx>
Cc: Huang, Po-kai <po-kai.huang@xxxxxxxxx>; Stephen McCann <stephen.mccann@xxxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>
Subject: Re: Discussion about control frame protection extension

 

Hi all,

 

Po-kai, I think it's clearer if we set the Protected Frame = 1 in the FCS. It's consistent with protected data and protected management frames. 

 

Thanks,

 

Mike

 

 

 

On Thu, Apr 17, 2025 at 10:59 AM Jouni Malinen <jouni@xxxxxxxxxxxxxxxx> wrote:

The reason for beacon protection having to set Protected Frame subfield to 0 is not because of lack of additional security header but because of all STAs, i.e., including ones not supporting beacon protection, being able to process the Beacon frames. If there are cases where a protected Control frame is sent to a STA (or a group of STAs) that is (are) known to support control frame protection, I see no issues in using Protected Frame = 1 to indicate this even if there is no security header present.

 

- Jouni

 

 

From: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Sent: Wednesday, April 16, 2025 8:44 PM
To: M Montemurro <montemurro.michael@xxxxxxxxx>
Cc: Stephen McCann <stephen.mccann@xxxxxxxxxx>; laurent.cariou@xxxxxxxxx; Jouni Malinen <jouni@xxxxxxxxxxxxxxxx>
Subject: RE: Discussion about control frame protection extension

 

Hi Mike,

 

                As explained, the Protected Frame subfield in FC is to signal additional security header. I cited the baseline texts again below. As a result, we just cannot use it because we are not including security header. I also explain that in Beacon frame protection they set the Protected Frame subfield to 0 because they also do not include security header.

 

We name the new field protected Control, so it is not confused with that Protected frame field. Hope this better clarifies the situation.

 

9.3.2.1.4 The frame body

The frame body consists of either of the following:

— The MSDU (or a fragment thereof), the Mesh Control field (present if the frame is transmitted by a

mesh STA and the Mesh Control Present subfield of the QoS Control field is 1, otherwise absent),

and a security header and trailer (present if the Protected Frame subfield in the Frame Control field

is 1, otherwise absent)

 

 

Best,

Po-Kai

 

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Wednesday, April 16, 2025 9:57 AM
To: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Cc: Stephen McCann <stephen.mccann@xxxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>; jouni@xxxxxxxxxxxxxxxx
Subject: Re: Discussion about control frame protection extension

 

Hi Po-kai,

 

Thanks. but why not use the Protected bit in the Frame Control field so signal that the frame is protected. It is included in the AAD already. Now it's kind of weird because that field is actually set to 0 for control frames.

 

So now you have one Protected field set to 0 and another "protected field" set to 1.

 

Cheers,

 

Mike

 

On Wed, Apr 16, 2025 at 12:11 PM Huang, Po-kai <po-kai.huang@xxxxxxxxx> wrote:

Hi Mike,

 

                I understand your questions on format much better now. Thanks for the illustration. I explain below. Let me know if this addresses your format questions.

 

Best,

Po-Kai

 

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Wednesday, April 16, 2025 7:48 AM
To: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Cc: Stephen McCann <stephen.mccann@xxxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>; jouni@xxxxxxxxxxxxxxxx
Subject: Re: Discussion about control frame protection extension

 

HI Po-kai,

 

I guess I can live with frame formats. 

 

With respect to the AAD, Also, I just noticed none of the BAR Control is protected by the AAD.

 

[Po-Kai]: I see the question. AAD is for the “header part”. BAR control is specific to BAR. Hence, it is protected by the MIC computation. This is addressed in the following texts.

 

12.5.x.5 Transmission

 

Otherwise, compute an integrity value over the concatenation of the AAD and contents after the TA field and before the MIC field.

 

Why not use the Protected field in the FC field since it is protected by the AAD?

 

[Po-Kai]: I assume you mean Protected Frame subfield. Today, Protected Frame is used only for the case when we have security header present for encryption. See texts below. Given that we are just doing integrity check without encryption, we do not introduce security header and as a result, we do not use that Protected Frame subfield. Note that Beacon frame protection also sets the Protected Frame subfield to 0 in the Beacon with MME. Let me know if this answers the questions.

 

9.3.2.1.4 The frame body

The frame body consists of either of the following:

— The MSDU (or a fragment thereof), the Mesh Control field (present if the frame is transmitted by a

mesh STA and the Mesh Control Present subfield of the QoS Control field is 1, otherwise absent),

and a security header and trailer (present if the Protected Frame subfield in the Frame Control field

is 1, otherwise absent)

 

I also think you should consider protecting fields in the BAR control in the AAD.

 

[Po-Kai]: As explained above, agree that we need to protect BAR control, and it is indeed protected in the MIC calculation.

 

Cheers,

 

Mike

 

On Wed, Apr 16, 2025 at 10:31 AM Huang, Po-kai <po-kai.huang@xxxxxxxxx> wrote:

Hi Mike,

 

                Let’s see if we can conclude the format to make sure that I address all your comments. I want to make sure that I address it rather than adding one thing, but you are still not happy about another. I mean it will be really confusing that I accommodate two bits, but you still say comments not addressed because you want to change format….. I will have to say that format change is also indeed more controversial.

 

                For your format argument, if your concern is on MIC truncation. As discussed, if you negotiate a new mode using the new capabilities (to be defined in the future), then devices support that new capabilities will have to support the new format (with truncated MIC as the example) and the signaling is effective based on the mode indication. Peer STAs will use that new format with truncated MIC if both sides support the new mode. Note that even if we define signaling in header, we also can not define new format anyhow because the bit will be reserved, and existing device cannot support that so the difficulty for future implementation is the same.

 

                I wonder if this helps?

               

Best,

Po-Kai

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Wednesday, April 16, 2025 7:20 AM
To: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Cc: Stephen McCann <stephen.mccann@xxxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>; jouni@xxxxxxxxxxxxxxxx
Subject: Re: Discussion about control frame protection extension

 

Hi Po-Kai,

 

The 2 bit field helps.

 

The only other comment is that the way you have specified protected control frame formats will make it difficult to add another protected control frame format. 

 

Cheers,

 

Mike

 

On Wed, Apr 16, 2025 at 10:15 AM Huang, Po-kai <po-kai.huang@xxxxxxxxx> wrote:

Hi Mike,

 

                Thanks for checking. I am waiting for you to confirm that 2 bit will work for you. Since I have not got any confirmation, I upload the version without that at this point. Can you confirm that if I do the 2 bit change, then it will solve your problem? If so, let me prepare one and circulate for review today.

 

Best,

Po-Kai

 

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Wednesday, April 16, 2025 6:34 AM
To: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Cc: Stephen McCann <stephen.mccann@xxxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>; jouni@xxxxxxxxxxxxxxxx
Subject: Re: Discussion about control frame protection extension

 

HI Po-kai,

 

I looked at the document you sent me and the document you posted and I do not see a 2-bit field in the RSNXE. Could you please double check?

 

Thanks,

 

Mike

 

On Tue, Apr 15, 2025 at 1:02 PM Huang, Po-kai <po-kai.huang@xxxxxxxxx> wrote:

Hi Mike,

 

                I think 2 bit in RSNXE to signal capabilities is not that controversial.

 

                For the header part, I will say eventually different mode will just signal different format like the MIC truncation size that you are talking about.

 

                If I just prepare a two bit RSNXE to indicate control frame protection will that work for you?

 

Best,

Po-Kai

 

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Tuesday, April 15, 2025 9:58 AM
To: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Cc: Stephen McCann <stephen.mccann@xxxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>; jouni@xxxxxxxxxxxxxxxx
Subject: Re: Discussion about control frame protection extension

 

HI Po-kai, 


Yes. I also think we might need to ensure that the frame format for the control frame with the encryption fields is extensible. It might require additional signaling in the header.

 

Cheers,

 

Mike

 

On Tue, Apr 15, 2025 at 12:33 PM Huang, Po-kai <po-kai.huang@xxxxxxxxx> wrote:

Hi Mike,

 

                Thanks for the response.  If I summarize what you propose, basically you are suggesting a two bit field to indicate control frame protection. Then for now, we only define what 0 value mean and other fields reserved. Is this the right understanding?

 

Best,

Po-Kai

 

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Tuesday, April 15, 2025 9:02 AM
To: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Cc: Stephen McCann <stephen.mccann@xxxxxxxxxx>; Cariou, Laurent <laurent.cariou@xxxxxxxxx>; jouni@xxxxxxxxxxxxxxxx
Subject: Re: Discussion about control frame protection extension

 

Hi Po-kai

 

Here are my detailed comments:

1) 9.3.1.7 - I would like to see signaling in the control frame that would be extensible. For instance, I would like to see a mechanism where there could be different encapsulation variants in the future. So for the moment, let's consider your proposal as variant "1", In the future, I'd like to be able to define a new variant that a) doesn't use the pairwise data key for control frame encryption and b) a truncated MIC that minimizes overhead of the frame. I'm open to how this done but as defined it is not extensible. 

 

2)  I would like to see the cryptographic encapsulation protocol negotiated separately from the pairwise data cipher suite. This would require changes to the negotiation to make it extensible to negotiate an alternative cipher suite. (This is somewhat related to 1 in that the encryption header in the frame may change).

 

3) I think I would prefer to have an enumerated or a bitwise field in the RSNXE to negotiate control frame encryption, with the enumerated field pointing to the encapsulation mechanism.

 

I still think GMAC-256 is still overkill since the key size is longer than the messages you are encrypting. As I said, I understand the hardware limitations you are trying to work around, but that's no excuse for providing some extensibility.

Personally I think more work needs to be done to specify this feature properly. In my opinion, that work hasn't been done.

 

Also, why did you take this discussion off the reflector?

Cheers,

 

Mike

 

On Thu, Apr 10, 2025 at 11:13 AM Huang, Po-kai <po-kai.huang@xxxxxxxxx> wrote:

Hi Mike and Stephen,

 

                Thanks for the discussion about control frame protection in the reflector. I do hear the comments, and I have been checking offline to produce a complete draft to address all the comments including Mark Rison’s thread to avoid uploading too many revisions to the reflector.

 

                For the negotiation of control frame protection mode, here is the way that I think will work for whatever extensions. First, for Mike, as we agree, we are not going to define any new mode now in March because it is not clear what that new mode is about. For example, there are claims that GMAC-256 may have issues, but that is not the case now and GCMP/GMAC-256 is even quantum secure, so there is no alternative to replace it. In this case, to address future extension, one easy way would be simply to indicate a new capability bit in RSNXE, say control frame extension. Then we can define what that extension is about including any modification when we have concrete understanding about the extension. Adding RSNXE capability bit can be done in any time, and I think that should solve your extension issue. In some sense, control frame extension indication in RSNXE is like a new mode indication. We can add a note in the proposal to mention this to demonstrate the “crypto agility”.  Will this work for you to address the comments of extension?

 

                 

 

Best,

Po-Kai

To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1