[Patch 3/3] Network steering feature

[Jouni Malinen]

On Thu, Oct 06, 2016 at 03:24:18PM -0700, David Weidenkopf wrote:
> > Could you please clarify where this protocol definitions for messages
> > exchanged between APs comes from?
> This is a new AP coordination protocol to provide coordinated BSS transitions.

There is ongoing effort to update the existing FT AP-to-AP protocol:
http://patchwork.ozlabs.org/patch/674418/

It sounds like there should be a single protocol defined that will cover
both of these needs rather than designing something completely different
for each.

> > I'm also not exactly happy with choosing an ethertype "random from unassigned".
> We will remedy this either by piggybacking on the 802.11r messages or
> by registering for an ethertype.
> We would appreciate your input to help guide our decision. Should this
> be an extension to 802.11r
> since it shares so much in common? Or instead should we begin the
> standards process from scratch?

As long as the message type/subtype gets assigned properly, I'm fine
with either approach. It should be noted that the current FT push/pull
protocol in hostapd is not assigned properly, so building on top of that
is not really an option before it gets redesigned in a manner that does
not simply pick reserved values and hope for the best that the standard
never uses those..

While getting a new Ethertype for hostapd purposes would be kind of
convenient, I'm not exactly fond of the $3095 registration fee..
Subtyping an existing Ethertype would likely be a more supportable
approach. If someone one the list happens to be aware of an organization
willing to assign a subtype for this type of purpose (i.e., something
that would be assigned to hostapd/wpa_supplicant so that we can
sub-subtype that for needs within hostap.git), please let me know. I
know that Atheros has an Ethertype assigned, but I'm not completely sure
how it is managed nowadays. I might be able to get a subtype from there,
but will need to first figure out how to get that properly assigned.

> > I don't see any kind of authentication in the protocol. What protects
> > this from injection of packets from unauthorized devices? Couldn't all
> > associated stations in the network send these messages to trigger APs to
> > react for arbitrary MAC addresses, e.g., to cause denial of service or
> > improve the network conditions for themselves?
> We propose to change our implementation to make use of the FT encryption keys.
> This would also benefit from a recent patch that simplified FT key
> configuration.
> [please see http://lists.infradead.org/pipermail/hostap/2016-September/036255.html].

We should find a common design. That may not be the specific one in that
patch (as noted in the discussion, I dropped that six patch series while
looking at the series pointed to above).

-- 
Jouni Malinen                                            PGP id EFC895FA