Re: [STDS-802-11-TGM] 24/1915 (SAQ for low-tx devices) and 24/1919 (TSF

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

Hi Yanchao,

Thank you for the comments. Since we did not get a chance to discuss on the call today, here are my thoughts:

> Is it better to protect the TSF with a more finer time resolution? i.e. to protect more bits of the 64-bit TSF value?

This proposal is intended to provide some amount of protection for the timestamp in a manner that is completely transparent to legacy devices, without any significant architectural impacts on devices that want to add this functionality. I think adding finer resolution protection for the timestamp would require either a) having a hard upper bound on Beacon transmission delay relative to TBTT or b) access to the actual timestamp value, or at least the additional bits to be protected, when computing the MME MIC. Both of those seem to be relatively difficult. Additionally, that information would need to be signaled in the Beacon so would require addition of another element (in order to maintain backwards compatibility) or re-definition of the MME (which would probably break compatibility).

> The proposed method uses the beacon period as basic denominator. If the value of beacon period is greater than 2^5 (32 TU), all the MSB bits of 64-bit TSF can be protected. But if the beacon period is small, the most MSB bit(s) of 64-bit TSF may not be protected. For example, if the beacon period is 32 TU (this value is allowed by spec), then the 48-bit BIPN can only cover the Bit62~Bit15 of the 64-bit TSF, leaving the MSB Bit63 of TSF not protected and be vulnerable to be manipulated.

The BIPN must be unique for every beacon transmitted to preserve security, so the denominator needs to be the beacon period or smaller. Again, solving this would require a more complicated solution such as including the high bit in another element (or in the MME), or signaling that the high bit will always be 0, perhaps with a flag in the RSNXE - but that would require the AP to restart if the bit ever rolls over. Are such short beacon periods in common use anywhere? 100 TU is, I think, used by the vast majority of APs, with 300 TU in some more specialized applications. I could add a restriction that this beacon protection mechanism shall only be enabled if the beacon period is > 32 TU.

Thanks,

- Henry

On Sun, Apr 27, 2025 at 7:08 PM Yanchao Xu <Yanchao.Xu@xxxxxxxxxxx> wrote:

Hi Henry,

About the 24/1919/(TSF protection), we have two comments,

As the BIPN is derived from TBTT (per beacon) level, the resolution of the protected TSF is within one beacon period. Is this resolution fine enough? For example, the document has a use case of modifying the TWT timing to make STA wake at incorrect time. In many use cases, the TWT interval/duration is less than one beacon period. So even with this proposed method, the attacker can still manipulate the TSF to be any value within one beacon period and can be able to mislead STA to wrong TWT timing.

Is it better to protect the TSF with a more finer time resolution? i.e. to protect more bits of the 64-bit TSF value?

The proposed method uses the beacon period as basic denominator. If the value of beacon period is greater than 2^5 (32 TU), all the MSB bits of 64-bit TSF can be protected. But if the beacon period is small, the most MSB bit(s) of 64-bit TSF may not be protected. For example, if the beacon period is 32 TU (this value is allowed by spec), then the 48-bit BIPN can only cover the Bit62~Bit15 of the 64-bit TSF, leaving the MSB Bit63 of TSF not protected and be vulnerable to be manipulated.

Best,

Yanchao Xu

From: Henry Ptasinski <henry@xxxxxxxxxx>
Sent: 2025年4月28日 2:20
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] 24/1915 (SAQ for low-tx devices) and 24/1919 (TSF protection)

[ EXTERNAL EMAIL ]

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

Thanks for the comments Mark.

I've uploaded revised versions of both docs.

- Henry

On Thu, Mar 20, 2025 at 6:50 AM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

Thanks for these. I attach some comments.

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: *** IEEE STDS-802-11 List *** <STDS-802-11@xxxxxxxxxxxxxxxxx> On Behalf Of Henry Ptasinski
Sent: Tuesday, 18 March 2025 21:38
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] TGmf teleconference announcement - 28 April

--- This message came from the IEEE 802.11 Working Group Reflector ---

Hi Mike,

Please add 11-24/1915 and 11-24/1919 to the queue. These both have minor changes to address comments received from when I presented them in Nov.

Thanks,

- Henry

On Thu, Mar 13, 2025 at 2:13 PM M Montemurro <montemurro.michael@xxxxxxxxx> wrote:

--- This message came from the IEEE 802.11 Working Group Reflector ---

Hello everyone,

As discussed yesterday, TGmf will be holding a teleconference at 10am ET on 28 April 2025 for 2 hours.

The agenda for the teleconference will include contributions that we were unable to review during the session this week.

Cheers,

Mike

--

Henry Ptasinski

President

Element78 Communications LLC

henry@xxxxxxxxxx

+1-415-608-0637

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