On Sat, Mar 15, 2008 at 9:11 PM, Johannes Berg
<johannes@xxxxxxxxxxxxxxxx> wrote:
>
> On Wed, 2008-03-12 at 17:05 -0700, Reinette Chatre wrote:
> > From: Emmanuel Grumbach <emmanuel.grumbach@xxxxxxxxx>
> >
> > This patch makes mac80211 able to send a phase1 key for TKIP decryption.
> > This is needed for drivers that don't do the rekeying by themselves
> > (i.e. iwlwifi). Upon IV16 wrap around, the packet is decrypted in SW, if
> > decryption is ok, mac80211 calls to set_key with a new phase 1 RX key.
>
>
> > --- a/include/net/mac80211.h
> > +++ b/include/net/mac80211.h
> > @@ -590,12 +590,20 @@ enum ieee80211_key_alg {
> > * @IEEE80211_KEY_FLAG_TKIP_REQ_TX_P2_KEY: This flag should be set by
> > * the driver for a TKIP key if it requires a phase2 TX key generation
> > * in SW. The key will be attached to each packet.
> > + * @IEEE80211_KEY_FLAG_TKIP_REQ_RX_P1_KEY: This flag should be set by the driver
> > + * for a TKIP key if it requires phase 1 key generation in software.
> > + * The phase 1 key will be sent in the same context as Rx.
> > + * @IEEE80211_KEY_FLAG_TKIP_PHASE1_VALID: Set by mac80211, valid only when
> > + * IEEE80211_KEY_FLAG_TKIP_REQ_RX_P1_KEY was set. When set, the phase 1
> > + * fields (tkip_p1k and tkip_iv32) in ieee80211_key_conf are valid.
>
> This really breaks the set_key() model of having always one set_key()
> call to add the key and another one to remove it again.
>
> I think it would be much more appropriate to handle this in the driver
> by exporting an appropriate phase1 mixing function that takes the
> key_conf, iv16, RX vs. TX flag, and for RX the queue number as
> arguments. The RX vs. TX flag could be used by the b43 driver since that
> hardware can actually derive the phase2 key by itself.
iwlwifi firmware also derive phase2 in RX path by itself since this is
not really possible to do in host level. However in case of non
matching iv32 such as wraparound it passes packet up unencrypted. And
there are some more esoteric cases when packet when SW decryption is
more efficient such as very short packets. Therefore HW decryption
have to be always backed up by SW one.
Wraparound of Iv32 is reliable only if decryption of a the packet that
triggers it is correct. If this is not done and phase1 is advanced by
mistake it breaks traffic till the next wraparound actually it will
effectively cause disconnection. Your suggestion will requires to
move also decryption into driver levelm not only phase1 generation. So
it's rather no go solution
> I think for advanced features like crypto hardware acceleration or
> similar we should deviate from the "push" model mac80211 has for most
> things (and which you also implemented here) so we don't end up creating
> special flags for all possible different hardware. A "pull" model is
> much more scalable here.
I agree in general but in this specific case this will cause much more
data movement than few flags.
Thanks
Tomas
> johannes
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Ipw3945-devel mailing list
> Ipw3945-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/ipw3945-devel
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
