| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
| --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hello Mark, David and all, Here’s an attack: 1.
An AP transmits a block of frames, one of which fails 2.
AP receives block ack, showing frame failed 3.
End of TXOP 4.
Attacker spoofs a frame with the missing SN
a.
This affects the scoreboarding state, but not the reassembly/reordering state. 5.
AP transmits a new block of frames, including the failed frame 6.
The failed frame fails a second time 7.
STA sends a BA indicating the frame succeeded 8.
AP discards and will never re-transmit that frame 9.
STA will never receive that frame It’s a pretty unlikely scenario because it requires that the same frame fail twice. In implementations, the scoreboarding is likely to be done in hardware, and before decryption. The latter may take some time because there is a non-trivial amount of number crunching. There’s also access to per-STA data such as keys, which might take
some time. Note, for the attack to work, the scoreboarding state has to persist across two TXOPs. The partial state rules allow a STA to discard this state, which means the attack is less likely
to work (i.e. the poison is discarded) on a STA that receives data from multiple STAs (such as the AP). I can think of a more active attack in which the attacker deliberately collides with the BA, which only requires a frame to fail once. Best Regards, Adrian P STEPHENS Tel: +44 (1793) 404825 (office) ---------------------------------------------- From: ***** IEEE stds-802-11-tgm List ***** [mailto:STDS-802-11-TGM@xxxxxxxx]
On Behalf Of Mark Hamilton --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Thanks, David! Replaying ( J ) to all the lists, to further discussion. Mark From: David Kloper (dakloper) [mailto:dakloper@xxxxxxxxx]
Mark, We have doors on our houses so we can keep unwanted intruders from entering our homes, and not to keep them from knocking on our doors. Encrypted VPN tunnels and firewalls cannot protect you from a DoS attack on your door, but can limit so that only valid traffic is admitted beyond that doorway. We can’t stop someone from causing frames to be lost, whether from attacks on the BA window, or RF jamming. There are many DoS attacks possible, and 802.11 is not immune. Speaking specifically to 802.11, since the HT-Immediate Block-ACK is sent as a control response at SIFS timing, such a requirement would mandate for implementations that: a) All 802.11n/ac/ad compliant devices must implement inline decryption, so that they do not acknowledge fraudulent frames; b) from a hard real-time implementation standpoint the inline decryption must fully complete within the SIFS, prior to deciding whether to send a Block-ACK response, or we would acknowledge the reception
of no-frames; And what about the PN replay protection? The PN must be strictly increasing within a UP/TID, and this is validated only after Block-ACK reordering, or would cause retried frames to never be acknowledged. We do specifically callout and separate BA score boarding and reordering logic. If we forego the PN validation for the purposes of Block-ACK score boarding, then replayed prior GCMP/CCMP frames from that same session could be sent with the same effect, making any requirement
to validate the MIC prior to score boarding ineffectual. Note: That the Sequence Control field is specifically masked out the Sequence Number subfield in the AAD, as the expectation was never to mandate inline encryption/decryption. Now in the case of unintended / non-malicious cases when the key was out of sync, such as PSK or some race condition or latency during key change, then is the expected behavior that the frames sent
with the wrong key (or prior to the key being installed) should be retried until a max retry limit is reached, or is it preferable that if they are going to be dropped, that it is done early with minimal wastage of air-time. Afraid I haven’t spent the time hunting down the exact references within the spec, but placing MIC validation below score boarding would certainly be a significant change vs a clarification. Thanks, David From: *** 802.11 Architecture Standing Committee *** [mailto:STDS-802-11-ARC@xxxxxxxx]
On Behalf Of Mark Hamilton --- This message came from the IEEE 802.11 ARC Reflector ---
Sorry for the spam. Correction to the spreadsheet where you can find this CID. It is in this one:
https://mentor.ieee.org/802.11/dcn/15/11-15-0532-49-000m-revmc-sponsor-ballot-comments.xls
Mark From: Mark Hamilton [mailto:mark.hamilton2152@xxxxxxxxx]
All, On the latest Sponsor Ballot recirc, REVmc got a comment about the addition (in D6.0) to show “Block Ack Scoreboarding” in the STA ‘stack’ (Figure 5-1). The CID is 8137. You can find details in the MAC spreadsheet,
here:
https://mentor.ieee.org/802.11/dcn/15/11-15-0565-48-000m-revmc-sb-mac-comments.xls.
The gist is questioning whether the Block Ack Scoreboard should be updated before checking the frame integrity (effectively, meaning before it has been decrypted). The concern is that without doing the integrity check,
a frame could be spoofed, and cause ‘junk’ to be in the Block Ack Scoreboard. The text of REVmc seems to lack any specificity on when the scoreboard should be updated, with respect to the question of before or after decryption/integrity check. This was discussed at length in TGak, since 11ak is being proposed to use a “GCR-like” block ack mechanism, but it was realized that the details of block ack scoreboarding were not clear in the baseline. TGak needs to
clarify the order of operation to make sure the various addressing, acknowledgement and security mechanisms will work properly for GLK links. My memory is fuzzy on the details, but as I recall the discussion in TGak, the thinking was that block ack scoreboarding (which is used to build any Block Ack response) is effectively the same sort of operation as Normal
Ack processing. That is, if a frame is received with a good CRC and the Address1 field matches, then it gets acknowledged - or scoreboarded to be acknowledged. In particular, the frame is not decrypted and integrity checked first. However, as pointed out
in the comment to REVmc, this means that ‘junk’ information can be injected into the scoreboard by spoofed frames. Thoughts or comments on this topic would be welcome. Note, of course, that clarification of block ack potentially affects normal Block Ack, GCR block ack, and DMG block ack, (and future GLK block ack), so it would be
good to get this correct. This will be discussed again on the REVmc teleconference on July 15, so comments at or before that call would be appreciated. Thanks. Mark _______________________________________________________________________________
IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand.
SELF SERVICE OPTION: Point your Browser to -
http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button.
Further information can be found at:
http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________ IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand. SELF SERVICE OPTION: Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button. Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________ |