Aleksandar Kuzmanovic & Edward W. Knightly
A Performance vs. Trust Perspective in the Design of End-Point Congestion Control
Protocols
Motivation
Sender-based TCP– Control functions given to the sender
RWND
CWND
SND.NXTSND.UNA
FlowControl
Re liability
Conge stion Contro l
SendMuchNextSend
Loss/Progress
se nd buffe r
SEG.ACK
SEG.WND
SEG.SEQ
SEG.ACKSEQ.WND
SEG.SEQ
RCV.NXTRCV.WNDResequencing
re cv buffe r
TC P SENDER
TC P REC EI VER
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
RCV.NXTSEG.WNDREQ.NXT
FlowControl
Reliability
Congestion Control
ReqMuchNextReq
Loss/Progress
rec v /req buf f er
SEG.REQ
SEG.DEQ
SEG.SEQ
SND.NXT Send
s end buf f er
RC P REC EI VER
RC P SENDERCWND
RWND
SEG.SEQ
SEG.REQSEG.DEQ
ReqMuch
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
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
Server(Sender)
Client(Receiver)
request
data?
Can HTTP, file, and stream ing servers in the I nternet safely deploy the receiver- driven TCP protocols?
An Example:Request-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
Server
Requests
Malicious Client
Remaining Outline
Modeling receiver misbehaviors
Evaluate network-based solutions
Present an end-point solution
Conclusion
Algorithmic Misbehavior
Why parameter-based misbehaviors?– Easy to implement– Tells how much you
can misbehave while eluding detection
Co
ng
est
ion
Win
do
w
T ime
packet loss
W =2
a=1
b=1/ 2 RTO=1s
Goal– Compute TCP throughput for arbitrary (misbehaving)
parameters
Bandwidth Stealing
"Uniform" stealing ( AI MD)
"Biased" stealing (RTO)
Denial ofS ervice
)321()2
)1)(1(3,1min(
)1()1(2
1
22 pp
adddbp
RTOdadbp
RTT
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 & RTT=40ms
If Ti > TB => flow i malicious
Pushback [RFC3168]– Once a misbehavior is detected, network nodes
coordinate efforts to thwart a malicious (flooding) node
RED-PD
Fact– Network-based schemes
lack the exact knowledge of end-point parameters
Example– RED-PD doesn’t know about
RTT: TB=f(Ploss, RTT=40ms)
Implication– Clients with RTT > 40 ms
can exploit this vulnerability
Algorithmic misbehavior– Our algorithm tells how to
re-tune AIMD parameters to steal bandwidth, yet elude detection
S erverMisbehaving Client
Pushback
The request-flood attack and Pushback
But in the request flooding scenario, the flooding machine is not malicious – moreover, it is a victim…
S erverMisbehaving Client
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
SND.NXT Send
s end buf f er
SEG.SEQ
SEG.REQSEG.DEQ
PingAgent
PNG.SND
PNG.RCV
TFRCAgent
Control Agent
RTT
Ploss
Measured Throughput
ComputedThroughput
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!
SND.NXT Send
s end buf f er
SEG.SEQ
SEG.REQSEG.DEQ
PingAgent
PNG.SND
PNG.RCV
TFRCAgent
Control Agent
RTT
Ploss
Measured Throughput
ComputedThroughput
The solution is completelyindependent of a potentially
misbehaving receiver
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)
Challenges
“Advanced” TCP stacks– From the sender’s perspective, advanced TCP stacks look like a receiver’s 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
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
Top Related