Re: [RFC 0/4] EAPoL over NL80211

[Arend van Spriel <arend.vanspriel@broadcom.com>]

On 12/29/2017 7:29 PM, Denis Kenzior wrote:
> Hi Arend,
>
> <snip>
>
>>> To make this possible this patchset introduces a new NL80211 command
>>> and several
>>> new attributes.  A userspace that is capable of processing EAPoL
>>> packets over
>>> NL80211 includes a new NL80211_ATTR_CONTROL_PORT_OVER_NL80211
>>> attribute in its
>>> NL80211_CMD_ASSOCIATE or NL80211_CMD_CONNECT requests being sent to
>>> the kernel.
>>> The previously added NL80211_ATTR_SOCKET_OWNER attribute must also be
>>> included.
>>
>> Does it make sense to require a combination of attributes. It is
>> always a bit awkward so prefer to avoid it. Could we implicitly make
>> the netlink unicast for notifications when
>> NL80211_ATTR_CONTROL_PORT_OVER_NL80211 is provided by user-space.
>>
>
> Agreed, requiring both attributes is less than ideal, but I tried to
> make the initial RFC as minimal as possible.  It also helped that iwd
> uses SOCKET_OWNER by default.  What can be done is to always set
> conn_owner_nlportid and introduce another flag that would indicate
> whether 'connection tear-down on application exit' was requested.
>
> However, my opinion is that the current SOCKET_OWNER behavior should
> just be made default, especially for control port over nl80211
> connections, even if SOCKET_OWNER was not requested.  Once the
> controlling application dies, there's no hope of salvaging the
> connection, perform rekeys, etc.

If you mean that all notifications need to be unicast I tend to 
disagree. It would kill the multicast functionality. If you just mean 
for NL80211_CMD_ASSOCIATE or NL80211_CMD_CONNECT it makes sense for 
secure connections, but what about unencrypted connections.

> <snip>
>
>>> 2. It has been previously suggested that CMD_FRAME infrastructure is
>>> used to
>>> accomplish control port over nl80211 transport.  However, it did not
>>> seem to be
>>> a good fit as the relevant code paths assume that only management
>>> frames are
>>> to be sent via this mechanism.  Thoughts?
>>
>> What are the issues coming from that assumption? Does it assume 802.11
>> header is present? What else?
>>
>
> Correct.  There's also quite a bit of logic to figure out whether the
> frame is being sent offchannel or not; whether offchannel capability is
> present in the driver, etc.  This can be ignored for control port
> frames, but makes the code path complicated.

It seems to boil down to a single question "offchannel or not" so I 
suppose that bit of logic could be isolated.

> The biggest issue was that each driver defines a set of management
> frames it can accept via this mechanism.  The set is structured using
> management frame type as an identifier and the code checks this set
> prior to accepting the frame to be sent via CMD_FRAME.  Since control
> port frames are data frames it would probably require quite a bit of
> surgery in the core mac80211/wireless code and the driver code to make
> it work.

Yes. It assumes management frame type and as such subtypes are stored in 
struct wiphy::mgmt_stypes. Together these are part of the frame control 
field in 802.11 header. So I suppose you could add struct 
wiphy::data_stypes, but for "eapol over nl80211" you may want to add 
ethernet protocol in the mix. I am not sure if we need subtype 
granularity for data frametypes as I think the 802.11 stack, ie. 
mac80211 or some fullmac firmware, decides the subtype further down.

> Another issue is that cfg80211_mgmt_tx_params doesn't have a 'don't
> encrypt' setting.  So that part would need to be added as well.

True. Looking at the above I would stick with the separate primitive 
although the name might be a bit more generic so it can be used for the 
pre-auth protocol as well.

Anyway, I will review the individual patches keeping this in mind. 
Thanks for the clarifications.

Regards,
Arend