All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jouni Malinen <j@w1.fi>
To: Nicolas Cavallari <Nicolas.Cavallari@lri.fr>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	"John W. Linville" <linville@tuxdriver.com>,
	linux-wireless@vger.kernel.org
Subject: Re: [PATCH v2] mac80211: tx: do not drop non-robust mgmt to non-MFP stas.
Date: Wed, 4 Jul 2012 20:44:21 +0300	[thread overview]
Message-ID: <20120704174421.GA6070@w1.fi> (raw)
In-Reply-To: <4FF43E53.6050805@lri.fr>

On Wed, Jul 04, 2012 at 03:00:03PM +0200, Nicolas Cavallari wrote:
> From what i understand, data frames to unauthorized stations are dropped
> well before selecting the encryption key. as stations are authorized
> after or at the same time their encryption key are set, it somewhat
> works. But for MFP, i'm not sure. I think that drop_unencrypted is
> mistaken for "drop_unencrypted_management" there.
> But i'm not an MFP expert.

drop_unencrypted was originally (i.e., way before MFP) added as an extra
protection for some corner cases where keys may not have been set. In
theory, the PAE (authorized vs. unauthorized) should have covered those
cases, but there were some multi-SSID AP cases that were not obviously
clear. Consequently, it felt safer to add an extra protection for BSSes
that are known to use encryption for data frames.

As far as MFP is concerned, we have the WLAN_STA_MFP flag that should be
more reliable way of determining whether robust management frames have
to be protected.

> I'm not sure if we should just add a separate
> drop_unencrypted_management, or just replace drop_unencrypted with
> drop_unencrypted_management.

I hope that neither of those would be needed.

> But in a IBSS with RSN, if wpa_supplicant
> isn't recent enough, stations are always authorized by default. so
> drop_encrypted is required in this case.

For a BSS that uses RSN, we could maintain a new flag that indicates
that (non-nullfunc) Data frames are not to be transmitted or received
without protected. Though, this would be quite similar to
drop_unencrypted in practice.


As far as the new patch is concerned, it would look like this is
extending the fix in commit e0463f501fb945c1fde536d98eefc5ba156ff497.
The commit log for that change seems to claim that the goal was to avoid
dropping any management frames to a STA that does not use MFP, but the
change does not seem to do that.

As far as drop_unencrypted not being used in AP/managed mode is
concerned, that sounds like an additional bug.. This code is supposed to
drop Action frames from STA/AP before 4-way handshake. If we want to get
rid of drop_unencrypted, this function may need another condition to
drop the frame based on WLAN_STA_MFP flag. I have clearly assumed that
drop_unencrypted was set here (and maybe that was indeed the case in
early 2009 or maybe I did testing with WEXT at the time based on commit
0c7c10c7cc6bc890d23c8c62b81b4feccd92124b).

-- 
Jouni Malinen                                            PGP id EFC895FA

  parent reply	other threads:[~2012-07-04 17:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-04  9:13 [PATCH v2] mac80211: tx: do not drop non-robust mgmt to non-MFP stas Nicolas Cavallari
2012-07-04  9:35 ` Johannes Berg
2012-07-04 10:03   ` Nicolas Cavallari
2012-07-04 10:12     ` Johannes Berg
2012-07-04 13:00       ` Nicolas Cavallari
2012-07-04 13:29         ` Johannes Berg
2012-07-04 16:10           ` [PATCH 1/2] mac80211: restructure key selection Nicolas Cavallari
2012-07-04 16:10             ` [PATCHv3 2/2] mac80211: tx: do not drop non-robust mgmt to non-MFP stas Nicolas Cavallari
2012-07-10 16:07             ` [PATCH 1/2] mac80211: restructure key selection Johannes Berg
2012-07-04 13:45         ` [PATCH v2] mac80211: tx: do not drop non-robust mgmt to non-MFP stas Nicolas Cavallari
2012-07-04 17:44         ` Jouni Malinen [this message]
2012-07-05  7:55           ` Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120704174421.GA6070@w1.fi \
    --to=j@w1.fi \
    --cc=Nicolas.Cavallari@lri.fr \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.