Re: [STDS-802-11-TGBF] 回复: Feedback on 1934r5

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

Hi Chaoming and all,

I also had similar questions a Mike, what is the motivation in replacing a two way frame exchange with a single Measurement Query? Are we trying to save the overhead of the session setup response? I don’t see why it has to be done, also seems you are also proposing the Measurement Setup Request frame (from the AP) in response to a Measurement Query frame to be an implicit acknowledgement from the AP to setup the sensing session. In my opinion, a separate pair of frames for session setup (per the original intention) is much cleaner, even if the frames don’t negotiate any sensing attributes, it can be explicit acknowledgement from both parties to proceed with sensing operations. This seems to be getting unnecessarily complicated in my humble opinion.

Btw, in your slides the Measurement Query seems to be always sent in the uplink while the Measurement Setup Request in the DL? Surely it can be bi-directional right?

Regards,

Rojan

From: Ali Raissinia <alirezar@xxxxxxxxxxxxxxxx>
Sent: Wednesday, April 20, 2022 12:02 AM
To: STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBF] 回复: Feedback on 1934r5

Essentially, we have defined session setup as primarily a capability exchange phase thus not need to be ‘protected’. Sensing measurement setup is when parameters of sensing are assigned and there’s binding between peers to begin measurement exchange hence it would need to be protected.

For unassociated case, since MS query happens after PASN (as client knows PMF is required) it is able to benefit from PMF and protect client’s sensing capabilities as well as the fact that client has initiated a request for measurement setup exchange.

Ali

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Tuesday, April 19, 2022 8:46 AM
To: Ali Raissinia <alirezar@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBF] 回复: Feedback on 1934r5

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Correct. MS Request/Response after the SA is complete allows the setup between the Sensing Responder and Sensing Initiator to be protected. Anything exchanged prior to SA establishment cannot be trusted in a secure environment.

Cheers,

Mike

On Tue, Apr 19, 2022 at 11:42 AM Ali Raissinia <alirezar@xxxxxxxxxxxxxxxx> wrote:

It is not clear to me sharing sensing capabilities sent in Beacon, Probe Response and potentially in Association frame exchanges result in any security compromise. However, Authentication after Association can protect MS Request/Response in order to protect the sensing parameter assignments plus the knowledge of the measurement exchange occurrences.

Ali

From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Tuesday, April 19, 2022 8:30 AM
To: Ali Raissinia <alirezar@xxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBF] 回复: Feedback on 1934r5

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Ali,

The association request/response is not protected so I don't believe that is sufficient to establish a sensing session, particularly when security is required. Something needs to happen once the SA is in place.

Cheers,

Mike

On Tue, Apr 19, 2022 at 11:25 AM Ali Raissinia <alirezar@xxxxxxxxxxxxxxxx> wrote:

Gents, for the association case when device has obtained AID it has established session because it exchanged its sensing capabilities during the association frame exchange hence ready to be used for measurement setup exchange. Use of PMF or PASN is only needed when security is required.

Ali

From: 罗朝明(Chaoming Luo) <000015d97e832564-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, April 19, 2022 8:20 AM
To: STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBF] 回复: [STDS-802-11-TGBF] 回复: Feedback on 1934r5

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Mike,

I think we have discussion in your "22/0401r3" about whether sensing requires RSN with PMF, I don't understand why PMF has nothing to do with sensing.

For additional authorization specific for sensing measurements, I don't see any consensus for it up to now, and I'm not proposing it.

BR,

Chaoming

发件人: M Montemurro <montemurro.michael@xxxxxxxxx>
发送时间: 2022年4月19日 23:11
收件人: 罗朝明(Chaoming Luo) <luochaoming@xxxxxxxx>
抄送: STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx>
主题: Re: [STDS-802-11-TGBF] 回复: Feedback on 1934r5

HI Chaoming,

PMF is just a feature that is negotiated during security establishment that allows management frames to be protected. Again, it has nothing to do with sensing and in my opinion, cannot be assumed to provide authorization for sensing measurements. Either you need another sensing setup exchange to provide authorization or you need to add sensing authorization to the 4-way handshake.

