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.
"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?
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.
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.
?
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
> _______________________________________________________________________________