1. doc.: IEEE 802.11-08/0703r0 Submission March 2008 Luke Qian etc, Cisco Systems, IncSlide 1 Issues and Solutions to IEEE 802.11n A-MPDU Denial of Service Attacks Authors:

2. doc.: IEEE 802.11-08/0703r0 Submission March 2008 Luke Qian etc, Cisco Systems, IncSlide 2 Abstract A number of issues are identified and discussed which relate to various possible Denial of Service (DoS) Attacks rooting from the BA operations for IEEE 802.11n A-MPDU. These issues possess a unique characteristics of a relatively long period of DoS damage with a single attack which were commented in CID 6232, 6233, 6070, 6071 etc in LB124 as well as CID 5899 in LB 115. A set of solutions are proposed for discussion. Most part of the solutions have been merged into 11-08/0665.

3. doc.: IEEE 802.11-08/0703r0 Submission March 2008 Luke Qian etc, Cisco Systems, IncSlide 3 Objectives 802.11n devices with A-MPDU are exposed to a number of newly identified types of Deny of Service (DOS) attack associated with the use of Block ACK (BA) and the BA reordering buffer and window. These have the characteristic of a hit-and-run attack as only one packet is needed to DoS the victim for a significant period of time, cause a disassociation or dropped session. These DOS attacks include: 1)Forged packets with advanced Sequence Numbers (SN) 2)Captured and Replayed packets with modified SN. 3)Captured and Replayed packets with advanced SN without modification. 4)False Block ACK Request (BAR) with advanced SN. 5)False BA to prevent retransmission. We will describe each attack and the proposed solutions.

4. doc.: IEEE 802.11-08/0703r0 Submission March 2008 Luke Qian etc, Cisco Systems, IncSlide 4 Forged Packets with Advanced SNs – the Problem Description Clause 9.10.7.6 Rx reordering buffer control specifies how received packets are buffered to maintain the order under BA with a sliding window of the expected sequence numbers. The window could be moved forward by a hackers packet and legitimate packets received thereafter will be discarded unexpectedly. CID 5899 in LB 115

5. doc.: IEEE 802.11-08/0703r0 Submission March 2008 Luke Qian etc, Cisco Systems, IncSlide 5 More Descriptions of Forged Packets with Advanced SNs The sliding window of expected sequence numbers (SN) is determined by WinStart_B (the next expected sequence number that has not yet been received) WinEnd_B (the end of the window) Packets are classified into 3 categories based on their SNs and the current window: 1) WinStart_B <= SN <= WinEnd_B -- within the expected window 2) WinEnd_B < SN < (WinStart_B + 2^11) -- after the expected window 3) (WinStart_B+2^11) <= SN < WinStart_B -- before the expected window Under normal operating conditions all of the received packets should be type 1 -- within the expected window. Packets that are before the window (type 3) are discarded. If a hacker moves the expected window forward by sending a type (2) frame with a SN greater than WinEnd_B, legitimate packets received after the hacker's packet will be treated as type (3) and discarded. The hacker forges a data packet with an advanced SN so that the sliding window is moved unexpected. The hacker is intentionally sending *later* sequence numbers that are not duplicates, "the duplicate removal" layer won't help.

6. doc.: IEEE 802.11-08/0703r0 Submission March 2008 Luke Qian etc, Cisco Systems, IncSlide 6 Forged Packets with Advanced SNs – a Proposed Solution Reverse the order of "Block ACK Reordering" and "MPDU decryption and Integrity (Optional)" on the Rx side of Figure 6-1 Now that the decryption occurs before the reordering, type (a) packets will fail the decryption and discarded therefore wont be further passed up for BA reordering. Some implementations already have this reverse ordering in place without any identified adverse effects.

7. doc.: IEEE 802.11-08/0703r0 Submission March 2008 Luke Qian etc, Cisco Systems, IncSlide 7 Captured and Replayed Packets with Modified SNs – Problem Description The hacker captures a data packet and then retransmits it with a modified SN so that the sliding window is moved unexpected. Note that the SN is not protected.

