DOMINO: A System to Detect Greedy Behavior in IEEE 802.11 Hotspots By Maxim Raya, Jean­Pierre Hubaux, Imad Aad Laboratory for computer Communications and Applications(LCA) School of Computer and Communication Sciences EPFL, Switzerland Your host today: Aaron LeMasters 12/31/2018 CS388 Wireless and Mobile Security

CS388 Wireless and Mobile SecurityCS388 Wireless and Mobile Security Quick Agenda Overview of this research paper Misbehavior What is it and how do we measure it? DOMINO Intro, components, design details Six detection tests ** STAY AWAKE ** Simulation Results Conclusions 12/31/2018 CS388 Wireless and Mobile SecurityCS388 Wireless and Mobile Security

CS388 Wireless and Mobile Security Overview 12/31/2018 CS388 Wireless and Mobile Security

CS388 Wireless and Mobile Security Goal & Previous Work This paper attempts to detect greedy misbehavior on Wireless hotspots by examining MAC-layer activity The approach in this paper builds on a previous work by Kyasanur and Vaidya (detecting misbehavior based on penalty assigned) Shortcomings in previous work’s solution: Requires modification to 802.11 MAC protocol Could lead to further misbehavior Adds significant overhead to AP Only considers lagging UDP traffic as indicator of misbehavior No actual implementation of proposed solution 12/31/2018 CS388 Wireless and Mobile Security

CS388 Wireless and Mobile Security Main points Hotspots are growing more popular, demand increasing Users will misbehave by modifying hardware characteristics of their Wireless Card to become greedy (this is yet another MAC-layer paper) DOMINO can stealthily detect this behavior and integrate with WIDS; AirDefense Guard + DOMINO = protocol misbehavior and intrusion detection all-in-one 12/31/2018 CS388 Wireless and Mobile Security

CS388 Wireless and Mobile Security Assumptions Operation mode of AP is infrastructure mode using DCF (normal default) Solution is implemented on a single, trusted AP operating by an ISP (no changes to user laptops or NICs) Only user stations misbehave Objective of misbehavior is to gain throughput – doesn’t consider any other misbehavior (DoS, spoof, etc) 12/31/2018 CS388 Wireless and Mobile Security

CS388 Wireless and Mobile Security Misbehavior 12/31/2018 CS388 Wireless and Mobile Security

Motivation for misbehavior Authors point out that MAC protocol is the best place to misbehave because: You can get greater bandwidth gains because it is more efficient than doing it at higher layers It is undetectable at higher layers It can be used in any hotspot, because all AP’s use 802.11 MAC protocol (whereas TCP greediness wouldn’t impact UDP greediness, for example) Rather than enumerate all possible MAC-layer misbehaviors, a taxonomy is created to classify general types of misbehaviors 12/31/2018 CS388 Wireless and Mobile Security

CS388 Wireless and Mobile Security Misbehavior Taxonomy Two main classes: MAC Greedy behavior Scramble frames of target systems to increase their contention window (CW) by modifying CTS, ACK, or DATA frames Manipulate standard protocol parameters Security Attacks Inherent weaknesses in MAC (ie, De-auth attack) Not addressed in this paper Goal of both classes is to increase the cheater’s own throughput (bandwidth share) 12/31/2018 CS388 Wireless and Mobile Security

Misbehavior: Scrambling Frames How the RTS/CTS handshake works in 802.11: (RTS = Request to send / CTS = clear to send) Station wanting to send data sends the receiver an RTS frame The receiver responds with a CTS frame Any other node receiving the CTS frame should refrain from transmitting for time specified in the frame Any node receiving the RTS frame but not CTS is permitted to transmit to neighboring nodes 12/31/2018 CS388 Wireless and Mobile Security

Misbehavior: Scrambling Frames (cont’d) 12/31/2018 CS388 Wireless and Mobile Security 11

Misbehavior: Scrambling Frames (cont’d) Force a sending target (DATA frame source) to double its contention window size by altering ACK frame sender selects larger back-off values Cheater gets more medium 12/31/2018 CS388 Wireless and Mobile SecurityCS388 Wireless and Mobile Security

