domino: a system to detect greedy behavior in ieee 802.11...

DOMINO: A System to Detect Greedy Behavior in IEEE 802.11

Hotspots

By Maxim Raya, Jean-Pierre Hubaux, Imad AadLaboratory for computer Communications and Applications(LCA)

School of Computer and Communication SciencesEPFL, Switzerland

Your host today: Aaron LeMasters

3/12/2008 CS388 Wireless and Mobile Security 1

3/12/2008 CS388 Wireless and Mobile SecurityCS388 Wireless and Mobile

Security

2

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

Overview


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

3/12/2008 CS388 Wireless and Mobile Security

4

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


5

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 orNICs)

• Only user stations misbehave• Objective of misbehavior is to gain throughput –

doesn’t consider any other misbehavior (DoS, spoof, etc)


6

Misbehavior


Motivation for misbehavior

• Authors point out that MAC protocol is the best place to misbehave because:

1. You can get greater bandwidth gains because it is more efficient than doing it at higher layers

2. It is undetectable at higher layers3. 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


8

Misbehavior Taxonomy• Two main classes:

1. MAC Greedy behavior• Scramble frames of target systems to increase their

contention window (CW) by modifying CTS, ACK, or DATA frames

• Manipulate standard protocol parameters2. 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)


9

Misbehavior: Scrambling FramesHow the RTS/CTS handshake works in 802.11:

(RTS = Request to send / CTS = clear to send)

1. Station wanting to send data sends the receiver an RTS frame

2. The receiver responds with a CTS frame

3. Any other node receiving the CTS frame should refrain from transmitting for time specified in the frame

4. Any node receiving the RTS frame but not CTS is permitted to transmit to neighboring nodes


10

Misbehavior: Scrambling Frames (cont’d)


11

3/12/2008 CS388 Wireless and Mobile SecurityCS388 Wireless and

Mobile Security

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


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

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


14

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


15

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


16

DOMINO System Details


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

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


19

Limitations of DOMINO

• No automatic remediation• Requires steady traffic on the channel


20

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


21

The 6 Test Components of DOMINO


22

Other Components of DOMINO

Main loop in program:


23

Other Components of DOMINO (cont’d)

• Check() function to execute tests:


24

Other Components of DOMINO (cont’d)

• Punishing Function based on policy defined by Wireless ISP

• Decides what to do with misbehaving user


25

How DOMINO Detects Misbehavior

TEST #1: Scrambled Frames


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


27

Scrambled Frames – Detection

• DOMINO detects scrambled frames by observing a user’s retransmission rate (Rtxrate)

• 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’


28

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


29


TEST #2: Shorter than DIFS


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)


31


TEST #3: Oversized NAV


3/12/2008 CS388 Wireless and Mobile SecurityCS388 Wireless and Mobile

Security

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

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


34


TEST #4: Maximum Backoff


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


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!


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


38


TEST #5: Actual Backoff


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


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%)


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


42


TEST #6: Consecutive Backoff


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

3/12/2008 44CS388 Wireless and Mobile Security

Consecutive Backoff – Detection

• Same equation as Test #5, except backoffs are now measured during packets with interframe delays


45


Mobile Security

46

Simulation Results


Mobile Security

47

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


Mobile Security

48

Simulation Design (cont’d)• The authors measured throughput of cheaters to show they do benefit:


Mobile Security

49

Simulation Results – Actual Backoff (UDP)

• UDP – successful b/c idle time is only due to backoff, no interframe delay


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


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


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)


Mobile Security

53

Simulation Results – Consecutive Backoff (TCP) [2]


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”


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


Mobile Security

56

Simulation Results – Complete Solution (cont’d)


Mobile Security

57

Conclusions


Mobile Security

58

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


Mobile Security

59

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

domino: a system to detect greedy behavior in ieee 802.11...

Documents