| Message ID | 1301969218-9878-1-git-send-email-javier@cozybit.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 */