Misbehavior: Manipulate Standard Protocol Parameters When channel is idle, transmit after SIFS but before DIFS Manipulate NAV value in RTS or DATA frames to force neighbors to not contend Reduce back-off time by choosing a small, static window, so that back-off is always chosen within this window SIFS is the small gap between DATA frame and its ACK frame; RTS and CTS are sent after SIFS expires DIFS is the period of time a station waits after it has found the channel idle; sends RTS after this amount of time (DCF protocol) 12/31/2018 CS388 Wireless and Mobile SecurityCS388 Wireless and Mobile Security

CS388 Wireless and Mobile Security Misbehavior Metrics How the AP determines a user is misbehavior Takes measurements by collecting statistical data Considers two attributes of transmitting stations: throughput and backoff Chooses backoff as metric for solution 12/31/2018 CS388 Wireless and Mobile Security

Misbehavior Metrics: Throughput Most obvious choice – users hogging bandwidth are the cheaters, right? Problematic – throughput naturally varies based on application being used by the user To check application would require significant overhead High false-positives possible, b/c UDP throughput problems are related to many legit factors (SNR, device drivers, O/S protocol implementation, etc) Similarly, TCP protocol design (retransmit, reliability, error control, etc) tends to naturally degrade throughput on wireless networks 12/31/2018 CS388 Wireless and Mobile Security

Misbehavior Metrics: Backoff Less dependent on factors that affect throughput Still has its own problems, but authors choose it over throughput: Backoff idle period is indistinguishable from the delay due to a low packet rate source Backoff value cannot be computed at receiving end (no info in MAC header), thus it is hard to interpret collisions since those stations will increase backoff and others wont Hidden terminal problem can cause increases in backoff times 12/31/2018 CS388 Wireless and Mobile Security

CS388 Wireless and Mobile Security DOMINO System Details 12/31/2018 CS388 Wireless and Mobile Security

What is DOMINO? “System for Detection Of greedy behavior in the MAC layer of IEEE 802.11 public NetwOrks” A piece of software to be installed on the monitoring Access Point It collects traffic traces during a monitoring period to be inspected for misbehavior

CS388 Wireless and Mobile Security Key Features of DOMINO Seamless integration with the AP w/o interfering normal operations (passive monitoring) Compatibility with existing networks Still applicable to future revisions of 802.11 protocol This is supported by results from real experiments 12/31/2018 CS388 Wireless and Mobile Security

CS388 Wireless and Mobile Security Limitations of DOMINO No automatic remediation Requires steady traffic on the channel 12/31/2018 CS388 Wireless and Mobile Security

CS388 Wireless and Mobile Security Design Details Fully implemented in software/firmware Minor changes to 802.11 driver, possibly integrate with MADWIFI Can run as a module on AP Integrate with a monitor near the AP, such as AirDefense Guard 12/31/2018 CS388 Wireless and Mobile Security

The 6 Test Components of DOMINO 12/31/2018 CS388 Wireless and Mobile Security

Other Components of DOMINO Main loop in program: 12/31/2018 CS388 Wireless and Mobile Security

Other Components of DOMINO (cont’d) Check() function to execute tests: 12/31/2018 CS388 Wireless and Mobile Security

Other Components of DOMINO (cont’d) Punishing Function based on policy defined by Wireless ISP Decides what to do with misbehaving user 12/31/2018 CS388 Wireless and Mobile Security

How DOMINO Detects Misbehavior TEST #1: Scrambled Frames 12/31/2018 CS388 Wireless and Mobile Security

Scrambled Frames – Background Scrambling the RTS/CTS/DATA frames just creates noise and confusion The goal is to halt other’s use of the medium or stall them for long periods of time to hog the channel 12/31/2018 CS388 Wireless and Mobile Security

Scrambled Frames – Detection DOMINO detects scrambled frames by observing a user’s retransmission rate (Rtx rate) Bad user must scramble a large portion of others’ CTS, RTS, and DATA frames to cause desired effect – thus its Rtx rate will be lower than its victims’ 12/31/2018 CS388 Wireless and Mobile Security 28

CS388 Wireless and Mobile Security Scrambled Frames – How? But how does it detect a retransmission?? When user scrambles CTS, DATA or ACK frames, the RTS or DATA header will contain repeated sequence numbers notice threshold φ to control false positives 12/31/2018 CS388 Wireless and Mobile Security

