A Performance vs' Trust Perspective in the Design of EndPoint Congestion Control Protocols

1
A Performance vs. Trust Perspective in the Design
of End-Point Congestion Control Protocols
Aleksandar Kuzmanovic Edward W. Knightly
2
Motivation

• Sender-based TCP
• Control functions given to the sender

3
Receiver-Based TCP

• Receiver decides how much data can be sent, and
  which data should be sent by the sender
• DATA ACK communication
• becomes REQ - DATA
• Example protocols
• TFRC RFC3448, WebTP, and RCP

4
Why Receiver-Based TCP?

• Example Busy web server
• Receiver-based TCP distributes the state
  management across a large number of clients
• Generally
• Whenever a feedback is needed from the receiver,
  receiver-based TCP has advantage over
  sender-based schemes due to the locality of
  information
• Benefits RCP03
• Performance Functionality
• - Loss recovery - Seamless handoffs
• - Congestion control - Server migration
• - Power management for - Bandwidth aggregation
• mobile devices - Web response times
• - Network-specific congestion control

5
Vulnerability

• Receivers remotely control servers by deciding
  which packets and when to be sent
• Receivers have both means and incentive to
  manipulate the congestion control algorithm
• Means open source OS
• Incentive faster web browsing file download

6
An ExampleRequest-Flood Attack

• Request flood attack
• A misbehaving receiver
• floods the server with
• requests, which replies and
• congests the network
• Resource stealing
• A misbehaving
• receiver moderately
• re-tunes TCP parameters
• to gain performance,
• yet eludes detection

7
Remaining Outline

• Modeling receiver misbehaviors
• Evaluate network-based solutions
• Present an end-point solution
• Conclusion

8
Algorithmic Misbehavior

• Goal
• Compute TCP throughput for arbitrary
  (misbehaving) parameters

• Why parameter-based misbehaviors?
• Easy to implement
• Tells how much you can misbehave while eluding
  detection

9
Bandwidth Stealing
10
Network-Based Solutions

• RED-PD MFW01 designed to detect non-responsive
  flows
• Monitors only a subset of flows at the router and
  compares their rates to the targeted bandwidth
  (TB)
• TB is computed as a TCP-fair throughput for
• Observed Ploss RTT40ms
• If Ti gt TB gt flow i malicious
• Pushback RFC3168
• Once a misbehavior is detected, network nodes
  coordinate efforts to thwart a malicious
  (flooding) node

11
RED-PD

• Fact
• Network-based schemes lack the exact knowledge of
  end-point parameters
• Example
• RED-PD doesnt know about RTT TBf(Ploss,
  RTT40ms)
• Implication
• Clients with RTT gt 40 ms can exploit this
  vulnerability
• Algorithmic misbehavior
• Our algorithm tells how to re-tune AIMD
  parameters to steal bandwidth, yet elude
  detection

12
Pushback

• The request-flood attack and Pushback
• But in the request flooding scenario, the
  flooding machine is not malicious
• moreover, it is a victim

13
An End-Point Solution

• Sender-side verification
• Ping Agent
• Measures RTT by pinging the receiver
• TFRC Agent
• Computes TCP-fair rate
• Control Agent
• Enforces the sending rate

14
A Server-Side Only Solution

• Secure RTT measurement
• What if the receiver simulates a shorter RTT?
• Use nonce ESWSA01
• Randomize the time between pings
• Secure Ploss measurement
• What if the receiver floods the sender with
  requests?
• Use nonce ESWSA01
• The sender purposely drops a packet
• if the receiver never re-request the packet
  it is cheating!

The solution is completely independent of a
potentially misbehaving receiver
15
Evaluation

• Scenarios
• with behaving receiver (to study false positives)
• with misbehaving receivers (to study detection)

End-point scheme is able to detect even very
moderate misbehaviors
Slight inaccuracy for higher packet loss
ratios (due to TFRC conservatism)
16
Challenges

• Advanced TCP stacks
• From the senders
• perspective, advanced
• TCP stacks look like a
• receivers misbehavior
• HTTP servers
• A single malicious receiver can significantly
  degrade performance to others
• Counter mechanisms discussed in the paper
• Can protect against DoS, but at the same time can
  reduce the performance in absence of DoS attacks

17
Conclusions

• Receiver-based TCP stacks are highly vulnerable
  to receiver misbehaviors
• cannot be safely deployed in the Internet without
  some level of protection
• Network-based schemes are fundamentally limited
  to thwart receiver misbehaviors
• An end-point-based solution
• accurate and independent of a potentially
  misbehaving receiver
• system security and protocol performance
• both cannot be maximized simultaneously