8. doc.: IEEE 802.11-08/0703r0 Submission March 2008 Luke Qian etc, Cisco Systems, IncSlide 8 Captured and Replayed Packets with Modified SNs – the Proposed Solution Including SN in crypto associated data (don't mute). Modified packet will not decrypt correctly and will be discarded before BA reordering. Signaling the muting with some of the unused bits in the CCMP Header: – Allocate a bit to signal SN protection – Negotiate SN protection to allow for legacy interoperability Signaling the muting in the packet will make the decrypt easier. Rather than having to look the muting up from a table of [address, priority] the muting method is immediately available from the received IV.

9. doc.: IEEE 802.11-08/0703r0 Submission March 2008 Luke Qian etc, Cisco Systems, IncSlide 9 Captured and Replayed Packets with Advanced SNs without Modifications – Problem Description The hacker captures the initial 2^12 packets - essentially every single SN. The hacker replays an unmodified packet with advanced SN. The unmodified replay packet passes decrypt, and integrity check and moves the BA window forward. The packet will not be initially detected as a replay, as replay detection occurs *after* BA reordering. Eventually the replay would be detected; but, the DOS damage has already been done. The hacker doesnt have to capture all 2^12 packets, just some packets with advanced SNs and waits for the receivers SN roll-over to be smaller than the replayed packets.

10. doc.: IEEE 802.11-08/0703r0 Submission March 2008 Luke Qian etc, Cisco Systems, IncSlide 10 Captured and Replayed Packets with Advanced SNs without Modifications – Proposed Solution Build a replay detection mechanism into the BA reordering layer: In the BA reordering layer, a packet should be immediately rejected if the TSC/IV is less than the current replay counter. This will prevent replay of these very old SN.

11. doc.: IEEE 802.11-08/0703r0 Submission March 2008 Luke Qian etc, Cisco Systems, IncSlide 11 False BAR with Advanced SN – Problem Description A BAR is forged with an advanced SN in it so that the sliding window is moved unexpectedly on receiving such a BAR. Legitimate BAR to Shift Window Clause 9.10.7.7: 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.

12. doc.: IEEE 802.11-08/0703r0 Submission March 2008 Luke Qian etc, Cisco Systems, IncSlide 12 False BAR with Advanced SN – Proposed Solution (a) Replace the BAR with a dropped bit in the SN of a packet. –The full 12-bit sequence number isn't really required under block ack agreement since only a 64 packet window is used. An 8-bit sequence number is more than sufficient. Use one unused bit as dropped bit. –The dropped bit would indicate all preceding packets have been dropped. –This "dropped" packet would NOT be forwarded to LLC. –The payload would be truncated, and have the same IV as the original packet. When a packet is dropped, the transmitter does not send a BAR, instead it indicates it with the dropped bit in the following packets. A receiver does not advance window when BAR is received. BAR would continue to be used, but only to solicit a BA. A receiver only advances the window when a "dropped" data packet is received. Including SN in crypto associated data. Hacker cannot create a "dropped" packet as it is encrypted and protected.

13. doc.: IEEE 802.11-08/0703r0 Submission March 2008 Luke Qian etc, Cisco Systems, IncSlide 13 False BAR with Advanced SN – the Proposed Solution (b) When a packet is dropped, the transmitter does not send a BAR, instead it sends a BAR wrapped up in a encrypted management frame. an 802.11w solution to switch BAR control frame to an management action frame, negotiated as part of 11w capability A receiver does not advance window when BAR is received Hacker cannot forge a BAR wrapped in an encrypted management frame as it is encrypted and protected.

14. doc.: IEEE 802.11-08/0703r0 Submission March 2008 Luke Qian etc, Cisco Systems, IncSlide 14 False BA to Prevent Retransmission – the Problem Description A hacker can forge a BA for a failed packet and keep the transmitter from retransmitting. The window on the receiver side will leave a hole and delay the buffered packets passing up the stack.

15. doc.: IEEE 802.11-08/0703r0 Submission March 2008 Luke Qian etc, Cisco Systems, IncSlide 15 False BA to Prevent Retransmission – the Proposed Solution Use one unused bit in the SN of a data packet as the flush bit to reduce the impact of the hacker transmitted BA packet The transmitter sends "flush" data packet to indicate there are no un-acknowledged or outstanding packets before this one. The transmitter would set the "flush" bit when transmitting a packet where all preceding packets have been acknowledged. This could be done periodically to alleviate any sequence number hole created by the attack -The receiver skips any sequence number holes before the "flush" packet. This "flush" packet would be forwarded to LLC. Including SN in crypto associated data. Hacker cannot created a "flush" packet as it is encrypted and protected. Some packets would get dropped in this case; but, this is possible with normal transmission

16. doc.: IEEE 802.11-08/0703r0 Submission March 2008 Luke Qian etc, Cisco Systems, IncSlide 16 Summary To address the five types of A-MPDU related DOS attacks, a full set of solutions are proposed. The solutions consist of: –Reversing the BA reordering and decryption on the receiver. –Protecting SN in CCMP associated data –Including a replay detection mechanism into the BA reordering layer –Modify SN to indicate the dropped packets. or alternatively introducing a BAR wrapped in an encrypted management action frame. –Modify SN to indicate the flush packets. –No moving of the window on receiving the BAR. –Negotiating the use of the capabilities for backward compatibility.