Re: Management frame protection and packet injection from hostapd

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 3235 bytes --]


> Yes, as long as the STA entry is found (and it should, in this case),
> the pairwise CCMP key is used both for data and management frames. I
> haven't done full testing yet, but I would expect this to work even when
> the unicast management frames comes from hostapd.

Yeah, it should.

> Broadcast/multicast management frames are protected with BIP using IGTK.
> This is similar to how GTK is used with TKIP/CCMK for broadcast data
> frames, i.e., there is a default TX key index that the AP uses for the
> frames. Indexes 1..3 are used for data frames and 802.11w is using 4..5
> for BIP (even though the key index space is actually completely separate
> from the one used with data frames).

Ok, thanks for the explanation.

> > Yeah that sounds like a hack. I guess it should work just like when we
> > submit a unicast frame via monitor with the radiotap flag to indicate
> > that we want encryption, only we should add logic to look up the default
> > key to use if there is no peer/unicast key by the outgoing MAC address?
> 
> Yes, we already look for STA entry for unicast and that should work as
> long as the STA table is not per netdev, i.e., both data and monitor
> interface end using the same STA table. If no STA entry is found
> (multicast/broadcast), we look for a default TX key, but this is only
> done for the netdev that was used to send the frame (which is different
> between normal data interface and packet injection via monitor
> interface).

Good point about the STA tables there. I guess we really do need to bind
the frame to a certain outgoing device to use that sdata state struct.

> If the monitor interface were to look for the default key (or well,
> keys, since there are now two; one for data, one for mgmt) from the data
> interface (somehow bound to the monitor iface?), that should work here.
> 
> > OTOH, that would break for multi-SSID/single-BSSID scenarios I guess, so
> > we probably need a way to indicate "this frame belongs to interface
> > index N"?
> 
> Yes, either the frame or maybe more easily the monitor interface would
> need to be bound to the interface that is used for key configuration.

Yeah, either would work, for per-frame we'd have to extend radiotap but
it would probably be better as it would allow hostapd to use the same
mon.wlan0 interface for all BSSes.

> > I don't see any such problems, but if I were to venture a guess it's
> > because of configuring keys on a monitor interface. It sounds like
> > something sticks around within the netdev:mon.wlan0 subdirectory, then
> > the code tries to delete the directory and only afterwards is the entry
> > removed, leaving the directory (and the parent, of course) hanging
> > there.
> 
> Yes, that sounds likely since the changes I did for debugfs were very
> trivial copies from CCMP/data-default-key processing. I'll debug this
> more and try to figure if there is need to re-order something or make
> the debugfs entry removal able to handle such a case.

Ok. I don't know right now, and it does seem to work correctly here, but
maybe it doesn't when the application doesn't explicitly remove the key
or something, I'll take a look.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]