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