How DOMINO Detects Misbehavior TEST #2: Shorter than DIFS 12/31/2018 CS388 Wireless and Mobile Security 30

Shorter than DIFS – Detection AP simple monitors idle period since last ACK Any station that transmits before required DIFS is potentially misbehaving Threshold here is protocol-defined (DIFS) 12/31/2018 CS388 Wireless and Mobile Security 31

How DOMINO Detects Misbehavior TEST #3: Oversized NAV 12/31/2018 CS388 Wireless and Mobile Security 32

Oversized NAV - Background Network allocation vector (NAV) value of a frame is a function of frame length and data rate Basically a counter at each station that represents the amount of time that the previous frame needed to send its frame; MUST BE ZERO before a station can transmit Stored in duration field of frame header Receiving station reads this value and sets their NAV accordingly, allocating enough medium for them 12/31/2018 CS388 Wireless and Mobile SecurityCS388 Wireless and Mobile Security

Oversized NAV – Detection AP compares actual duration of transmission against the NAV value present in DATA or RTS frames Stations that regularly set high NAV values are potential offenders, for obvious reasons Threshold A defines a tolerance value 12/31/2018 CS388 Wireless and Mobile Security 34

How DOMINO Detects Misbehavior TEST #4: Maximum Backoff 12/31/2018 CS388 Wireless and Mobile Security 35

Maximum Backoff – Background IEEE 802.11 protocol selects backoff values randomly from [0, CW –1], where CW depends on retransmission rate Thus, maximum selected backoff over a set of frames sent by a given station should be close to CWmin –1, if the sample size is adequate 12/31/2018 CS388 Wireless and Mobile Security 36

Maximum Backoff – Detection Test #4 checks a user’s maximum backoff over a set of samples against a threshold value; if it is less, possible offender! Sample size must increase as threshold increases! 12/31/2018 CS388 Wireless and Mobile Security 37

Maximum Backoff – Caveat This test can be easily fooled The cheater (and sometimes normal use) can make the monitor observe in every sample at least one backoff value larger than or equal to the threshold Use this as an auxiliary test 12/31/2018 CS388 Wireless and Mobile Security 38

How DOMINO Detects Misbehavior TEST #5: Actual Backoff 12/31/2018 CS388 Wireless and Mobile Security 39

Actual Backoff – Background How to measure “actual backoff”? If no collisions, the AP calculates a “total delay”, I.e. all idle intervals, between two transmission from a station If a collision occurs, the current and next backoffs are ignored Whatever is calculated is stored for a particular station 12/31/2018 CS388 Wireless and Mobile Security 40

Actual Backoff – Detection Bac[Si] Bac stores all backoffs calculated Si is a particular station being observed Bacnom is the nominal backoff value which is the average backoff value The ac value is between 0 and 1 and represents desired correct detection rate (I.e, 90%) 12/31/2018 CS388 Wireless and Mobile Security 41

Actual Backoff – Caveat Since no data is collected during a collision, the test cannot detect misbehavior during interframe delays The AP will see the delays when it adds up the idle times for a source, but since it does not record the backoff, it cannot measure them properly Solved by Test #6 – consecutive backoff 12/31/2018 CS388 Wireless and Mobile Security 42

How DOMINO Detects Misbehavior TEST #6: Consecutive Backoff 12/31/2018 CS388 Wireless and Mobile Security 43

Consecutive Backoff – Background Takes into account sources with interframe delays Primarily TCP sources (congestion control) Whenever two frames are back-to-back, not interleaved with others’ frames, DOMINO will measure the backoff and consider it in the user’s average retransmission rate calculation Why is this an opportunity to cheat? Because the user is experiencing upper layer delay (in TCP) and by altering the MAC-layer backoff value, he can ignore upper layer contention and improve his throughput 12/31/2018 CS388 Wireless and Mobile Security 44

Consecutive Backoff – Detection Same equation as Test #5, except backoffs are now measured during packets with interframe delays 12/31/2018 CS388 Wireless and Mobile Security 45

CS388 Wireless and Mobile SecurityCS388 Wireless and Mobile Security Simulation Results 12/31/2018 CS388 Wireless and Mobile SecurityCS388 Wireless and Mobile Security

