Hi Abhi ,
Thanks for the response. There is some misunderstanding on your side, let's try to clarify in the reflector.
If your look at the following figure captured from my contribution, the L-AP(or mesh STA in the SP) only own MAPC discovery and MAPC authentication function, once the trust link is setup between two mesh STAs , AP1 and AP2 can generate the PTK and exchange the GTK , and protect the following MAPC frame exchange. Again, the procedure of MAPC negotiation and MAPC transmission is still between two UHR APs , not between two mesh STAs . This framework allow the two APs are configured with the same credential information(to reuse SAE(authentication using a password)) without disclosing their infrastructure credential information to each other.
As Mike suggested before, the mesh protocol allow the mesh STA to authentication with multiple mesh STAs , that's why we try to reuse some of the useful mesh procedure.
Anyway, I hear some members said they don't like the mesh protocol, and we could define a new MAPC security procedure to allow inter-vendor authentication, let's walk on this direction if no one object it.
Thanks
Best Regards
Jay Yang (杨志杰)
Hi Mike, Jay, Xiaofei ,
In 11s mesh, two mesh STAs perform mesh peering - which is a form of loose association between them. The peering is directional, and each party need to initiate it. The AID that is assigned is used (amongst other things) for traffic indication (via TIM IE in each STA’s Beacon frame). So, in some sense, it is AP/client relationship (based on the direction).
In MAPC , APs negotiate the terms of coordination for one or more flavors of MAPC . The intention of AP ID is to identify the AP during the coordination TXOP (i.e., triggering). Therefore, MAPC negotiation must not be equated to performing associating or peering. Let’s not mix them or try to force fit MAPC negotiations into 11s peering framework.
Regards,
Abhi
From: Jay Yang <yang.zhijie@xxxxxxxxxx>
Sent: Tuesday, February 11, 2025 4:37 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] Your PPT on MAP protection
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
Hi Mike,
Thanks for the clarification, that's why I propose to define a light Mesh STA concept, as we don't need all the functionality of the current mesh STA.
Hi Xiaofei ,
As the mesh protocol already define the mesh discovery procedure, we can insert some MAPC relevant IEs into the message exchanged in the discovery procedure(also, strip out the unnecessary part). On the other hand, MAP discovery procedure is invisible to the client, define a light probe request/reponse or Beacon via the mesh discovery procedure can void the overhead issue.
Hope the above explaination can address you concern, and welcome the further comments.
A clean revision of SP text:
Do you agree to define light mesh STA with the following:
1) a modified mesh procedures to support MAPC discovery and support MAPC authentication（including PTK generation and GTK exchange) .
Note1: It's TBD to reuse or modify the AMPE or PASN protocol.
Note2: Other functionalities are TBD .
Thanks
Best Regards
Jay Yang (杨志杰)
Original
From: MMontemurro <montemurro.michael@xxxxxxxxx>
Date: 2025年02月12日 03:19
Subject: Re: [STDS-802-11-TGBN] Your PPT on MAP protection
Hi Xiaofei ,
The pieces of mesh that I was referring to were peering messages (Open/Confirm/Close) along with group key behavior (to protect MAP). We could also strip out fields/elements of peering messages that we don't need.
This would be work TBD .
Cheers,
Mike
On Tue, Feb 11, 2025 at 12:48 PM Xiaofei Wang <Xiaofei .Wang@xxxxxxxxxxxxxxxx> wrote:
Hi Mike & Jay,
Thanks for the discussion. I was wondering which portion of the mesh protocol is used for discovering MAP? Could you elaborate?
Thank you!
Xiaofei Clement Wang
Principal Engineer | InterDigital
T: (631) 622.4028
E: Xiaofei .wang@InterDigital .com
From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Tuesday, February 11, 2025 9:15 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] Your PPT on MAP protection
Hi Jay,
Thanks for your response. I'm not exactly clear on what you mean by "light mesh STA". We could certainly update AMPE to address peering in less messages.
I think we'd need more details. But based on what I 'think" you are proposing, I'd suggest a straw poll like this:
Do you agree to define light mesh STA for MAPC with the following functionalities and features:
1) Modifying mesh procedures to support M-AP discovery and M-AP authentication（including PTK generation and GTK exchange) to support MAPC .
2) Collocating with the AP(s) that intends to participate MAPC scheme <not sure what this means but willing to discuss>
3) Not allowed to set up association with another light mesh STAs . <not sure what this means but willing to discuss>
Note1: It's TBD to reuse or modify the AMPE or PASN protocol.
Note2: Other functionalities are TBD .
Cheers,
Mike
On Mon, Feb 10, 2025 at 10:42 PM <yang.zhijie@xxxxxxxxxx> wrote:
Hi Mike,
Thanks for the comment during the call and initiating the mail thread in reflector. (Sorry for my delay response)
I appreciate you provide a simple direction for MAPC protection with some high level guidance. I totally agree what you said, we should define or reuse something like current mesh protocol. I propose to reuse PASN because the authentication, PTK generation, and the proposed GTK exchange can be done within 3 authentication frames exchange( after KEK in PASN enabled), while the current authentication and AMPE in mesh protocol belongs two separated procedures, and the later one may cause some overhead issue compared with PASN . Anyway, we could discuss more on this point.
And I plan to run the following SP if other members also support this direction:
Do you agree to define light mesh STA for MAPC with the following functionalities and features:
1) Dedicating for M-AP discovery, M-AP authentication（including PTK generation and GTK exchange).
2) Collocating with the AP(s) that intends to participate MAPC scheme
3) Not allowed to set up association with another light mesh STAs .
Note1: It's TBD to reuse or modify the AMPE or PASN protocol.
Note2: Other functionalities are TBD .
Welcome the further comments on this.
Thanks
Best Regards
Jay Yang (杨志杰)
Original
From: MMontemurro <montemurro.michael@xxxxxxxxx>
Date: 2025年02月07日 00:18
Subject: [STDS-802-11-TGBN] Your PPT on MAP protection
Hi Jay,
I really appreciate you bringing up this MAP protection issue.
The reason why I brought up Mesh for protecting MAP coordination was because:
a) mesh peering is fairly lightweight
b) broadcast among peers is already addressed
c) Mesh already handles multiple authentication and is agnostic to the authetnication type.
d) Mesh handles many to many peer connections.
e) I think you need some basic state information between peer APs to use MAP.
I'm not suggesting we establish a mesh network with all the features, just borrow the parts that we need.
Cheers,
Mike
To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1