[PATCH v2 07/14] AP: Rename SAE anti clogging variables and functions

[Peer, Ilan]

Hi,

> -----Original Message-----
> From: Jouni Malinen <j at w1.fi>
> Sent: Tuesday, January 26, 2021 13:01
> To: Peer, Ilan <ilan.peer at intel.com>
> Cc: hostap at lists.infradead.org
> Subject: Re: [PATCH v2 07/14] AP: Rename SAE anti clogging variables and
> functions
> 
> On Tue, Jan 26, 2021 at 07:01:26AM +0000, Peer, Ilan wrote:
> > So eventually this patch would end up by only renaming internal
> > functions and variables? Are you introducing another configuration
> > option to also set the PASN anti clogging?
> 
> I was first planning to just rename the internal functions and variables as part
> of these patch series. However, now that I thought more about the PASN
> comeback mechanism after your replies and after having re-read
> P802.11ax/D2.6, I think I'll just skip all the patches related to the comeback
> mechanism for now to get the rest of the patch series applied.
> It is starting look clear that the comeback mechanism needs more thought on
> both the AP and the station sides.
> 

Ok. AFAIU, you are referring to the implementation details and not the specification.

> For the station side (patch 10/14), I see no point in using external mechanism
> for the special case mentioned in the draft, i.e., when Comeback After value
> of 0 is used. That is just like the SAE anti-clogging mechanism, i.e., immediate
> retry with the cookie, and that needs to happen automatically within
> wpa_supplicant. The case with nonzero Comeback After value seems
> reasonable to handle external based on your explanation.
> 

I agree that the special case with the comeback ater 0 can be handled in the
wpa_supplicant. I can add such implementation once you are done with
the other patches.

> For the AP side, this PASN mechanism is much more flexible than the SAE
> one since there is an explicit indication of Comeback After and the reasons
> for using this can be quite different. As such, it may not be reasonable to
> share the same configuration parameter for this with SAE.

I thought that adopting the same approach as with SAE, at least in terms of
token generation and tracking would be good enough as an initial implementation,
which can be later be improved.

> Furthermore, the hardcoded value of 10 TUs for Comeback After may not be
> the best approach (0 TUs would sounds like a better default behavior, but
> there may be other reasons for the AP to behave more dynamically in this
> area).. And that was actually incorrectly documented in
> wpa_pasn_add_parameter_ie() as being seconds, not TUs..
> 

Agree. Again, that was only an initial implementation 😊 As with the case of
wpa_supplicant, I can also add a more comprehensive implementation also
for the AP side. 

Ilan.