Re: [RFC PATCH 3/7] 802.11w: Add BIP (AES-128-CMAC)

[Jouni Malinen <j@w1.fi>]

On Tue, Jun 17, 2008 at 08:19:13PM +0200, Johannes Berg wrote:

> Well the thing is that you can't just call pskb_expand_head without
> orphaning the SKB first and all that truesize adjusting, because of
> truesize accounting, because it might now or later belong to a userspace
> socket.

OK. I don't want to do that here, so I'll see what can be done with
IEEE80211_ENCRYPT_TAILROOM.

> > Anyway, I would assume it would be possible to do this by changing
> > IEEE80211_ENCRYPT_TAILROOM from 12 to 22 which would waste 10 bytes
> > extra for every frame (well, not waste for BIP-protected frames but
> > there are next to none of them).
> 
> 22? Is there something else on the frame in addition to the MMIE?

Uhm.. Maybe I just cannot count anymore.. Or well, I did not remember
where the 12 comes from and decided to add 4 because of that. Anyway,
yes, now that I see that 12 is 8(MIC)+4(ICV) for TKIP, this 12 would
indeed change to 18.

> Yeah, true, and we actually have that in another place too. If we then
> remove the MMIE, the IE sanity checks should catch the bad frame anyway,
> when/if it is parsed. Except we removed those because APs were sending
> bogus information. I'm fine with this, but we should be aware of the
> consequence.

As long as we get the RX path implemented properly, this will only hit
if there is a bug in an MFP-enabled AP or someone is trying to attack
the network and both cases are very good candidates for dropping the
frame anyway. The key selection is supposed to pick BIP key only if the
sender (AP) has negotiated MFP and as such, all valid broadcast robust
management frames are guaranteed to have MMIE in the end.

-- 
Jouni Malinen                                            PGP id EFC895FA