On Wed, Mar 02, 2016 at 07:10:52PM +0100, M. Braun wrote: > I'm thinking about choosing one of a1 / b1 / a2 / b2. > I'd be fine implementing a1 as this provides all I need. But if any of > over variants is required, that might be feasable as well. > > Structure: > > a) use TLV. This completely breaks backward compatibility. > > b) keep the existing format, add a magic cookie (like DHCP/BOOTP > migration) after the existing message and then add TLV. > This should keep compatibility for the attributes already in the > message struct. For b, could define new frame_type values (though, this is not really nice even with the current ones which are not really properly assigned) or a completely new frame type. The latter could be considered especially if we were to move from a MAC frame to something on top of IP to allow routing of AP-to-AP communication. As far as (a) vs. (b) is concerned, I think I'm willing to drop backwards compatibility once for this taken into account the origin and state of the current protocol. That said, if it is straightforward to leave the current option in place as-is and define a new one independently, there could be some value in doing so and remove the current (i.e., the old at the time) version eventuality after couple of released versions. > Encryption > > 1) As IPsec-over-UDP with static keys results in something similar to > the current encryption, encryption might just be dropped in hostapd. > Using IPsec or some other VPN solution is also more flexible with > respect to the available key management schemes. In theory, yes, this would be quite nice. That said, I find it quite unlikely that people would be setting up anything secure between APs.. > 2) Hostapd is currently missing some MAC. So replace aeswrap with an > AES-GCM implementation. AES-GCM has the complexity of the IV value having to be unique for every single use with a specific key. In other words, using AES-GCM would come at the price of having to define a mechanism to derive and manage new keys and/or unique IV space.. > Additionally, if the key provided is all-zero, encryption and > authentication could be skipped (for example if used with a VPN). > This way users that do not need in-hostapd encryption/authentication > of the message can skip it and reduce cpu time needed. I'm not sure I like this and certainly not with "all-zero key" as the way of configuring this. If the new mechanism is over an IP connection, it would be somewhat easier to justify that external VPN configuration needs to be used. Though, this would also come with the price of having to have IP addresses for the APs to be configured statically are learned through some mechanism (I guess this could use DNS as well, if desired). -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
