Re: [STDS-802-11-TGBE] Security comment resolutions on OCVC

[Yongho Seok <yongho.seok@xxxxxxxxx>]

Hi Mike, 

Regarding CID 11071, this part is for 320 MHz OCI discussion different with the multi-link OCI. 

In 320 MHz BSS operation, the Operating Class field and the Primary Channel Number field in the OCI element can only support identifying the primary 160MHz channel. 

This is happened because 320 MHz follows overlapping channelization. 

Before 320 MHz, 80 MHz 160 MHz channelization followed non-overlapping channelization. So, the Operating Class field and the Primary Channel Number field were  sufficient enough to identify the BSS operating channels. (Please remind that, to identify secondary 80 MHz in 80+80 MHz BSS, the OCI element has the Frequency Segment 1 Channel Number field which is set to the channel center frequency index of the secondary segment.

In consequence, the missing part in 11be is how to identify the secondary 160 MHz channel in 320 MHz operating channel.

So, I think that the following comment from Po-kai may work. 

"Frequency Segment 1 Channel Number" to simply "Channel center frequeny of 320 MHz", which is set to channel center frequency of 320 MHz when 320 MHz is used and 0 otherwise.

Thanks, 

Yongho 

2022년 10월 7일 (금) 오전 8:22, M Montemurro <montemurro.michael@xxxxxxxxx>님이 작성:

Hello all,

I took a second look at the following comments on OCVC, which were deferred (see bottom if email)

The purpose of OCVC was to verify that an ongoing exchange was taking place on the channel that both parties believed to be the same. Given that for MLO, the exchanges take place on the same link, existing OCVC procedures will work as specified in the baseline. There is no need  to include link ID information in the OCI KDE.

Furthermore, the requested links provided in the reassociation request, and the  links advertised links included beacons and probe responses are both validated as part of the 4-way handshake.  

I'm inclined to reject these CIDs unless somebody can provide some explanation on what the problem is and why providing operating channel information for links addresses the issue.  

Thanks,

Mike

Comment

CID	Clause	Page	Line	Comment	Proposed Change
11071	12.7.6.1	355	45	The description implies that OCI KDE can be used for MLO. However, OCI KDE needs to be redesigned to include link ID and information for 320 MHz verification because 320 MHz may have 320 MHz-1 or 320 MHz-2.	Define MLO OCI KDE. Ideally, follow the format of OCI KDE to include link ID and change "Frequency Segment 1 Channel Number" to simply "Channel center frequeny of 320 MHz", which is set to channel center frequency of 320 MHz when 320 MHz is used and 0 otherwise.
10678	12.7.6.3	358	46	For MLO, OCI verification should occur on all the links. Will need to make sure OCI works correctly for MLO. e.g., we should include the OCI KDE for each requested link in msg 2 for the AP MLD to verify the operating channels of the STAs corresponding to the requested links	As in the comment
10679	12.7.6.4	361	11	For MLO, OCI verification should occur on all the links. Will need to make sure OCI works correctly for MLO. e.g., we should include the OCI KDE for each requested link in msg 3 for the non-AP MLD to verify the operating channels of the APs corresponding to the requested links	As in the comment
14100	12.7.2	351	5	OCI KDE should have a corresponding MLO KDE defined because RNR in ML probe response is not protected	As in comment

---

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

---

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