Re: [STDS-802-11-TGM] Discussion on CID 178 Resolution: Protected Channe

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

Hello Ashish,

Well, you can have MFP, or you can have MFP and BP, or you can have

nothing (you can't have BP but not MFP: "If dot11RSNAProtectedManagementFramesActivated

is false, dot11BeaconProtectionEnabled shall be set to false.").

I'm happy to further qualify the text as regards MFP. Something like:

If a non-AP STA that has negotiated management frame protected receives both protected channel switch information (e.g. protected Channel Switch Announcement frame, protected Extended Channel Switch Announcement frame, or Channel Switch Announcement element or Extended Channel Switch Announcement element in a protected Beacon frame when it has negotiated beacon protection) and unprotected channel switch information (e.g. unprotected Channel Switch Announcement frame, unprotected Extended Channel Switch Announcement frame, or Channel Switch Announcement element or Extended Channel Switch Announcement element in a Probe Response frame, unprotected Beacon frame or protected Beacon frame when it has not negotiated beacon protection), it should use the protected channel switch information and ignore the unprotected channel switch information.

Having said this, I'm not sure all this can actually happen. If MFP

has been negotiated then all CSA frames will be protected since they

are Spectrum Management Action frames, which are robust. ECSA frames

are never protected because they are Public Action frames, which are

not robust, but there is a Protected Dual variant, which is robust.

So exactly when would a STA that has negotiated MFP receive an

unprotected *CSA frame? Isn't the issue only with *CSA elements in

probe responses and, if BP was not negotiated, beacons?

Thanks,

Mark

Mark RISON, Standards Architect, WLAN English/Esperanto/Français

Samsung Cambridge Solution Centre Tel: +44 1223 434600

1 Cambridge Square, Cambridge CB4 0AE Fax: +44 1223 434601

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

From: Ashish Shukla <shukla.a@xxxxxxxxx>
Sent: Tuesday, 6 January 2026 19:27
To: Mark Rison <m.rison@xxxxxxxxxxx>
Cc: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] Discussion on CID 178 Resolution: Protected Channel Switch Announcement

Thanks a lot Mark, appreciate your feedback.

inline...

On Tue, Jan 6, 2026 at 1:16 AM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

Thanks, Ashish.

I have a concern with

A non-AP STA [...] should ignore any Channel Switch Announcement element or Extended Channel Switch Announcement element in an unprotected Beacon frame or unprotected Probe Response frame.

since it rather defeats the purpose of including these elements in

beacons/probe responses.

Good catch. I intended to specify this behavior for non-AP STAs that have negotiated management frame protection. Without PMF, STAs can make use of any of these frames. Something like this.

"When Management frame protection is negotiated, a non-AP STA should use the channel switch parameters from a protected Channel Switch Announcement frame or a protected Extended Channel Switch Announcement frame and should ignore any Channel Switch Announcement element or Extended Channel Switch Announcement element in an unprotected Beacon frame or unprotected Probe Response frame."

I think what you're trying to say is that if you receive a protected

element you should use that in preference to an unprotected element,

if you can?

Yes, exactly. In a BSS, there could be a mix of non-AP STAs with varying capabilities. STAs without PMF (802.11w) can continue using unprotected frames, while STAs with PMF can make use of protected elements when available. Additionally, Beacon protection-enabled STAs can use either a protected beacon or a protected action frame carrying CSA information, but not an unprotected Probe Response frame.

Also note that probe responses are never protected (they're not robust

and not covered by beacon protection). And beacon protection doesn't

help you if you haven't negotiated beacon protection.

I also think the sentences in the NOTE are duplicates.

Given all this, how about something like:

If a non-AP STA receives both protected channel switch information (e.g. protected Channel Switch Announcement frame, protected Extended Channel Switch Announcement frame, or Channel Switch Announcement element or Extended Channel Switch Announcement element in a protected Beacon frame when it has negotiated beacon protection) and unprotected channel switch information (e.g. unprotected Channel Switch Announcement frame, unprotected Extended Channel Switch Announcement frame, or Channel Switch Announcement element or Extended Channel Switch Announcement element in a Probe Response frame, unprotected Beacon frame or protected Beacon frame when it has not negotiated beacon protection), it should use the protected channel switch information and ignore the unprotected channel switch information.

This is quite clear as well. Thanks
However, as I mentioned earlier, it may make sense to qualify this to a non-AP STA that has negotiated protected management frame procedure?

NOTE—If the unprotected channel switch information is received first, a non-AP STA might not be able to handle subsequent protected channel switch information.

The note looks good. Thanks

?

Thanks,

Mark

--

Mark RISON, Standards Architect, WLAN English/Esperanto/Français

Samsung Cambridge Solution Centre Tel: +44 1223 434600

1 Cambridge Square, Cambridge CB4 0AE Fax: +44 1223 434601

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

> -----Original Message-----

> From: Ashish Shukla <shukla.a@xxxxxxxxx>

> Sent: Tuesday, 6 January 2026 00:25

> To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx

> Subject: [STDS-802-11-TGM] Discussion on CID 178 Resolution: Protected Channel Switch Announcement

>

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

>

> Hello Youhan, Mark Rison, Po-Kai, Joseph, Brian Hart and Everyone,

>

> Following the discussion in the January teleconference, I have revised

> the text to resolve CID 178, available here:

> https://mentor.ieee.org/802.11/dcn/25/11-25-2282-02-000m-lb289-cid-178-proposed-resolution.docx

>

> The proposal addresses a security vulnerability where an adversary can

> spoof unprotected Beacon or Probe Response frames containing malicious

> Channel Switch Announcement elements, causing a STA to switch to an

> incorrect channel. The proposed resolution recommends that STAs

> prioritize CSA information received in protected frames over

> unprotected frames. Please see the background in the doc above.

>

> I would appreciate your feedback on this proposal before the upcoming

> January interim meeting, where I plan to present the resolution.

>

> Thank you and regards,

> Ashish

>

> ________________________________

>

>

> On Mon, Jan 5, 2026 at 3:04 PM Youhan Kim

> <00002b3ff331b292-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

> >

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

> > Hi, Mike,

> >

> > Could you please add the following documents to the agenda for next week?

> >

> > 11-25/2097 - Deprecating Large Number of EHT-SIG Symbols in EHT SU (CID 278)

> >

> > This document was presented in the 2025 Nov. Plenary meeting. No feedback received so far, so

> hopefully this would be a short recap presentation at this point + SP.

> >

> > 11-26/0039 - EHT OM Control MCS15 Disable (CID 279)

> > 11-25/2182 - NDP Preamble Content (CID 498)

> >

> >

> > Also, CID 50 is marked as "Submission required" in the 11mf database.

> > But please note that I had presented 11-25/2180 during the December Ad Hoc meeting, and CID 50 was

> agreed to be marked as "Ready for Motion". Please see 11-25/1761r0.

> >

> > Thanks,

> > Youhan

> >

> > ________________________________

> >

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

>

> _______________________________________________________________________________

>

> IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this

> CLOSED reflector. We use this valuable tool to communicate on the issues at hand.

>

> SELF SERVICE OPTION:

> Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and

> then amend your subscription on the form provided. If you require removal from the reflector

> press the LEAVE button.

>

> Further information can be found at: https://protect2.fireeye.com/v1/url?k=90468d56-cffe85f4-90470619-

> 000babff88b5-9cd178d372a098c4&q=1&e=e608c455-8017-437f-a3d4-

> f4e5e6bf6cb8&u=http%3A%2F%2Fwww.ieee802.org%2F11%2FEmail_Subscribe.html

> _______________________________________________________________________________

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