Re: [STDS-802-11-TGBH] padding discussion

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

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:

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