Thanks for your review, our responses are below. > 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. > Should the RFC-Network-Steering.txt be > part of the commit to document the protocol and how it is to be > configured? Yes until such a time as a standard can be accepted. > Especially the use of r0kh list (a parameter specific to FT) > is quite unexpected.. This protocol provides a means for the network to trigger FT so it does make some sense to integrate the capabilities. The domain of participants has a natural overlap and shared responsibility. > 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? > Is it clear that this protocol > would never need to be routed between APs that are not reachable within > the same physical network (e.g., any need for IP routing)? Yes, the protocol shares a mutual boundary with the DS and with the FT candidates. > 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]. > I started going through the details in all three patches and noticed > that the four new files added (patch 1/3 and 3/3) do not include any > copyright or license statements. Could you please provide an updated > version with such statements added (and hopefully with the same license > that is used throughout the repository)? I cannot apply any of the > patches without clear understanding on the licensing terms. Yes we will be happy to correct this oversight. > I'm attaching the snapshot version that I have in my review branch after > fixing couple of small issues and cleaning up some coding style issues > (far from complete on that front, though). Thank you. We wiil incorporate your changes and review for style compliance. > Please also note that there are number of allocation calls (at least > wpabuf_alloc()) that could fail and need to be checked against NULL > before dereferencing the pointer. Understood. We will update in our next submission. On Mon, Sep 19, 2016 at 9:32 AM, Jouni Malinen <j@xxxxx> wrote: > On Fri, Jul 29, 2016 at 08:48:20AM -0700, David Weidenkopf wrote: >> Introduction >> ---------------- >> The network steering system steers client STAs to the infrastructure AP >> with the best RSSI. APs collaborate and can use several methods to direct >> client STAs to transition to the best AP. >> >> Please review the attached txt for further details regarding this RFC. >> >> This RFC builds upon the previous two patches, "BSS transition with candidate >> list" and "Client station blacklist support". > > Could you please clarify where this protocol definitions for messages > exchanged between APs comes from? Should the RFC-Network-Steering.txt be > part of the commit to document the protocol and how it is to be > configured? Especially the use of r0kh list (a parameter specific to FT) > is quite unexpected.. I'm also not exactly happy with choosing an > ethertype "random from unassigned".. Is it clear that this protocol > would never need to be routed between APs that are not reachable within > the same physical network (e.g., any need for IP routing)? > > 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? > > I started going through the details in all three patches and noticed > that the four new files added (patch 1/3 and 3/3) do not include any > copyright or license statements. Could you please provide an updated > version with such statements added (and hopefully with the same license > that is used throughout the repository)? I cannot apply any of the > patches without clear understanding on the licensing terms. > > I'm attaching the snapshot version that I have in my review branch after > fixing couple of small issues and cleaning up some coding style issues > (far from complete on that front, though). > > Please also note that there are number of allocation calls (at least > wpabuf_alloc()) that could fail and need to be checked against NULL > before dereferencing the pointer. > > -- > Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