CS388 Wireless and Mobile SecurityCS388 Wireless and Mobile Security Simulation Design They only test actual backoff, consecutive backoff, and complete solution Focus on a single cheater 8 stations sending UDP and TCP data Distance to AP is 50m All stations are within range of each other Model common traffic types: UDP – 1 cheater, 7 regular, all CBR sources TCP – 1 cheater, 8 regular, all FTP sources 12/31/2018 CS388 Wireless and Mobile SecurityCS388 Wireless and Mobile Security

Simulation Design (cont’d) The authors measured throughput of cheaters to show they do benefit: Notice TCP is much less of a benefit due to congestion control mechanisms imposing delay on lower layers 12/31/2018 CS388 Wireless and Mobile SecurityCS388 Wireless and Mobile Security

Simulation Results – Actual Backoff (UDP) UDP – successful b/c idle time is only due to backoff, no interframe delay Notice TCP is much less of a benefit due to congestion control mechanisms imposing delay on lower layers 12/31/2018 CS388 Wireless and Mobile SecurityCS388 Wireless and Mobile Security

Simulation Results – Actual Backoff (TCP) Unsuccessful (no graphic shown in paper) b/c all of the collected data (which was small), was simply interframe delay as a result of higher-layer TCP congestion control mechanism Notice TCP is much less of a benefit due to congestion control mechanisms imposing delay on lower layers 12/31/2018 CS388 Wireless and Mobile SecurityCS388 Wireless and Mobile Security

Simulation Results – Consecutive Backoff (UDP) Unsuccessful (no graphic shown in paper) b/c measured average consecutive backoff rapidly decreases as number of stations increases, and thus you start comparing really tiny values Notice TCP is much less of a benefit due to congestion control mechanisms imposing delay on lower layers 12/31/2018 CS388 Wireless and Mobile SecurityCS388 Wireless and Mobile Security

Simulation Results – Consecutive Backoff (TCP) Successful results, because MAC-layer queuing allows other sources to interleave with the source that has interframe delay (as a result of TCP congestion), so it is rare that consecutive backoffs would exist (and thus are easily detected) Notice TCP is much less of a benefit due to congestion control mechanisms imposing delay on lower layers 12/31/2018 CS388 Wireless and Mobile SecurityCS388 Wireless and Mobile Security

Simulation Results – Consecutive Backoff (TCP) [2] Notice TCP is much less of a benefit due to congestion control mechanisms imposing delay on lower layers 12/31/2018 CS388 Wireless and Mobile SecurityCS388 Wireless and Mobile Security

Simulation Results – Complete Solution Since actual backoff test was good at handling UDP traffic, and consecutive backoff was good at handling TCP traffic, let’s combine those two approaches for “complete solution” 12/31/2018 CS388 Wireless and Mobile SecurityCS388 Wireless and Mobile Security

Simulation Results – Complete Solution (cont’d) The authors implemented a “real cheater” to show the complete solution is accurate Use Proxim’s Orinoco wireless cards (Atheros chipset) with MADWIFI drivers on Linux kernel 2.4.20+ Simply write a value to a register to modify the contention window min and max values – they won’t tell us which register  12/31/2018 CS388 Wireless and Mobile SecurityCS388 Wireless and Mobile Security

Simulation Results – Complete Solution (cont’d) 12/31/2018 CS388 Wireless and Mobile SecurityCS388 Wireless and Mobile Security

CS388 Wireless and Mobile SecurityCS388 Wireless and Mobile Security Conclusions 12/31/2018 CS388 Wireless and Mobile SecurityCS388 Wireless and Mobile Security

CS388 Wireless and Mobile SecurityCS388 Wireless and Mobile Security Successes New classification for misbehavior New detection techniques (6 tests) Implementation of detection solution Solution is easily integrated into AP Achieves high accuracy in real networks Cheater prototype created 12/31/2018 CS388 Wireless and Mobile SecurityCS388 Wireless and Mobile Security

CS388 Wireless and Mobile SecurityCS388 Wireless and Mobile Security Some problems… Hidden terminals Creates false positives Must adjust threshold Security of DOMINO Not really considered in this paper Adaptive cheating What about users that know how DOMINO works? Monitoring period requires some trial-and-error Effect of mobility on the detection system? Incoming traffic vs outgoing traffic 12/31/2018 CS388 Wireless and Mobile SecurityCS388 Wireless and Mobile Security