Cheers,

Mike

On Tue, Apr 19, 2022 at 11:07 AM 罗朝明(Chaoming Luo) <luochaoming@xxxxxxxx> wrote:

Hi Mike,

IMHO sensing may require the feature of protection of management frame which depends on PTK, that's the reason I say sensing session is established after the 4-way handshake for associated STAs.

BR,

Chaoming

发件人: M Montemurro <montemurro.michael@xxxxxxxxx>
发送时间: 2022年4月19日 23:00
收件人: 罗朝明(Chaoming Luo) <luochaoming@xxxxxxxx>
抄送: STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx>
主题: Re: [STDS-802-11-TGBF] 回复: Feedback on 1934r5

Hi Chaoming,

For Claudio's information, the 4-way handshake is a protocol exchange between a STA and an AP to derive a PTK.

Also I'd like to understand the intention here, because I don't believe completion of the 4-way handshake can be used to assume anything with respect to sensing - unless there is a plan to include sensing authorization information in the 4-way handshake.

Thanks,

Mike

On Tue, Apr 19, 2022 at 10:56 AM 罗朝明(Chaoming Luo) <000015d97e832564-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

Hi Claudio,

I'm fine to list the frames used in 4-way handshake, but I guess people may argue that it's already in baseline and do not need SP for it, anyway I'll add it and see whether there are other comments.

I'll make those four roles as TBD, as Cheng also suggest further discussion for mandatory roles.

BR,

Chaoming

发件人: Claudio da Silva <claudiodasilva@xxxxxx>
发送时间: 2022年4月19日 22:48
收件人: 罗朝明(Chaoming Luo) <luochaoming@xxxxxxxx>; Claudio Da Silva <000015f3cbee3aeb-dmarc-request@xxxxxxxxxxxxxxxxx>; STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx>
主题: RE: Feedback on 1934r5

Hi Chaoming,

I’m just asking you to list the frames that make up the four-way handshake – to avoid ambiguity.

Yes, as a group, we will have to define a minimum feature set for 11bf.

Claudio

From: 罗朝明(Chaoming Luo) <luochaoming@xxxxxxxx>
Sent: Tuesday, April 19, 2022 7:44 AM
To: Claudio da Silva <claudiodasilva@xxxxxx>; Claudio Da Silva <000015f3cbee3aeb-dmarc-request@xxxxxxxxxxxxxxxxx>; STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: 回复: Feedback on 1934r5

Hi Claudio,

1. '4-way handshake' is a procedure already in the baseline, we're not adding any frame into the procedure. We just utilize the state established by the 4-way handshake procedure.

2. I'm open if the group wants to define a minimum set of mandatory roles, let's more opinions on this point.

BR,

Chaoming

发件人: Claudio da Silva <claudiodasilva@xxxxxx>
发送时间: 2022年4月19日 22:11
收件人: 罗朝明(Chaoming Luo) <luochaoming@xxxxxxxx>; Claudio Da Silva <000015f3cbee3aeb-dmarc-request@xxxxxxxxxxxxxxxxx>; STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx>
主题: RE: Feedback on 1934r5

Hi Chaoming,

Two points:

We must define which frames are sent as part of the 4-way handshake.
We can’t make all sensing roles to be optional first, and then define a minimum feature set. It won’t work. I suggest you delete the proposed initiator/responder/transmitter/receiver capabilities from slide 6. Defining the minimum feature set will require discussion.

Claudio

From: luochaoming@xxxxxxxx <luochaoming@xxxxxxxx>
Sent: Monday, April 18, 2022 8:03 PM
To: Claudio Da Silva <000015f3cbee3aeb-dmarc-request@xxxxxxxxxxxxxxxxx>; STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: RE: Feedback on 1934r5

Hi Claudio,

Thanks very much for your constructive comments! Please see my reply inline. And please let me know if you have further comments, thanks again!

