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