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

Re: [STDS-802-11-TGBI] What happens when a non-AP MLD changes EDP epoch group?



Hi, 

In my understanding, the EDP Epoch Response frame should be received well in advance so that the non-AP MLD is able to compute all its FA parameters. Then it will wait until the time of the next epoch change and apply them. first question is what happens if the response frame arrives so that the non-AP MLD does not have time to change its parameters? it aborts? disassociate?

This question is not clear. I am not sure is there any problem on this case. 
At least there is no need to add new disassociation reason for this case.  


EDP FA block =KDF-Hash-Length( KDK, "EDP CPE frame anonymization", n)
I agree that current anonymization calculation has issues. 

The time based pattern creation, replace n with some TSF, will be challenging:
- This would need some master clock for the AP MLD that is not currently defined. 
- The scheme will not work in  seamless mobility domain where STA uses the same PTK for all AP MLDs (per-SMD PTK). In this scenario, the AP MLDs in SMD may repeat the same TSF which will result in the same anonymization pattern use in different AP MLDs.
  
I think better solution is to include more input parameters to the anonymization block calculation, so that FA block is unique per epoch and AP MLD. 
Also it is better to use Per-AP MLD PTK in SMD, so that all AP MLDs in SMD cannot track the non-AP MLD by detecting the pre-calculated MAC addresses. 

Cheers,
Jarkko     

On Jul 3, 2025, at 9:03 AM, BARON Stephane <Stephane.BARON@xxxxxxxxxxxx> wrote:

Hi Antonio, Hi Phil
 
Please see my answers inline below. (in Blue)
 
Best regards.
 
Stéphane.
 
From: Philip Hawkes <000047a0059a9b2d-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: jeudi 3 juillet 2025 03:07
To: STDS-802-11-TGBI@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBI] What happens when a non-AP MLD changes EDP epoch group?
 
BEWARE: This email originated outside of our organization. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe.
Please report all suspicious emails to the ISS department as an attachment. 
 
Hi Antonio, I have responses inline below (in green font starting [PH]) to your questions about generation of EDP FA Block. Cheers,Phil

From: Antonio DeLaOlivaDelgado <aoliva@xxxxxxxx>
Sent: Wednesday, July 2, 2025 4:43 PM
To: STDS-802-11-TGBI@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBI@xxxxxxxxxxxxxxxxx>
Subject: [STDS-802-11-TGBI] What happens when a non-AP MLD changes EDP epoch group?
 

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

Dear, 
I have several CIDs asking to describe what happens when a non-AP MLD changes its group, maybe after receiving an EDP Epoch Request frame.
 
In my understanding, the EDP Epoch Response frame should be received well in advance so that the non-AP MLD is able to compute all its FA parameters. Then it will wait until the time of the next epoch change and apply them. first question is what happens if the response frame arrives so that the non-AP MLD does not have time to change its parameters? it aborts? disassociate?
 
I have also noticed that the calculation of the FA parameters, which is the following:

EDP FA block =KDF-Hash-Length( KDK, "EDP CPE frame anonymization", n)

Will result on the same parameters for the same user in the same relative n, is not it?
[PH] According to current definition: yes.
[SBA] I currently have some comments to solve regarding this definition. “n” is a poor solution that have been put in place as a compromise but that shows evident drawbacks.
 
So if we have one user in EDP epoch 1 with relative number 10, which has been there during epoch with relative number 9, and changes to a new epoch group 2 which next relative epoch number is 7, in two epochs (relative epoch number 9) its EDP FA block in epoch group 2 will be the same as in the epoch group 1, relative number 9. 
Is my interpretation correct?
[PH] According to current definition: I believe so.
[SBA] I agree and this is not acceptable.
 
is this what we want?
[PH] No! As you point out, this can result in an epoch deriving an EDP FA block identical to the EDP FA block of an earlier epoch of another epoch group, which will be easily detectable since all affiliated STAs of all non-AP MLDs will using identical MAC addresses in both epochs.
There are two changes help avoid such scenarios:
1. In the place of (n) in the KDF context, use EpochTSFStartTime(n) or PlannedTSFStartTime(n) (defined in 10.71.2.4 EDP Epoch Start Time Computation)). This was the original proposal for generation of EDP FA block.
2. Include the EDP Group ID  (defined in (9.4.1.84 EDP Epoch Settings field)) in the KDF context
 
One or both of these changes could be applied.
[SBA] My preference would be [1] since today we have no rule for the Group ID assignment, and the reuse of a previously used group ID for a same station would end up with the same sequence of MAC addresses for a given STA. We just need to be sure the computation of those times are performed on the link used for EDP setup. This is the content of the resolution I am preparing for this issue.

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


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



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