Re: [PATCH v2] p54: connect to 11w protected networks

[Johannes Berg <johannes@sipsolutions.net>]

On Fri, 2012-09-07 at 19:01 +0200, Christian Lamparter wrote:

> > > Oh no, I mean dynamic reconfiguration of the firmware's
> > > keycache during runtime. 
> > 
> > Right right, but for MFP that doesn't help since in AP mode
> > we don't know whether to expect encrypted management frames
> > or not.
> 
> Hmpf, don't we set the CMAC key in this case? 

Hmm, I guess we would have that, and actually ... we know MFP will be
used for the *station* so we should in fact know this already. I'll need
to revise my patch. D'oh.

> (Note: I haven't
> seen much/any of the 11w spec, as 802.11-2012 is AFAICT still not
> available for _free_). 

Hm. Well it was published March 29th, so it should be available in 3
weeks if they hold their promise ...

> However, my thinking is/was that when
> mac80211 tries to upload the CMAC key, return -EOPNOTSUPP and 
> we kick the ccm per-station key, so the firmware won't try to
> decrypt incoming (mgmt and data) frames with this combination
> anymore.

CMAC keys aren't per-station, so we'd have to remove them all or
something? But I think we already know about MFP for the station when we
set the key, I'll check this.
 
> > > But for this, we would need
> > > a way to tell mac80211 when driver wants to delete a key
> > > from the hw/fw cache and when there is room for another
> > > one (Didn't you had a patch for the "we have a empty slot
> > > in the rxkey cache we are not using" case some time ago?
> > > However in this case, we want to tell mac80211 what "exact"
> > > key (by MAC of the peer and key index) we want.)
> > 
> > I had a patch for the opposite: please remove this key, I can't
> > handle it any more. Adding a new one in that case couldn't be
> > done.
> Ah well, that's too bad. Altough, I thought you removed
> it because its prone to cause rx/tx races?!

No, just because it was unused. Adding a new key could also be
implemented, or you could iterate the keys in some way maybe.

> > > Of course, I'm well aware of the "amount of work" and the
> > > problems associated with removing and readding keys during
> > > runtime without causing races (or just minor races).
> > 
> > Actually that's not too difficult, the bigger difficulty is
> > actually knowing which key to re-upload I think.
> Well, the firmware reports a "CACHE MISS" status in every
> encrypted rx frame if no key was found in the rxkey cache.
> 
> Of course, being a cache, we can make some sort of LRU 
> (not sure about the size, but rxkey cache * 2 would be
> a start) and keep track of the rx key usage. This way
> when a "rxkey" becomes more popular it will be detected
> and "replace" a rxkey that is no longer active... and
> so on.

Right. Seems pretty simple really, but I guess the devil is in the
details :-)

Anyway I'll revise that patch (after dinner) and see if MFP flag is set
correctly, if so then we can just use that.

johannes