1 / 6

TGn LB124 – A “detect and mitigate” solution to the BA DoS problems

TGn LB124 – A “detect and mitigate” solution to the BA DoS problems. Authors:. Date: 2008-05-09. Summary. BA DoS attacks do exist Two complementary types of solution exist Harden

snow
Download Presentation

TGn LB124 – A “detect and mitigate” solution to the BA DoS problems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TGn LB124 – A “detect and mitigate” solution to the BA DoS problems Authors: Date: 2008-05-09 Adrian Stephens, Intel Corporation

  2. Summary • BA DoS attacks do exist • Two complementary types of solution exist • Harden • Prevents attack from being effective – i.e. no DoS from BA attacks (other less targeted DoS attacks still exist) • May require hardware changes • Requires support from both peers • Detect & Mitigate • Detects attack after it has occurred • Some MSDUs will be lost for each attack • Effective with “Draft 2.0” devices as recipient • Driver-level modifications may suffice – may be capable of being retrofitted? Adrian Stephens, Intel Corporation

  3. Detection • Draft 2.0 recipients • An attack leaves WinStart_R in an anomalous state • A BA will be generated with a SSN that is “later” than the originator’s window. This suffices to detect the event. • But this is ineffective when the recipient uses partial state, and the partial state is flushed following the attack, but before a BA has been sent. • Draft 5.0 recipients • In addition to the above, the recipient can detect an attack in a number of ways, within: scoreboard, re-ordering buffer MIC check and replay detection. • After detecting an attack, a draft 5.0 recipient sends a “BA-SYNC-REQUEST” frame to the originator. (Could be protected, non-real-time. Could re-use DELBA with reason “BA DoS attack”.) Adrian Stephens, Intel Corporation

  4. Mitigation • Draft 2.0 recipients • There are a number of ways to reset state, including: • sending 2**12/winsize dummy data frames to push the winstart_B to a known position. • (preferrred) Send a DELBA followed by ADDBA to recreate the BA agreement in a known state. • Either solution will cause the loss of up to a window’s worth of data. • Draft 5.0 recipients • Add a new protected management action frame BA-SYNC, which carries a new SSN. • Recipient advances the SSN to just past its current window. • Will loose up to a window’s worth of data Adrian Stephens, Intel Corporation

  5. Negotiation • The only negotiation necessary is for the originator to know whether it is dealing with a draft 2.0 recipient or not. • As the BA DoS vulnerability is not strictly a HT issue, we can add to the extended capabilities field a bit called “Supports BA re-sync”, which indicates support for the new BA management frames and associated behavior. Adrian Stephens, Intel Corporation

  6. Straw PollsVote yes or no for each in turn • A: Do you think BA DoS is an issue we should fix in TGn? • B: Do you support (in concept) a mitigation & detect (only) solution? • C: Do you support (in concept) both mitigation & detect and hardening solutions? • D: Do you support (in concept) only a hardening solution? Adrian Stephens, Intel Corporation

More Related