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

Re: [STDS-802-11] TGbh Polling



--- This message came from the IEEE 802.11 Working Group Reflector ---

Dan,

Agree on the computing power of mobile devices (and S/W). Also agree simple hash can be done – or the use of the “blob”.

 

I also agree we do not need to solve the “pea” issue; however, we do need to be aware of being able to pass the STA identity to the upper layer apps that could tell you all about peas. Or am I off target on this as one of the issues that are to be addressed?

 

Finally agree that we need to hear from mobile device vendors – if they do not agree then they will not implement and all this work would be for not.

 

Luther

 

From: Harkins, Dan <daniel.harkins@xxxxxxx>
Sent: Tuesday, January 24, 2023 9:34 AM
To: Luther Smith <l.smith@xxxxxxxxxxxxx>; STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] TGbh Polling

 

 

  Hi Luther,

 

On 1/24/23, 6:13 AM, "Luther Smith" <l.smith@xxxxxxxxxxxxx> wrote:

 

--- This message came from the IEEE 802.11 Working Group Reflector ---

All,

 

Returning to the foundation of the working group, how do we fix the issues injected by RCM. If requiring the non-AP STA to do “computation” may put a burden on the non-AP STAs; however to have the AP STA do this may be less of a burden. (Thinking of simpler, low CPU non-AP STAs such as IOT devices).

With this stated, EBSS would need to share the “device ID” to enable functions that are broken by RCM. While there are some lower level items that have depended upon the MAC address, there are also upper layer applications there were depending on the MAC address to be static. (Captive Portal, Network access, legal intercept to name a couple).

 

I'm not so sure that "computation" is the issue. What are we talking about, a few hashes? IoT devices can do that and my phone has more power than the computers that took men to the moon (although the software back in the 60s was obviously of higher quality so there's that).

 

IMHO, it's not that the STA vendors would balk at a few hashes, it's that they don't have a compelling reason to implement anything to address the use cases we formed 11bh on. Even if the AP did all the work (which I would push back on) there are still changes required on the STA side. Yes, we argued about some things that the user of a STA might find useful ("I want to use my phone to get targeted advertisements for peas and detergent while I roam the aisles of the supermarket!") but is that sufficient customer demand for a vendor to put this work on a STA's roadmap given the other feature sets that are targeted for it? Color me doubtful but then I'd be interested in hearing the opinions of either of the two large handset vendors on this matter.

 

  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

 

From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Monday, January 23, 2023 4:56 PM
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] TGbh Polling

 

--- This message came from the IEEE 802.11 Working Group Reflector ---

All,

 

Please let me (the reflector) know if there is support from others for Straw Poll(s) trying to ask simply if there is consensus on a direction for pre-association scheme(s) to be “non-computation” or “computation”, per Graham’s suggestion.

 

Note that (per my previous email) I do think there is an outstanding request from the end of the Baltimore session to try an “Option 5” Straw Poll.  We could that or Graham’s suggestion, both, or one instead of the other.  I’m open to any suggestion that seems like it might get some direction for us.

 

Thanks! Mark

 

P.S., Graham, I am checking on your question about recording the results of a Straw Poll.

 

From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Sent: Monday, January 23, 2023 3:41 PM
To: mark.hamilton2152@xxxxxxxxx; STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11] TGbh Polling

 

Hi Mark,

I have been thinking about the results of the polls we had and it is difficult to get a clear picture as may be the votes were split among the schemes.

In an attempt to get a clearer picture of where the group wants to go I would like to propose the following Poll:

 

“Would you vote to include in the Draft one or more of the following schemes?

Non-computation schemes:

·         SMA

·         MAAD

·         IRM

·         Non-encrypted ID in IE (AP allocates)

·         Non-encrypted ID in IE (STA allocates )

 

Schemes with Computation:

·         IRMA

·         RRCM

·         ID encoding”

 

I would also request if there were any objections to recording the votes.  I know this is not normal but this has only been the case is only post-COVID. 

Maybe Mark, would you please ask the 802.11 Exec/Chair if it were permitted to ask the group if they would agree to a recorded Straw Poll vote, and further if this has to be unanimous?

 

Depending upon the result of the Poll, it would be a matter of searching for a scheme that had enough support.  We could start by polling non-computation versus computation, for example.

 

I would be interested in hearing others’ views, of course.

 

Thanks

Graham

 

 

 

From: G Smith
Sent: Monday, January 23, 2023 11:38 AM
To: mark.hamilton2152@xxxxxxxxx; STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11] TGbh conference calls announcement

 

Just noticed Option 5 is slightly different to option 3 in that the ID is supplied by the network.  In option 3 the ID was supplied by the STA.  The reasoning behind that was that we already had a network generated ID. 

Anyhow, if we want to make the list completely complete, then we should also add MAAD.

 

6         MAAD scheme

         AP picks MAC to be used next time, as per present rules (local bit).

         AP tells STA the MAC address it should use for the next association

         STA maintains list of ESS/SSIDs and latest MAC Addresses.

         AP maintains list of STA addresses

         Needs an “opt-in” mechanism (Capability bit or MIB variable?))

         ADs

         Simple, easy to implement. 

         Similar level of privacy as RCM (random MAC address for listener)

         Network can track STA

         Provides good protection against copying

         Meets every Use Case

         No computations

         DIS

         STA is constrained to MAC provided by AP last time.

 

Maybe a way ahead is to simply see if there is any way forward at all wrt pre-schemes.

 

A Poll to have pre-schemes at all

Then

A poll along the lines of “pre-schemes with or without computations”

 

Graham

 

 

From: G Smith
Sent: Sunday, January 22, 2023 10:37 AM
To: mark.hamilton2152@xxxxxxxxx; STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11] TGbh conference calls announcement

 

Hi Mark,

Re: 5th Option

This is the same as the 3rd Option.  It was already polled.

 

Graham

 

From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Saturday, January 21, 2023 8:04 PM
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11] TGbh conference calls announcement

 

--- This message came from the IEEE 802.11 Working Group Reflector ---

All,

 

With 10 days’ notice, as mentioned at the closing plenary yesterday, I am announcing TGbh teleconferences on the following Tuesdays, at 9:30 am ET, for 2 hours:

-          Jan 31

-          Feb 7

-          Feb 14

-          Feb 21

-          Feb 28

 

Agenda and call in details will follow, shortly.

 

Also note that I will be able to attend or chair the call on Jan 31, so one of the Vice Chairs will step in (thanks, Peter and Stephen!).

 

I anticipate that further discussion on the “5th option”, as described below, will be our next item of discussion on the way forward topic.  REMINDER: I am looking for a volunteer to champion/lead this discussion.  And, we need to complete the review of the latest proposed resolutions for comments on the D0.2 text.

 

5th option:

         Network generates an ID, communicated in 4-way handshake (similar/as done in D0.2)

         STA returns that ID in a new IE in a non-encrypted frame at next association (Association Request?) and/or pre-association frames

         ID is changed every association

         STA maintains list of ESS/SSIDs and IDs.

         Needs an “opt-in” mechanism

         Advantages

         Simple, easy to implement

         Provides good protection against copying

         Meets every Use Case

         No computations

         Disadvantages

         Requires new IE

         Needs to specify some uniqueness to ID (6 octets?)

 

 

Thanks.  Mark


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


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


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


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