> I don’t think that in the existing spec we have discussed the case of using Time To Termination request to shorten the TTT, it has been used
to extend the TTT, at least that is my impression. I suppose it is a case we can consider or we can be more specific about it in the protocol description.
Hm, I've just
grepped D1.02 and I can't find anything that indicates it's
only used to extend the duration of a TS.
Am I missing something?
If this is indeed the intent, then I think it definitely needs some words,
because to me it's very counter-intuitive (if there is only one subscriber
to a TS, and they've said they only need it for 5 more minutes, why would
you keep broadcasting it for the next hour?).
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
Thanks, Pei. I attach my comments.
Also, this mechanism has no protection against an attacker causing
premature termination of an EBCS TS by forging an EBCS req ANQP-element
with a short Requested Time To Termination, right?
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
> -----Original Message-----
> From: ** STDS-802-11-TGbc -- Enhanced Broadcast Service ** <STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx> On
> Behalf Of ??(Zhou Pei)
> Sent: Wednesday, 26 May 2021 11:25
> To: STDS-802-11-TGBC@xxxxxxxxxxxxxxxxx
> Subject: [STDS-802-11-TGBC] Discussion on EBCS Request ANQP-element
>
> Hi all,
>
> I presented a contribution titled "Text Proposal for EBCS Request ANQP-element" (doc: 11-21-0600-02-
> 00bc-text-proposal-for-enhanced-broadcast-request-anqp-element) in the last teleconference.
> Some members raised the security issue of adding Requested Time to Termination subfield to the EBCS
> Request ANQP-element, since one unassociated non-AP STA may maliciously request a long time, which
> will have negative effects on the other non-AP STAs.
> I think this issue can be solved by limiting the time duration and/or frequency of ECBS services
> requested by unassociated non-AP STAs. That is to say, the EBCS transmitter of an EBCS has the
> authority to determine the time to termination of the EBCS.
>
> Attached pleased find a revised version of my proposal. I added a new Clause 11.100.5 EBCS Negotiation
> Procedure for Unassociated STAs.
> Please let me know if you have any comment, thanks!
>
>
> Best regards,
>
> Pei Zhou
> ________________________________
> OPPO
>
> 本电子邮件及其附件含有OPPO公司的保密信息,仅限于邮件指明的收件人使用(包含个人及群组)。禁止任何人在未经授权的情况
> 下以任何形式使用。如果您错收了本邮件,请立即以电子邮件通知发件人并删除本邮件及其附件。
>
> This e-mail and its attachments contain confidential information from OPPO, which is intended only for
> the person or entity whose address is listed above. Any use of the information contained herein in any
> way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by
> persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error,
> please notify the sender by phone or email immediately and delete it!
>
> ________________________________________________________________________
> To unsubscribe from the STDS-802-11-TGBC list, click the following link:
> https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBC&A=1
________________________________________________________________________
To unsubscribe from the STDS-802-11-TGBC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBC&A=1
To unsubscribe from the STDS-802-11-TGBC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBC&A=1
To unsubscribe from the STDS-802-11-TGBC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBC&A=1