[PATCH 24/25] MBO: Always accept BTM request with disassociation imminent bit set

[Peer, Ilan]

> -----Original Message-----
> From: Jouni Malinen [mailto:j at w1.fi]
> Sent: Sunday, February 21, 2016 12:37
> To: Peer, Ilan
> Cc: hostap at lists.infradead.org; Stern, Avraham
> Subject: Re: [PATCH 24/25] MBO: Always accept BTM request with
> disassociation imminent bit set
> 
> On Sun, Feb 21, 2016 at 09:19:01AM +0000, Peer, Ilan wrote:
> > > From: Jouni Malinen [mailto:j at w1.fi] On Mon, Feb 15, 2016 at
> > > 04:53:59PM +0200, Ilan Peer wrote:
> > > > According to Multiband Operation specification (r17, section
> > > > 3.5.2), a BSS Transition Management Request with the
> > > > disassociation imminent bit set should always be accepted.
> > >
> > > The spec includes an exception for this: "another AP, if one [is] available".
> 
> > Could not find this in the version that I have (v17). What I have states that:
> >
> > "On receipt of an unsolicited BTM Request frame with a Disassociation
> Imminent bit set to one, the MBO STA shall be capable of responding with a
> BTM Response frame that shall contain the Status Code field (§ 8.6.14.10 in
> [3]) indicating accept. The MBO STA may also include the Target BSSID field (§
> 8.6.14.10 in [3]). When the Disassociation Imminent bit is set to one, the STA
> shall not reject the Transition Management Request"
> 
> I'm reviewing this based on the latest draft (r19). Anyway, that "shall not
> reject" is there.. Interesting. IMHO, this looks pretty bad requirement and as
> such, if it is needed, it will need to be made conditional on CONFIG_MBO (if
> not even something stronger; I'm willing to ignore pointless requirements in
> the spec in the default behavior).
> I'd say the spec should really be modified to not say that, though, since there
> is no such requirement in the IEEE 802.11 standard and it does not make any
> sense to be forced to accept something that cannot be done.
> 

I've asked our representatives to handle this the WFA, so we can wait for their
clarifications/changes on this. 

> > We were also confused about this :) Maybe the reason for this is that
> > as Disassociation Imminent is set the station does not have much choice and
> eventually would be disassociated so whether it initiated a transition to one of
> the candidates or not does not really matter.
> 
> Sure, but it should be valid behavior for a non-AP STA to wait for the AP to
> disconnect it if there are no other options for the non-AP STA to find
> alternative connection. Misusing BSS Transition Management frames to cause
> disconnection is not really the best approach for something like this since the
> AP can already use the standard Deauthentication frame as notification.
> 

Indeed. Looking at this again, this is also actually not compatible with the spec that
requires the station to disconnect after accepting the BTM.

Thanks,

Ilan.