Title: Fairness Attacks in the eXplicit Control Protocol
1Fairness Attacks in the eXplicit Control Protocol
- Christo Wilson
- Christopher Coakley
- Ben Y. Zhao
- University of California Santa Barbara
2Motivation
- Heavy research in recent years into explicit
feedback protocols - Demonstrate desirable qualities
- Fairness between flows
- High utilization
- Few drops
- No slow start
- Not security aware
- Honesty is for the most part less profitable
than dishonesty -- Plato, The Republic - Our work quantifying the impact of attackers
through detailed experiments
3Table of Contents
- Background and Attack Model
- Experimental Setup
- Sender-side Attacker
- Congestion controlled
- Fully Unresponsive
- Receiver-side Attacker
- Proposed Defenses
- Conclusion
4Background Explicit Feedback
Bottleneck
Explicit Feedback Enabled Internet
5Attack Model
- Feedback mechanism abuse enables attacks
- Selective compliance with feedback
- Falsified feedback
- Two attack types
- Sender-side ignores feedback
- Receiver-side falsifies header information
- Attacker goals
- Control as much bandwidth as possible
- Denial of Service (DoS) remote hosts
6Experimental Setup
- Attacker models implemented using XCP
- Tests performed in ns2
- 10ms latency
- 1KB packets
- Drop-tail queues
- 20 Mbit bottleneck link
-
7Sender-side Attacker
Explicit Feedback Enabled Internet
8Sender-side Attacker
- Two types of attackers implemented
- Congestion controlled
- TCP like behavior
- Continuous additive c_wnd growth
- Multiplicative c_wnd back off after packet drop
- Fully unresponsive
- Only probes for bandwidth once (1 packet drop)
- Locks c_wnd at 50 of current size
- Trumps congestion controlled attackers
- Resumes probing in response to
- positive feedback
- 25 reduction in RTT
9Sender-side Attacker (Congestion Controlled)
- 9 Sender-Side Attackers w/ 1 Normal Flow
10Sender-side Attacker
- Two types of attackers implemented
- Congestion controlled
- TCP like behavior
- Continuous additive c_wnd growth
- Multiplicative c_wnd back off after packet drop
- Fully unresponsive
- Only probes for bandwidth once (1 packet drop)
- Locks c_wnd at 50 of current size
- Trumps congestion controlled attackers
- Resumes probing in response to
- positive feedback
- 25 reduction in RTT
11Sender-side Attacker (Fully Unresponsive)
- 1 Sender-Side Attacker w/ 49 Normal Flows
12Sender-side Attacker (Fully Unresponsive)
- 4 Sender-Side Attackers w/ 1 Normal Flow
13Receiver-side Attacker
Explicit Feedback Enabled Internet
14Receiver-side Attacker
- 1 Receiver-Side Attacker w/ 49 Normal Flows
15Proposed Defenses Edge Monitors
- Edge monitors
- Must be ubiquitous
- Requires per flow monitoring/state
- Sender-side attacks detected by monitoring actual
versus expected throughput - Receiver-side attacks are trivially detected
- Issues
- Ubiquity of monitors can not be guaranteed
- Unfeasible router overhead
- Network edge does not exist
16Proposed Defenses Attack Severity
- Sender-side attacks are tractable problem
- Elephant flow monitors exist
- Detectable anywhere in network path
- Motivation for attack is lacking
- Can not be used to DoS
- Receiver-side attacks represent difficult
challenge - Can target/break well behaved hosts
- DoS potential
- Motivation for attack is much stronger
17Proposed Defenses Nonce Feedback Injection
Explicit Feedback Enabled Internet
18Proposed Defenses Nonce Feedback Injection
Explicit Feedback Enabled Internet
19Conclusion
- Existing explicit feedback protocols are
vulnerable to exploitation - Sender-side attacks
- Receiver-side attacks
- Attacks are highly effective
- Applies to existing explicit feedback protocols
- XCP, RCP, MaxNet, JetMax, etc
- Proposed solutions are inadequate
- Potential solution nonce feedback injection
20Questions?