| 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, Adrian. Glad we agree on the end result. And, I’m happy to add a sentence, “Further, this chance is likely to make existing implementations non-compliant.” As for your comment on the waste of bandwidth: First, I just quoted text from the existing Standard. If you disagree with that text, that is a whole ‘nother can of worms. Second, I think the “waste of bandwidth” that is implied here is in the case where the sender/receiver have gotten keys out of synch or some such, such that the sender built what it thinks is a correct frame, but the receiver will repeatedly fail to decrypt/integrity check it. If this prevents the receiver from ACKing it, we’ll loop on retries for a while. The point was to have the receiver acknowledge that it got the frame, and only then drop it as failing integrity check, without the sender banging away on it. Mark From: Stephens, Adrian P [mailto:Adrian.P.Stephens@xxxxxxxxx] Hello Mark, “. Further, the text in 4.5.4.4 (Data confidentiality), last paragraph, makes it clear that frames which fail integrity check are still acknowledged, to prevent wasting WM bandwidth on retries of frames that are being discarded. Thus, the proposed change would trade one problem for a different problem” is a red herring. The only “waste of bandwidth” would be in the case that the attacker is transmitting a forged frame. As this would not happen very often, it is not something we would have to optimize. I agree with the resolution to the change as proposed, and might add “makes existing devices non-compliant”. The more intelligent solution, which I described in my submission, would leave the order to the implementer; but I agree that we are under no obligation to fix the commenter’s proposed change. 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 --- All, This is my proposed resolution text for CID 8137 (also copied here):
Proposed resolution: REJECTED. While checking MPDU integrity before doing scoreboarding would perhaps help with one particular type of DoS attack, it has sufficient problems to make this overly restrictive for implementations. For example, it is likely that Block Ack scoreboarding and normal ACK generation are done at the same point in the stack, especially for HT-immediate Block Ack. Since this implies that there is only a SIFS time duration to complete the frame reception, it puts significant burden on an implementation to check the MPDU Header and FCS, perform Address 1 checks and duplicate detection, and (with the proposed change) the MPDU Decryption and Integrity check, in time to send the ACK. Further, the text in 4.5.4.4 (Data confidentiality), last paragraph, makes it clear that frames which fail integrity check are still acknowledged, to prevent wasting WM bandwidth on retries of frames that are being discarded. Thus, the proposed change would trade one problem for a different problem. Comments welcome! 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 _______________________________________________________________________________ |