BR,

Chaoming

From: Claudio da Silva

Date: 2022-04-19 02:49

To: STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx

Subject: RE: Feedback on 1934r5

Sorry, my last email has an error:

For example, define that support of the sensing ~~receiver~~ responder role is mandatory for 11bf capable STAs.

Claudio

From: Claudio da Silva <000015f3cbee3aeb-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, April 18, 2022 11:42 AM
To: STDS-802-11-TGBF@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBF] Feedback on 1934r5

Chaoming,

Thanks for all the work you have done on the session setup. I appreciate it.

Find below a few suggestions and questions on the SPs found in 1934r5.

Thank you for all your effort,

Claudio

·         Because SP3 describes the overall sensing session setup procedure, my suggestion is to begin with it (that is, make it SP1).

·         [cm] I did make the SP3 as SP1 during the previous offline discussion, but people think it's better to SP for the MS Query related sequences first, and I tend to agree that it's a simpler way to push forward.

o    The “4-way HS” for the associated case must be defined.

o    [cm] I'll correct the term as "4-way handshake", which is already in clause 3.2 and 12.7.6 of the baseline.

o    “For an unassociated STA, after PASN, if there is, an exchange of MS Query….” What does “if there is” refer to: PASN or “an exchange of MS Query…”?

o    [cm] it does refer to PASN. Would it be better to rewording as "For an unassociated STA, after PASN if PASN is used, an exchange of MS Query…"?

o    I do not believe the figures in slides 7, 8, 9… should be included in the draft. (If you would like to do so, you will need to reformat them.) Thus, my suggestion is that we don’t add them in the SFD. If there is any normative behavior defined in them that you would like to cover, please write text instead.

o    [cm] I'm fine with not adding them in the SFD. My intention was to make it easier to understand the procedure.

·         Propose the edits below (in blue) to (current) SP1. (Propose to make this SP2.)

o    The intend of the last sentence of this SP is not clear to me (“The polling TF within…”).

o    [cm] The intention of "The polling TF within…" is to describe the cases in slide 10 and 12, which are also related to when and how to use the MS Query frame.

·         I do not agree with some of the sensing capabilities defined in slide 6:

o    Can a STA be “11bf capable” if it does not support the roles of sensing initiator nor of sensing responder? We must define a minimum feature set for a STA to be “11bf capable.” For example, define that support of the sensing receiver role is mandatory for 11bf capable STAs.

o    [cm] My thinking is we may write a normative text such as "if a STA is sensing capable then it shall support at least one of the roles of sensing initiator and/or sensing responder". IMHO, "support of the sensing receiver responder role is mandatory for sensing capable STAs" appears a little bit strong, because there may be cases a STA only works as sensing initiator ("neither a sensing transmitter nor a sensing receiver" as in D0.01).

o    “Support of reporting”: Does this refer to the ability of a STA to send a Sensing Measurement Report frame or report measurements up to the application (same STA)? This must be defined.

o    [cm] Appologize for the confusion. I should have put a note there "refer to motion 60 for the exact meaning of optional reporting. "

Proposed changes to SP1:

[cm] Thanks for the refinement, I'll take it.

Do you agree to add the following into 11bf SFD?

·         An unassociated STA (denoted as U-STA) transmits the measurement setup (denoted as MS) Query frame to solicit an MS Request frame from an AP.

o    The MS Query frame may contain the detailed sensing capabilities of the U-STA.

·         Upon receiving an MS Query frame, the AP responds with an MS Request frame to the U-STA.

o    The MS Request frame contains the UID assigned to the U-STA.

o    The MS Request frame contains one bit to inform the U-STA to comeback before session timeout expires to solicit an MS Request frame.

·         The AP can also send a MS Termination frame to the U-STA, which contains one bit indicating termination of the sensing session.

·         The Polling TF within a measurement instance contains one bit to inform the U-STA to transmit an MS Query frame outside the measurement instance.

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

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

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-TGBF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBF&A=1

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

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

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