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

Re: [STDS-802-11-TGBI] Discussion on 23/0166r0



Hi Amelia,

 

Thanks very much for your comments. Please see my reply inline.

 

BR,

Chaoming

 

-----邮件原件-----
发件人: Amelia Andersdotter <amelia.ieee@xxxxxxxxxxxxxxx>
发送时间: 2023320 4:22
收件人: STDS-802-11-TGBI@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBI] Discussion on 23/0166r0

 

Hi Chaoming,

 

Thank you for your presentations and strawpolls this week in TGbi. I thought I could briefly raise my comment on "need more information" from our Thursday session here on the reflector.

 

We've heard different presentations on enabling change of ancillary parameters (such as AID) when (OTA) MAC is changed, so what I would like to understand is how your mechanism would work with mechanisms in 11/23-336 or 11/23-414?

[cm] 11/23-336 looks like a competing method for changing AID. 11/23-414 focuses on changing OTA MAC, my 23/0166 should be able to work together with it.

 

I suppose, similarly, I'd ask how a process for changing the AID would be impacted if the mechanism proposed in 11/23-414 were used?

[cm] If 11/23-414 were used, e.g., the AP could assign a set of AIDs to an non-AP STA during the association process (hence there is a mapping between this set and the non-AP’s true MAC stored both in the AP and the non-AP STA), as I proposed in 23/0166. Whenever the AP discovers a new valid OTA MAC (i.e., it receives a frame whose TA is different from the TA the non-AP used previously and the TA is in a Tx Active MAC Address Set), it selects a different AID from the set and transmits frames using this new AID.

 

Or perhaps concisely, how much of your proposal depends on a MAC rotation to be performed in one way or the other (or at all, inside the DS)?

[cm] I think it is almost independent. For AID, as explained above, no extra frame exchange, hence it’s transparent to any MAC rotation method. For OTA PN, OTA SN and OTA TID, as explained in the doc 23/0166, they only depend on the value of the OTA_MAC. The method itself just a simple computation in both sides without any extra frame exchange. And, IMHO, these parameters are used only between the AP and the non-AP, and do not spread over the DS.

 

best regards,

 

Amelia

 

On 2023-02-17 11:48, 罗朝明(Chaoming Luo) wrote:

> 

> Hi All,

> 

> As discussed and promised during the call, I’m initiating this email

> thread to discuss the proposal of 23/0166r0. It would be appreciated

> if you can feedback any question or comment either individually to me

> or in this thread.

> 

> For the comment of “use a mapping from true SN to OTA_SN instead of

> reset SN to 0 when the associated non-AP changes OTA MAC address, and

> also scrambler seed, so the true sequence would not be interrupted”, I

> think I’m also fine with it if the group wants this direction. A

> similar algorithm as proposed for obfuscating PN could be used for SN too.

> 

> For the comment of how the mapping of true PN to OTA_PN works, a

> simple example is as follows:

> 

> STA send a frame with TA = OTA_MAC, OTA_PN = 0x101100B001B7, the

> OTA_PN was computed based on computed RN(4, 52) = 0x101100B0011B and

> true PN = 0x0000000000AC using the XOR algorithm;

> 

> When AP receives the frame from that OTA_MAC, AP generates a same

> RN(4, 52) locally based on that OTA_MAC, AP gets the true PN, which is

> computed based on RN(4, 52) and the OTA_PN using the XOR algorithm.

> 

> BR,

> 

> Chaoming

> 

> ----------------------------------------------------------------------

> --

> *OPPO *

> 

> 本电子邮件及其附件含有OPPO公司的保密信息,仅限于邮件指明的收件人(包含个人及群组)使用。禁止任何人在未经授权的情况下以任何形式使用。如果

> 您错收了本邮件,切勿传播、分发、复制、印刷或使用本邮件之任何部分或其所载之任何内容,并请立即以电子邮件通知发件人并删除本邮件及其附件。

> 

> 网络通讯固有缺陷可能导致邮件被截留、修改、丢失、破坏或包含计算机病毒等不安全情况,OPPO对此类错误或遗漏而引致之任何损失概不承担责任并保留

> 与本邮件相关之一切权利。

> *

> 除非明确说明,本邮件及其附件无意作为在任何国家或地区之要约、招揽或承诺,亦无意作为任何交易或合同之正式确认。

> *发件人、其所属机构或所属机构之关联机构或任何上述机构之股东、董事、高级管理人员、员工或其他任何人(以下称“发件人”或“OPPO”)不因本邮

> 件之误送而放弃其所享之任何权利,亦不对因故意或过失使用该等信息而引发或可能引发的损失承担任何责任。

> *

> 文化差异披露:因全球文化差异影响,单纯以YES\OK或其他简单词汇的回复并不构成发件人对任何交易或合同之正式确认或接受,请与发件人再次确认以

> 获得明确书面意见。发件人不对任何受文化差异影响而导致故意或错误使用该等信息所造成的任何直接或间接损害承担责任。

> *

> 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 are not the intended recipient,

> please do not read, copy, distribute, or use this information. If you

> have received this transmission in error, please notify the sender

> immediately by reply e-mail and then delete this message.

> Electronic communications may contain computer viruses or other

> defects inherently, may not be accurately and/or timely transmitted to

> other systems, or may be intercepted, modified ,delayed, deleted or

> interfered. OPPO shall not be liable for any damages that arise or may

> arise from such matter and reserves all rights in connection with the

> email. * Unless expressly stated, this e-mail and its attachments are

> provided without any warranty, acceptance or promise of any kind in

> any country or region, nor constitute a formal confirmation or

> acceptance of any transaction or contract. *The sender, together with

> its affiliates or any shareholder, director, officer, employee or any

> other person of any such institution (hereinafter referred to as

> "sender" or "OPPO") does not waive any rights and shall not be liable

> for any damages that arise or may arise from the intentional or

> negligent use of such information. * Cultural Differences Disclosure:

> Due to global cultural differences, any reply with only YES\OK or

> other simple words does not constitute any confirmation or acceptance

> of any transaction or contract, please confirm with the sender again

> to ensure clear opinion in written form.

> The sender shall not be responsible for any direct or indirect damages

> resulting from the intentional or misuse of such information. *

> ----------------------------------------------------------------------

> --

> 

> To unsubscribe from the STDS-802-11-TGBI list, click the following

> link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBI&A=1

> 

 

--

^\...~...~...~...~...~.../^

Amelia Andersdotter

^\...~...~...~...~...~.../^

 

________________________________________________________________________

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


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