On 2/13/07, Jouni Malinen <jkm@xxxxxxxxxxxxxxx> wrote:
On Tue, Feb 13, 2007 at 03:08:03AM +0200, Tomas Winkler wrote: > There are real cases when this happens. Try to two different AC for > example VoIP and have FTP in parallel. Packets for low priority AC > can be stalled encrypted and scheduled in a AP TX queue while high > priority packets are already sent with the new key. > Maybe the new key can be computed on demand but it's good thing to > preserve the old key for while. I don't know the particular hardware design well enough to comment on this, but d80211 software implementation keeps a separate RX P1K for each AC (actually, each TID). In other words, this kind of issue does not show up there. If the hardware implementation is limited to only one P1K for RX, there may be some benefit on storing old keys in some cases, but I'm not sure how that would work if the key has to be configured before the frame is actually received.
Since TX can use only on sequence counter regardless of AC also on receive side it's enough to use one phase1 key. To keep phase1 key for each AC is possible but it wast of memory. You need to keep just old key till all AC wraps.
In other words, in this case, the next frame after an FTP packet could well be from voice and not background and reconfiguring the old P1K value could have caused more latency on the higher priority frame at this point.. In other word, if there is only one RX P1K, the benefits for throughput may be requiring compromise on latency for higher priority traffic and that may or may not be acceptable.
You decrypt with old phase1 only in software, usually it is only few packets (since TX counter is global). It will be a bug to configure HW with the old key.
Jouni Malinen PGP id EFC895FA
- 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
