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

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

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@xxxxxxxxxxxxxxxx

 

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