Re: [STDS-802-11-TGBN] Your PPT on MAP protection

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

On Tue, Feb 11, 2025 at 7:37 PM <yang.zhijie@xxxxxxxxxx> wrote:

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>
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>;
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>
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>;
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