[RFC] cfg80211: Let mgmt_tx accept frames destined for its own stack.

[RFC] cfg80211: Let mgmt_tx accept frames destined for its own stack.

[Javier Cardona]

This is useful for implementing frame protection in userspace. The kernel may
request a userspace daemon to verify a frame (sent to userspace via
cfg80211_rx_mgmt()).  The userspace daemon can then pass back the
verified/unprotected frame to the stack for further processing (via a
self-addressed frame sent with cfg80211_mlme_mgmt_tx())

We are using this for our implementation authenticated peering.  11s defines
two versions of mesh peering, the non-secure mesh peering management (MPM) and
the Authenticated Mesh Peering Exchange (AMPE).  The latter is based on the
exact same state machine as MPM.  It is really convenient to use the in-kernel
MPM with a minimal userspace daemon to add the security bits introduced by
AMPE.  This way both secured and open mesh networks can use exact same peering
code.

What do you think... will this fly?

---
 net/mac80211/cfg.c  |   12 +++++++++++-
 net/wireless/mlme.c |    3 ++-
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 5548a4c..8b6ff5a 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1773,6 +1773,7 @@ static int ieee80211_mgmt_tx(struct wiphy *wiphy, struct net_device *dev,
 	u32 flags = IEEE80211_TX_INTFL_NL80211_FRAME_TX |
 		    IEEE80211_TX_CTL_REQ_TX_STATUS;
 	bool is_offchan = false;
+	bool is_to_self = false;
 
 	/* Check that we are on the requested channel for transmission */
 	if (chan != local->tmp_channel &&
@@ -1792,6 +1793,8 @@ static int ieee80211_mgmt_tx(struct wiphy *wiphy, struct net_device *dev,
 	if (is_offchan && !offchan)
 		return -EBUSY;
 
+	is_to_self = !memcmp(mgmt->da, dev->dev_addr, ETH_ALEN);
+
 	switch (sdata->vif.type) {
 	case NL80211_IFTYPE_ADHOC:
 	case NL80211_IFTYPE_AP:
@@ -1799,7 +1802,8 @@ static int ieee80211_mgmt_tx(struct wiphy *wiphy, struct net_device *dev,
 	case NL80211_IFTYPE_P2P_GO:
 	case NL80211_IFTYPE_MESH_POINT:
 		if (!ieee80211_is_action(mgmt->frame_control) ||
-		    mgmt->u.action.category == WLAN_CATEGORY_PUBLIC)
+		    mgmt->u.action.category == WLAN_CATEGORY_PUBLIC ||
+		    is_to_self)
 			break;
 		rcu_read_lock();
 		sta = sta_info_get(sdata, mgmt->da);
@@ -1827,6 +1831,12 @@ static int ieee80211_mgmt_tx(struct wiphy *wiphy, struct net_device *dev,
 
 	*cookie = (unsigned long) skb;
 
+	if (is_to_self) {
+		ieee80211_rx_irqsafe(wiphy_to_ieee80211_hw(wiphy),
+				skb);
+		return 0;
+	}
+
 	if (is_offchan && local->ops->offchannel_tx) {
 		int ret;
 
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index 493b939..eb00d60 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -983,7 +983,8 @@ int cfg80211_mlme_mgmt_tx(struct cfg80211_registered_device *rdev,
 			return err;
 	}
 
-	if (memcmp(mgmt->sa, dev->dev_addr, ETH_ALEN) != 0)
+	if (memcmp(mgmt->sa, dev->dev_addr, ETH_ALEN) != 0 &&
+		memcmp(mgmt->da, dev->dev_addr, ETH_ALEN) != 0)
 		return -EINVAL;
 
 	/* Transmit the Action frame as requested by user space */
-- 
1.7.1

Re: [RFC] cfg80211: Let mgmt_tx accept frames destined for its own stack.

[Johannes Berg]

On Mon, 2011-04-04 at 19:06 -0700, Javier Cardona wrote:
> This is useful for implementing frame protection in userspace. The kernel may
> request a userspace daemon to verify a frame (sent to userspace via
> cfg80211_rx_mgmt()).  The userspace daemon can then pass back the
> verified/unprotected frame to the stack for further processing (via a
> self-addressed frame sent with cfg80211_mlme_mgmt_tx())
> 
> We are using this for our implementation authenticated peering.  11s defines
> two versions of mesh peering, the non-secure mesh peering management (MPM) and
> the Authenticated Mesh Peering Exchange (AMPE).  The latter is based on the
> exact same state machine as MPM.  It is really convenient to use the in-kernel
> MPM with a minimal userspace daemon to add the security bits introduced by
> AMPE.  This way both secured and open mesh networks can use exact same peering
> code.
> 
> What do you think... will this fly?

Seems very strange to me. I guess if you're after unification in my mind
it makes more sense to declare the in-kernel state machine legacy, copy
it into the userspace tool and use it even for unprotected MPM?

johannes

Re: [RFC] cfg80211: Let mgmt_tx accept frames destined for its own stack.

[Javier Cardona]

On Tue, Apr 5, 2011 at 12:07 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2011-04-04 at 19:06 -0700, Javier Cardona wrote:
>> This is useful for implementing frame protection in userspace. The kernel may
>> request a userspace daemon to verify a frame (sent to userspace via
>> cfg80211_rx_mgmt()).  The userspace daemon can then pass back the
>> verified/unprotected frame to the stack for further processing (via a
>> self-addressed frame sent with cfg80211_mlme_mgmt_tx())
>>
>> We are using this for our implementation authenticated peering.  11s defines
>> two versions of mesh peering, the non-secure mesh peering management (MPM) and
>> the Authenticated Mesh Peering Exchange (AMPE).  The latter is based on the
>> exact same state machine as MPM.  It is really convenient to use the in-kernel
>> MPM with a minimal userspace daemon to add the security bits introduced by
>> AMPE.  This way both secured and open mesh networks can use exact same peering
>> code.
>>
>> What do you think... will this fly?
>
> Seems very strange to me. I guess if you're after unification in my mind
> it makes more sense to declare the in-kernel state machine legacy, copy
> it into the userspace tool and use it even for unprotected MPM?


We would like to preserve the ability to join an open mesh without a
daemon, in the same way that a station can associate with an AP
without one.  With that goal in mind, the alternatives are to
duplicate the MPM in userspace or to reuse the in-kernel MPM with only
AMPE in userspace.  Considering that AMPE uses MPM frames and state
machines, reusing the in-kernel MPM is a significantly lower effort
alternative.  Furthermore, while working on AMPE we can also bring the
in-kernel MPM up to spec.
Of course this requires agreeing on a suitable API between MPM and
AMPE.  If you don't like the generic one I proposed we can try to
define a mesh-specific alternative.  But first, setting aside the API change
proposal, do you object to this AMPE-in-userspace/MPM-in-kernel partition?

Cheers,

Javier

Re: [RFC] cfg80211: Let mgmt_tx accept frames destined for its own stack.

[Johannes Berg]

On Tue, 2011-04-05 at 11:05 -0700, Javier Cardona wrote:

> We would like to preserve the ability to join an open mesh without a
> daemon, in the same way that a station can associate with an AP
> without one.

Keep in mind that even the station case on an open or WEP network is
pretty useless since it will not reconnect if the connection drops, or
do any sort of roaming.

> With that goal in mind, the alternatives are to
> duplicate the MPM in userspace or to reuse the in-kernel MPM with only
> AMPE in userspace.  Considering that AMPE uses MPM frames and state
> machines, reusing the in-kernel MPM is a significantly lower effort
> alternative.  Furthermore, while working on AMPE we can also bring the
> in-kernel MPM up to spec.
> Of course this requires agreeing on a suitable API between MPM and
> AMPE.  If you don't like the generic one I proposed we can try to
> define a mesh-specific alternative.  But first, setting aside the API change
> proposal, do you object to this AMPE-in-userspace/MPM-in-kernel partition?

After thinking about this more, yes, I think I do object. Not only is
the design strange with passing frames back and forth, but also it seems
like a rather slippery slope, at some point I fear somebody will attempt
to "fake" MPM to take advantage of that kernel code even when it's not
really fitting.

Since practically speaking, wpa_supplicant is already required for
almost everything, I don't see any real disadvantages to duplicating the
MPM state machine there, and starting to deprecate the one in the kernel
over time with new features only available in userspace one, maybe even
removing it at some point. I realise this is a little more short-term
effort, but I think the long-term benefit probably outweighs it.

johannes

Re: [RFC] cfg80211: Let mgmt_tx accept frames destined for its own stack.

[Javier Cardona]

On Tue, Apr 5, 2011 at 1:28 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2011-04-05 at 11:05 -0700, Javier Cardona wrote:
>
>> We would like to preserve the ability to join an open mesh without a
>> daemon, in the same way that a station can associate with an AP
>> without one.
>
> Keep in mind that even the station case on an open or WEP network is
> pretty useless since it will not reconnect if the connection drops, or
> do any sort of roaming.
>
>> With that goal in mind, the alternatives are to
>> duplicate the MPM in userspace or to reuse the in-kernel MPM with only
>> AMPE in userspace.  Considering that AMPE uses MPM frames and state
>> machines, reusing the in-kernel MPM is a significantly lower effort
>> alternative.  Furthermore, while working on AMPE we can also bring the
>> in-kernel MPM up to spec.
>> Of course this requires agreeing on a suitable API between MPM and
>> AMPE.  If you don't like the generic one I proposed we can try to
>> define a mesh-specific alternative.  But first, setting aside the API change
>> proposal, do you object to this AMPE-in-userspace/MPM-in-kernel partition?
>
> After thinking about this more, yes, I think I do object. Not only is
> the design strange with passing frames back and forth, but also it seems
> like a rather slippery slope, at some point I fear somebody will attempt
> to "fake" MPM to take advantage of that kernel code even when it's not
> really fitting.

The above seem to be concerns with the API itself and not with
partitioning.  We could make the API specific for mesh peering frames
in a way that cannot be used for any other purpose other than
protecting mesh peering frames.

> Since practically speaking, wpa_supplicant is already required for
> almost everything, I don't see any real disadvantages to duplicating the
> MPM state machine there, and starting to deprecate the one in the kernel
> over time with new features only available in userspace one, maybe even
> removing it at some point. I realise this is a little more short-term
> effort, but I think the long-term benefit probably outweighs it.

I know of a few mesh use cases where wpa_supplicant is not required,
such as resource constrained embedded platforms like the ones used in
sensor networks.  But hey, we'll re-evaluate the wpa_supplicant route
and see if it is doable.

Thanks for the comments,

Javier

Re: [RFC] cfg80211: Let mgmt_tx accept frames destined for its own stack.

[Johannes Berg]

On Tue, 2011-04-05 at 15:04 -0700, Javier Cardona wrote:

> > After thinking about this more, yes, I think I do object. Not only is
> > the design strange with passing frames back and forth, but also it seems
> > like a rather slippery slope, at some point I fear somebody will attempt
> > to "fake" MPM to take advantage of that kernel code even when it's not
> > really fitting.
> 
> The above seem to be concerns with the API itself and not with
> partitioning.  We could make the API specific for mesh peering frames
> in a way that cannot be used for any other purpose other than
> protecting mesh peering frames.

Well, it's a bit of both. I can just see somebody trying to implement a
new protocol and making it look like MPM in order to be able to feed it
back into the kernel, or something like that. More generally, I don't
much like the looping back of things.

> I know of a few mesh use cases where wpa_supplicant is not required,
> such as resource constrained embedded platforms like the ones used in
> sensor networks.  But hey, we'll re-evaluate the wpa_supplicant route
> and see if it is doable.

I think in that case it'd make some sense to make the code in the kernel
configurable? Can't be all that much overhead to have essentially the
same code outside the kernel?

johannes

Re: [RFC] cfg80211: Let mgmt_tx accept frames destined for its own stack.

[Javier Cardona]

On Wed, Apr 6, 2011 at 7:38 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2011-04-05 at 15:04 -0700, Javier Cardona wrote:
>
>> > After thinking about this more, yes, I think I do object. Not only is
>> > the design strange with passing frames back and forth, but also it seems
>> > like a rather slippery slope, at some point I fear somebody will attempt
>> > to "fake" MPM to take advantage of that kernel code even when it's not
>> > really fitting.
>>
>> The above seem to be concerns with the API itself and not with
>> partitioning.  We could make the API specific for mesh peering frames
>> in a way that cannot be used for any other purpose other than
>> protecting mesh peering frames.
>
> Well, it's a bit of both. I can just see somebody trying to implement a
> new protocol and making it look like MPM in order to be able to feed it
> back into the kernel, or something like that. More generally, I don't
> much like the looping back of things.
>
>> I know of a few mesh use cases where wpa_supplicant is not required,
>> such as resource constrained embedded platforms like the ones used in
>> sensor networks.  But hey, we'll re-evaluate the wpa_supplicant route
>> and see if it is doable.
>
> I think in that case it'd make some sense to make the code in the kernel
> configurable? Can't be all that much overhead to have essentially the
> same code outside the kernel?

We are analyzing how hard it would be to do MPM in userspace while
keeping (default) path selection in the kernel.  In this approach
userspace would not only authenticate but also establish peer links
and (in-kernel) stations would represent only established peer links.
It's probably not that hard after all, but definitely some overhead
compared to leaving it as it is :)

Javier