1. 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

2. 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

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

4. 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 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

5. 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

6. 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

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

8. 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 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

9. 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

10. Misbehavior: Scrambling Frames
How the RTS/CTS handshake works in :
(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

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

12. 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

13. 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

14. 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

15. 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

16. 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

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

18. What is DOMINO?
“System for Detection Of greedy behavior in the MAC layer of IEEE 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

19. 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 protocol
This is supported by results from real experiments
12/31/2018
CS388 Wireless and Mobile Security

20. 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

21. CS388 Wireless and Mobile Security
Design Details
Fully implemented in software/firmware
Minor changes to 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

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

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

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

25. 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

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

27. 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

28. 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

29. 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

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

31. 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

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

33. 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

34. 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

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

36. Maximum Backoff – Background
IEEE 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

37. 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

38. 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

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

40. 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

41. 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

42. 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

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

44. 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

45. 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

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

47. 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

48. 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

49. 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

50. 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

51. 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

52. 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

53. 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

54. 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

55. 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
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

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

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

58. 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

59. 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