Mark,
(On your second point about CID 4009)
But, first, the device ID will come from the network first, so since it is limited to sending 252, the client will never have one that is bigger than that to worry about sending it to the AP.
Second, in terms of mixing into the 4-way handshake versus other delivery, again, I don’t there is a (meaningful?) use case where the same device ID would be mixed across different methods, so if the AP/network can deliver one to the non-AP STA initially, I think it will always work for any time the non-AP STA wants to return it.
But, perhaps I’m missing something?
Mark
From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Wednesday, 17 July, 2024 11:05
To: mark.hamilton2152@xxxxxxxxx; 'Harkins, Dan' <daniel.harkins@xxxxxxx>; STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBH] padding discussion
At this point, we have an agreement from the group (from yesterday) to mark CID 4008 as Revised: Incorporate the changes shown in https://mentor.ieee.org/802.11/dcn/24/11-24-1026-02-00bh-resolution-of-padding-cids.docx. (Recall that CID 4008 is about the text in AF.2 that talks about how the maximum size(s) are derived, etc., which Dan’s 11-24/1026 replaces.
I would like to hear from anyone else (in addition to Mark R) who would like a different resolution. Otherwise, we’re going to need to move on, with the one noted objection. (And, Mark R, do you want to be personally noted on the objection?)
Yes please. Helps with my resubmission on the next draft!
Then, I want to sort out CID 4009, which is asking for a statement about the maximum size of the Device ID field, in clause 9 locations (presumably each/every location in clause 9, as the comment is not more specific). I think the proposal from Dan (to go with our agreement yesterday (above)) is that clause 9 does not need any such statement, because the maximum length in the protocol itself is the (implied) maximum that will fit in the structures. Any restrictions because of the device ID being included into a larger structure, encrypted, etc., are covered by Dan’s proposal in AF.2, when that is used.
So, I think that means CID 4009 is actually now: Rejected. The Device ID field can be the maximum size that will fit in the protocol constraints, which is an implied rule for all elements without an explicit statement. (Or something like that.)
I would like to hear from anyone with comments/concerns about this direction for CID 4009.
That doesn't work, because in the Device ID element the device ID can be 253
octets when sent to an AP but only 252 octets when sent by an AP, but in a
Device ID KDE the device ID can only be 251 or 250 octets respectively.
This is orthogonal to AF.2.
[I haven't checked PASN/measurement IDs, but I expect similar variation.]
Thanks,
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: mark.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx>
Sent: Wednesday, 17 July 2024 17:23
To: Mark Rison <m.rison@xxxxxxxxxxx>; 'Harkins, Dan' <daniel.harkins@xxxxxxx>; STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBH] padding discussion
Thank you both (Dan and Mark).
At this point, we have an agreement from the group (from yesterday) to mark CID 4008 as Revised: Incorporate the changes shown in https://mentor.ieee.org/802.11/dcn/24/11-24-1026-02-00bh-resolution-of-padding-cids.docx. (Recall that CID 4008 is about the text in AF.2 that talks about how the maximum size(s) are derived, etc., which Dan’s 11-24/1026 replaces.
I would like to hear from anyone else (in addition to Mark R) who would like a different resolution. Otherwise, we’re going to need to move on, with the one noted objection. (And, Mark R, do you want to be personally noted on the objection?)
Then, I want to sort out CID 4009, which is asking for a statement about the maximum size of the Device ID field, in clause 9 locations (presumably each/every location in clause 9, as the comment is not more specific). I think the proposal from Dan (to go with our agreement yesterday (above)) is that clause 9 does not need any such statement, because the maximum length in the protocol itself is the (implied) maximum that will fit in the structures. Any restrictions because of the device ID being included into a larger structure, encrypted, etc., are covered by Dan’s proposal in AF.2, when that is used.
So, I think that means CID 4009 is actually now: Rejected. The Device ID field can be the maximum size that will fit in the protocol constraints, which is an implied rule for all elements without an explicit statement. (Or something like that.)
I would like to hear from anyone with comments/concerns about this direction for CID 4009.
Thanks. Mark
From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Wednesday, 17 July, 2024 8:22
To: Harkins, Dan <daniel.harkins@xxxxxxx>; STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx; 'mark.hamilton2152@xxxxxxxxx' <mark.hamilton2152@xxxxxxxxx>
Subject: RE: [STDS-802-11-TGBH] padding discussion
I think we should not duplicate information, especially since (as now)
it seems there is some degree of uncertainty about what the maximum
transmission size of a Device ID is (240, as I understand it).
NOTE--The maximum size of device ID that can be opacified using this scheme is the maximum size of device ID that can be communicated (see <wherever the 240 limit is specified>) minus the opacification overhead (17 octets (1 for the pad indicator and 16 for the SIV tag) plus padding plus tweak).
covers it all. It enables implementers to work out how big their
device ID can be before it can't be opacified.
Thanks,
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: Harkins, Dan <daniel.harkins@xxxxxxx>
Sent: Wednesday, 17 July 2024 15:15
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] padding discussion
I think it's helpful for implementers to have a hard number like that. Note that if our consensus was 240 octets it doesn't matter because 240 is wrong as 240 + the opacification overhead = 257 which will end up as 1 because the length is a single octet. We have to be correct. The maximum device ID can be more than 233, it's just that such a device ID cannot be used with the opacification scheme in annex AF. And that's what it says now.
regards,
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
On 7/17/24, 7:03 AM, "Mark Hamilton" <mark.hamilton2152@xxxxxxxxx> wrote:
All,
I’ll remind the group that (if I recall correctly) we added material explaining the derivation of these “magic numbers” in response to a comment earlier in our process. I am concerned that reversing that direction, and going back to a more general/vague statement that just has the magic numbers (without the derivation) will result in some voter(s) becoming unhappy again.
So, question to the reflector (here):
Are you okay with (or even prefer) to leave unstated the derivation of the required limits on the maximum size of a device ID (or an encoded Device ID, and/or an encrypted opaque identifier – let alone a PASN ID or Measurement ID)?
Thanks for any comments/discussion.
Mark
From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Wednesday, 17 July, 2024 5:41
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] padding discussion
I'm still struggling with this.
From a discussion with the other Mark I'd understood the consensus was
to limit device IDs to 240 octets. But then in:
The overhead of the scheme is 17 octets—1 for the pad indicator and 16 for the SIV tag—plus padding and plus the size of the tweak. Device identifiers that are greater than 233 octets cannot be opacified using this scheme.
Note: 233 is the maximum size of a device ID with no padding and no tweak minus the overhead.
I don't understand the 233.
I think it would be safer to keep it vague, something like just:
NOTE--The maximum size of device ID that can be opacified using this scheme is the maximum size of device ID that can be communicated (see <wherever the 240 limit is specified>) minus the opacification overhead (17 octets (1 for the pad indicator and 16 for the SIV tag) plus padding plus tweak).
Thanks,
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: Harkins, Dan <daniel.harkins@xxxxxxx>
Sent: Tuesday, 16 July 2024 21:25
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBH] padding discussion
Please see document 11-24/1026r1 for proposed changes to address the continued issue with the padding description in the annex (plus the fixing of a typo).
Dan.
--
"the object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." – Marcus Aurelius
To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1
To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1