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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
