doc.: IEEE /2163r0 Submission July 2007 Cam-Winget, Smith, WalkerSlide 1 A-MPDU Security Issues Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEEs name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEEs sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at. Date: Authors:

doc.: IEEE /2163r0 Submission July 2007 Cam-Winget, Smith, WalkerSlide 2 General Problem n A-MPDU packets may transmit MSDU packets out of order. –The receiver is responsible for buffering the packets and reordering to maintain the original packet order as per n/D2.00 clause Block ACK reordering in n with implicit (HT- Immediate) Block ACK enables A-MPDU DoS attacks all legitimate traffic can be discarded.

doc.: IEEE /2163r0 Submission July 2007 Cam-Winget, Smith, WalkerSlide 3 General Issue Clause Rx reordering buffer control specifies how receive packets are buffered to maintain order under block ack: –Packets are classified into categories based on the sequence number of the incoming packet (SN) and the current window of expected sequence numbers. –WinStart_B is the next expected sequence number that has not yet been received and WinEnd_B is the end of the window –(WinEnd_B = WinStart_B + WinSize_B - 1). WinSize_B can be up to 64. A receiver only processes packets that are within the expected window: –WinStart_B <= SN <= WinEnd_B –All other packets are discarded The expected window can be moved forward by a single packet such that all legitimate packets will be treated as outside the window and discarded

doc.: IEEE /2163r0 Submission July 2007 Cam-Winget, Smith, WalkerSlide 4 1st method to block ALL traffic A data packet with SN that is after the expected window: WinEnd_B < SN is < (WinStart_B ). Clause moves the window forward: – WinEnd_B = SN – WinStart_B = SN - WinSize_B + 1 All legitimate traffic is now discarded as all of the packets will be treated as before the window and discarded as per The bad packet would be held waiting for the packets within the *new* window that precede the attack packet SN. –RSN protection doesnt help since MPDU decryption is done AFTER Block ACK Reordering

doc.: IEEE /2163r0 Submission July 2007 Cam-Winget, Smith, WalkerSlide 5 2 nd method to block all traffic A Block Ack Request (BAR) packet with an SSN (starting sequence number) of (WinStart_B ) is transmitted Clause categorizes BAR packets based on SSN into two categories: 1) WinStart_B < SSN < (WinStart_B ) -- within or after the expected window 2) (WinStart_B ) < SSN < WinStart_B -- before the expected window The attack packet moves the window forward as per as follows: – WinStart_B = SSN – WinEnd_B = SSN + WinSize_B - 1 All legitimate traffic is now discarded, until the new window is reached. A legitimate BAR packet will not correct the problem as it will be treated as a type (2) BAR packet and will *not* adjust the window.

doc.: IEEE /2163r0 Submission July 2007 Cam-Winget, Smith, WalkerSlide 6 Suggestions Proposal to address SN window modification: –Use sequential encryption PNs for the A-MPDU sub-frames. A-MPDU sequential sequence numbers would still be required for the low level retransmission and block acking mechanism. CCMP is constructed such that it is feasible to reuse PN across TIDs provided it is only used once per TID –Validation of MIC should be done before Block ACK reordering –Block ACK reordering validates PN versus SN –ADDBA exchange must be updated to include starting PN BAR vulnerability still remains to be addressed: –Do not accept BAR packets outside the window –Only accept BAR packets that legitimately shift the window past a hole in the SN space for a discarded packet –Should extend CCMP to protect Block ACKs?

doc.: IEEE /2163r0 Submission July 2007 Cam-Winget, Smith, WalkerSlide 7 Straw Poll Should TGn address these A-MPDU security issues before sponsor ballot?

doc.: IEEE /2163r0 Submission July 2007 Cam-Winget, Smith, WalkerSlide 8 Comments?

doc.: IEEE /2163r0 Submission July 2007 Cam-Winget, Smith, WalkerSlide 9 TGn MAC

doc.: IEEE /2163r0 Submission July 2007 Cam-Winget, Smith, WalkerSlide 10 Legitimate BAR to Shift Window Clause : After sending data within an A-MPDU with the Ack Policy field set to Normal Ack, the originator may send a BlockAckReq when it discards a data MPDU due to exhausted MSDULifetime. The purpose of the Block- AckReq, in this case, is to shift the recipient window past the hole in the SN space created by the discarded data.