Presentation on theme: "Doc.: IEEE 802.11-08/1021r3 Submission September 2008 Luke Qian etc.Slide 1 A Simplified Solution For Critical A-MPDU DoS Issues Date: 2008-09-09 Authors:"— Presentation transcript:
doc.: IEEE /1021r3 Submission September 2008 Luke Qian etc.Slide 1 A Simplified Solution For Critical A-MPDU DoS Issues Date: Authors:
doc.: IEEE /1021r3 Submission September 2008 Luke Qian etc.Slide 2 Abstract Current operation rules for A-MPDU and BAR facilitate a number of Denial of Service (DoS) attacks as presented in /0703r0. This submission proposes a simplified solution to mitigate the most damaging and easiest-to-launch ones.
doc.: IEEE /1021r3 Submission September 2008 Luke Qian etc.Slide 3 Overview for the Issues Per current 11n A-MPDU/BA rules, advanced SN in data frames or BAR can advance the left edge of the BA re-ordering buffer on the receiver. However, –BAR is a control frame which is not encrypted, nor has any authentication information –SN in a data frame is not protected with encryption. As a result, a receiver running BA can be exposed to DoS attacks by rogue devices which move the receiver BA reordering buffer with falsely advanced SN, potentially causing subsequent valid frames to be discarded Such identified DoS attacks include: (Ref /0703) 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. They can cause severe performance degradation, such as drop of voice calls, lost connection for TCP traffic etc.
doc.: IEEE /1021r3 Submission September 2008 Luke Qian etc.Slide 4 Uniqueness of the DoS Issues Hit-and-run type of attack as only one packet is needed to cause the DoS. So an attacker does not need to be at the spot to launch attacks persistently, making it hard to identify or catch the attackers. Significantly long period of DoS for a single attack At the order of tens of seconds. Can cause disassociations or dropped sessions, especially problematic for tcp sessions and voice connections A regular DoS, CTS with excessive NAV setting for example, can only cause a DoS for a period of tens of ms, several order of magnitudes less than that of an A-MPDU DoS, and will have to repeatedly launch the attacks.
doc.: IEEE /1021r3 Submission September 2008 Luke Qian etc.Slide 5 The Proposed Approach The proposed solution focuses on one of the two easiest- to-launch DoS for a better acceptance in TGn: False Block ACK Request (BAR) with advanced SN. Note 1- The another is Forged packets with advanced Sequence Numbers (SN), addressed by switching the blocks of BA reordering and decryption Note2 - Both are fire and forget attacks whereby an attacker need nothing but a single packet to launch a DoS.
doc.: IEEE /1021r3 Submission September 2008 Luke Qian etc.Slide 6 A Simpler Solution Introduce a capability bit to signal the protection for backward compatibility Transmitter rules: –Never sends BAR with a SN which would cause the receiver to advance the left edge over a hole –Sends an 11w type of encrypted management action frame, the protected ADDBA, to advance the left edge of the receiver window over a hole when needed. Overload the existing ADDBA request frame ADDBA request already contains all the required information Only need to allow an ADDBA request to be used during an established BA session to move the left edge of receiver window Receiver rules: –On receiving a BAR which advances the left edge of receiver window over a hole, drop the BAR and flag a DoS attack (immediate detection of attack upon receipt of just one frame from attacker), and tear down BA session to minimize disruption –On receiving a protected ADDBA for an established BA session, adjust the left edge as requested.
doc.: IEEE /1021r3 Submission September 2008 Luke Qian etc.Slide 7 A Capability Bit for Negotiation: RSN Element changes A bit for signaling the capability: PBAC – Protected BAR Capable –Indicates capability to perform modified BAR rules and decryption ordering If both STA advertise PBAC=1, then PBAC SHALL be used –If at least one STA of a pair advertises PBAC=0, then PBA SHALL NOT be used –STA that supports PBAC must also indicate TGw (e.g. dot11RSNAProtectedManagementFramesEnabled) Pre-Auth PTKSA Replay Counter GTKSA Replay Counter Reserved No Pairwise PeerKey Enabled PBAC SPP A-MSDU Capable & Required Resv B0B1B2B3B4B5B6B8B9B10B11B12B13B15 Modified RSN Capabilities subfield of the RSN Element