Aleksandar Kuzmanovic & Edward W. Knightly A Performance vs. Trust Perspective in the Design of End-Point Congestion Control Protocols
Motivation l Sender-based TCP –Control functions given to the sender
Receiver-Based TCP l Receiver decides how much data can be sent, and which data should be sent by the sender l DATA – ACK communication becomes REQ - DATA l Example protocols –TFRC [RFC3448], WebTP, and RCP
Why Receiver-Based TCP? l Example: Busy web server –Receiver-based TCP distributes the state management across a large number of clients l Generally –Whenever a feedback is needed from the receiver, receiver-based TCP has advantage over sender-based schemes due to the locality of information l 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
Vulnerability l Receivers remotely control servers by deciding which packets and when to be sent l Receivers have both means and incentive to manipulate the congestion control algorithm –Means: open source OS –Incentive: faster web browsing & file download
An Example: Request-Flood Attack l Request flood attack –A misbehaving receiver floods the server with requests, which replies and congests the network l Resource stealing –A misbehaving receiver moderately re-tunes TCP parameters to gain performance, yet eludes detection
Remaining Outline l Modeling receiver misbehaviors l Evaluate network-based solutions l Present an end-point solution l Conclusion
Algorithmic Misbehavior Why parameter-based misbehaviors? –Easy to implement –Tells how much you can misbehave while eluding detection l Goal –Compute TCP throughput for arbitrary (misbehaving) parameters
Bandwidth Stealing
Network-Based Solutions l 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 & RTT=40ms If Ti > TB => flow i malicious l Pushback [RFC3168] –Once a misbehavior is detected, network nodes coordinate efforts to thwart a malicious (flooding) node
RED-PD l Fact –Network-based schemes lack the exact knowledge of end-point parameters l Example –RED-PD doesn’t know about RTT: TB=f(Ploss, RTT=40ms) l Implication –Clients with RTT > 40 ms can exploit this vulnerability l Algorithmic misbehavior –Our algorithm tells how to re-tune AIMD parameters to steal bandwidth, yet elude detection
Pushback l The request-flood attack and Pushback l But in the request flooding scenario, the flooding machine is not malicious –moreover, it is a victim…
An End-Point Solution l Sender-side verification: –Ping Agent: Measures RTT by pinging the receiver –TFRC Agent: Computes “TCP- fair” rate –Control Agent: Enforces the sending rate
A Server-Side Only Solution l Secure RTT measurement –What if the receiver simulates a shorter RTT? Use nonce [ESWSA01] Randomize the time between pings l 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
Evaluation l 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)
Challenges l “Advanced” TCP stacks –From the sender’s perspective, advanced TCP stacks look like a receiver’s misbehavior l 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
Conclusions l Receiver-based TCP stacks are highly vulnerable to receiver misbehaviors –cannot be safely deployed in the Internet without some level of protection l Network-based schemes are fundamentally limited to thwart receiver misbehaviors l An end-point-based solution –accurate and independent of a potentially misbehaving receiver –system security and protocol performance both cannot be maximized simultaneously