| 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 ---
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 _______________________________________________________________________________ |