Fairness Attacks in the eXplicit Control Protocol

1
Fairness Attacks in the eXplicit Control Protocol

• Christo Wilson
• Christopher Coakley
• Ben Y. Zhao
• University of California Santa Barbara

2
Motivation

• 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

3
Table of Contents

• Background and Attack Model
• Experimental Setup
• Sender-side Attacker
• Congestion controlled
• Fully Unresponsive
• Receiver-side Attacker
• Proposed Defenses
• Conclusion

4
Background Explicit Feedback
Bottleneck
Explicit Feedback Enabled Internet
5
Attack 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

6
Experimental Setup

• Attacker models implemented using XCP
• Tests performed in ns2
• 10ms latency
• 1KB packets
• Drop-tail queues
• 20 Mbit bottleneck link

7
Sender-side Attacker
Explicit Feedback Enabled Internet
8
Sender-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

9
Sender-side Attacker (Congestion Controlled)

• 9 Sender-Side Attackers w/ 1 Normal Flow

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

11
Sender-side Attacker (Fully Unresponsive)

• 1 Sender-Side Attacker w/ 49 Normal Flows

12
Sender-side Attacker (Fully Unresponsive)

• 4 Sender-Side Attackers w/ 1 Normal Flow

13
Receiver-side Attacker
Explicit Feedback Enabled Internet
14
Receiver-side Attacker

• 1 Receiver-Side Attacker w/ 49 Normal Flows

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

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

17
Proposed Defenses Nonce Feedback Injection
Explicit Feedback Enabled Internet
18
Proposed Defenses Nonce Feedback Injection
Explicit Feedback Enabled Internet
19
Conclusion

• 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

20
Questions?