Transcript Thesis Defense

Edge-based Inference,
Control, and DoS Resilience
for the Internet
Ph.D. Thesis Presentation
Aleksandar Kuzmanovic
The Internet
1969

SR
UCSB

2004
UTAH
UCLA
The system of astonishing scale and complexity
Aleksandar Kuzmanovic
Internet Design Principles


Network as a black-box
End-to-end argument [Clark84]
– The core is simple
– Intelligence at the
endpoints
Aleksandar Kuzmanovic

Implications
– Easy to upgrade the
network
– Easy to incrementally
deploy new services
Why End-Point Approach Today?

Scalability
e2e

scalability
Deployability
– IP and network core are not extensible and
are slowly evolving:


IPv6 (10 years)
IP Multicast (domain dependent)
Goal:
Aleksandar Kuzmanovic
Improve network performance
right here – right now!
Network Performance

Internet traffic
– HTTP (web browsing)
– FTP (file transfer)


Fact: 95% of the traffic today is TCP-based
Performance
– QoS differentiation


Net win for both HTTP and FTP flows
End-point-based two-level differentiation scheme
– Denial of Service


DoS attacks can demolish network performance
Prevent DoS attacks via a robust end-point protocol
design
Aleksandar Kuzmanovic
End-Point Service Differentiation





TCP-Low Priority
– Utilizes only the excess network bandwidth
Key mechanism
– Early congestion indications: one-way packet delay
Performance
– Can improve the HTTP file transfers for more than 90%
when FTP flows use TCP-LP
Deployability
– no changes in the network core
– sender side modification of TCP
High-speed version developed in cooperation with SLAC
– tested over Gb/s networks in US
http://www.ece.rice.edu/networks/TCP-LP
Aleksandar Kuzmanovic
Denial of Service

A malicious way to consume resources in a
network, a server cluster or in an end host,
thereby denying service to other legitimate users

Example
– Well-known TCP’s
vulnerability to
high-rate
non-responsive flows
Aleksandar Kuzmanovic
Victim
Attacker
Design Principles - Revisited


Design Principles
– Intelligence at the
endpoints
– The core is simple
– Trust and cooperation
among the endpoints
Implement more intelligence
at routers?
– Scalability issue
– Detect misbehaving flows
in routers is a hard
problem

Needle in a haystack
Aleksandar Kuzmanovic
Implications
– Easy to incrementally
.
implement new services
– Easy to upgrade the
.
network
– Large-scale system

Core Routers
Design Principles - Revisited


Design Principles
– Intelligence at the
endpoints
– The core is simple
– Trust and cooperation
among the endpoints
Implement more intelligence
at routers?
– Scalability issue
– Detect misbehaving flows
in routers is a hard
problem

Needle in a haystack
Aleksandar Kuzmanovic
Implications
– Malicious clients may
.
misuse the intelligence
– Easy to upgrade the
.
network
– Large-scale system

Core Routers
Design Principles - Revisited


Design Principles
– Intelligence at the
endpoints
– The core is simple
– Trust and cooperation
among the endpoints
Implement more intelligence
at routers?
– Scalability issue
– Detect misbehaving flows
in routers is a hard
problem

Needle in a haystack
Aleksandar Kuzmanovic
Implications
– Malicious clients may
.
misuse the intelligence
– Hard to detect endpoint
.
misbehavior
– Large-scale system

Core Routers
Design Principles - Revisited


Design Principles
– Intelligence at the
endpoints
– The core is simple
– Trust and cooperation
among the endpoints
Implement more intelligence
at routers?
– Scalability issue
– Detect misbehaving flows
in routers is a hard
problem

Needle in a haystack
Aleksandar Kuzmanovic
Implications
– Malicious clients may
.
misuse the intelligence
– Hard to detect endpoint
.
misbehavior
– Large-scale system

Core Routers
End-Point Protocol Design

Performance vs. Security
– End-point protocols are designed to maximize
performance, but ignore security
– 95% of the Internet traffic is TCP traffic
 Can have catastrophic consequences
Endpoints

DoS-resilient protocol design
– Jointly optimize
performance
and security
– Outperforms the
core-based solutions
Aleksandar Kuzmanovic
Remaining Outline

End-point protocol vulnerabilities
– Low-rate TCP-targeted DoS attacks
– Receiver-based TCP stacks with a misbehaving
receiver

Limitations of network-based solutions

DoS-resilient end-point protocol design
Aleksandar Kuzmanovic
Low-Rate Attacks

TCP is vulnerable to low-rate DoS attacks
TCP
DoS
Rate
DoS
DoS Inter-burst Period
Aleksandar Kuzmanovic
TCP: a Dual Time-Scale Perspective

Two time-scales fundamentally required
– RTT time-scales (~10-100 ms)

AIMD control
– RTO time-scales (RTO=SRTT+4*RTTVAR)


Avoid congestion collapse
Lower-bounding the RTO parameter:
– [AllPax99]: minRTO = 1 sec

to avoid spurious retransmissions
– RFC2988 recommends minRTO = 1 sec
Discrepancy between RTO and RTT time-scales is
a key source of vulnerability to low rate attacks
Aleksandar Kuzmanovic
TCP Sending Rate
The Low-Rate Attack
Victim
Attacker
DoS Rate
Time
Time
Aleksandar Kuzmanovic
TCP Sending Rate
The Low-Rate Attack
Attacker
Time


DoS Rate
short burst (~RTT)
random initial phase
Aleksandar Kuzmanovic
Victim
outage
Time

At a random initial time
A short burst (~RTT)
sufficient to create outage
– Outage – event of
correlated packet losses
that forces TCP to enter
RTO mechanism
The impact of outage is
distributed to all TCP flows
TCP Sending Rate
The Low-Rate Attack
Victim
minRTO
Attacker
Time
DoS Rate

Time
random initial phase
Aleksandar Kuzmanovic

The outage synchronizes all
TCP flows
– All flows react
simultaneously and
identically
 backoff for minRTO
The attacker stops
transmitting to elude
detection
TCP Sending Rate
The Low-Rate Attack
Victim
minRTO
Attacker
Time
DoS Rate


Time
random initial phase
Aleksandar Kuzmanovic
Once the TCP flows try to
recover
– hit them again
Exploit protocol determinism
TCP Sending Rate
The Low-Rate Attack
Victim
minRTO
minRTO
Attacker
DoS Rate
Time
Time
random initial phase
Aleksandar Kuzmanovic

And keep repeating…

RTT-time-scale outages
inter-spaced on minRTO
periods can deny service to
TCP traffic
Low-Rate Attacks

TCP is vulnerable to low-rate DoS attacks
TCP
DoS
Rate
DoS
DoS Inter-burst Period
Aleksandar Kuzmanovic
Vulnerability of Receiver-Based
TCP to Misbehaviors

Sender-based TCP
– Control functions given to the sender
SEG.ACK
SND.NXT
SND.UNA
Reliability
send buffer
Loss/
Progress
SEG.ACK
SEQ.WND
SendMuch
NextSend
RWND
Flow
Control
RCV.NXT
SEG.WND
Resequencing RCV.WND
SEG.SEQ
recv buffer
SEG.SEQ
CWND
Congestion Control
TCP SENDER
Aleksandar Kuzmanovic
TCP RECEIVER
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
SEG.SEQ
Reliability
RCV.NXT
SEG.WND
REQ.NXT
recv/req buffer
ReqMuch
NextReq
SEG.SEQ
SEG.DEQ
SND.NXT
Send
SEG.REQ
SEG.DEQ
send buffer
Flow
Control
RWND
Loss/
Progress
ReqMuch
SEG.REQ
RCP SENDER

Congestion Control
Example protocols
– TFRC [RFC3448], WebTP, and RCP
Aleksandar Kuzmanovic
CWND
RCP RECEIVER
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, receiverbased TCP has advantage over sender-based schemes due
to the locality of information

Benefits [RCP03]
Performance
- Loss recovery
Functionality
- Seamless handoffs
- Congestion control
- Server migration
- Power management for
- Bandwidth aggregation
mobile devices
- Web response times
- Network-specific congestion control
Aleksandar Kuzmanovic
Vulnerability


Receivers decide which packets and when to be
sent
– Receivers remotely control servers
Receivers have both means and incentive to
manipulate the congestion control algorithm
– Means: open source OS
– Incentive: faster web browsing & file download
Aleksandar Kuzmanovic
Receiver-Induced DoS Attacks

Request flood attack
– A misbehaving receiver
floods the server with
requests, which replies and
congests the network

Goals
– Evaluate
network-based
schemes
– Develop
end-point
solutions
Aleksandar Kuzmanovic
Remaining Outline

End-Point protocol vulnerabilities

Limitations of network-based solutions
Core Routers
– Low rate attacks
– Misbehaving receivers

DoS-resilient end-point protocol design
Aleksandar Kuzmanovic
Random Early Detection with
Preferential Dropping

RED-PD [MFW01] designed to detect and thwart
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
Key questions
– Can algorithms intended to find high-rate attacks
detect low-rate attacks?
– Could we tune the algorithms to detect low-rate
attacks without having too many false alarms?
Aleksandar Kuzmanovic
The Time-Scale Issue

Scenario: 9 TCP Sack flows with RED and RED-PD
– RED-PD detects high
bandwidth flows

DoS inter-burst period < 500 ms
Aleksandar Kuzmanovic
The Time-Scale Issue

Scenario: 9 TCP Sack flows with RED and RED-PD
– RED-PD detects high
bandwidth flows

but fails to detect low-rate attacks
DoS inter-burst period > 500 ms
DoS inter-burst period < 500 ms
Aleksandar Kuzmanovic
CHOKe

CHOKe [PPP00] controls misbehaving flows by
preventing a flow to monopolize buffer resources
=
=

Question:
– Why don’t we use CHOKe against low-rate
attacks?
Aleksandar Kuzmanovic
Flow Filtering Scenario
Heterogeneous RTT environment:
– Short-RTT flows are the most vulnerable to lowrate attacks

flow
cut-off time scale
no pass
pass
outage length
Aleksandar Kuzmanovic

RTT
Implications:
– Long-RTT flows
‘collaborate’ in
the attack
– Less-than
bottleneck rates
needed to attack
short-RTT flows
CHOKe and Flow Filtering
TCP (long-RTT)
TCP (short-RTT)
C
DoS


Aleksandar Kuzmanovic
DoS flow utilizes
only 3.3% of the
bottleneck capacity
CHOKe fails to
throttle the low-rate
attack against
short-RTT flows
Request Flooding DoS Attack

Pushback [RFC3168]
– Network nodes coordinate efforts to detect a
malicious (flooding) node

But in the request flooding scenario, the flooding
machine is not malicious
– moreover, it is a victim…
Aleksandar Kuzmanovic
Bandwidth Stealing

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
– We generalized the TCP
formula
 T=f(Ploss, RTT, a, b)
– Our algorithm tells how to
re-tune AIMD parameters to
steal bandwidth, yet elude
detection
Aleksandar Kuzmanovic
Summary of Limitations



Low rate attacks
– RED-PD: issue of time-scales
– CHOKe: flow filtering
Misbehaving receivers
– Pushback: No distinction of causes and effects
– RED-PD: No knowledge of endpoint parameters
Can we do better from the endpoints?
– End-point parameter randomization
Endpoints
– End-point TCP-fairness verification
Aleksandar Kuzmanovic
End-point minRTO Randomization

Observe:
– Low-rate attacks exploit protocol determinism




minRTO=1sec
Question:
– Can minRTO randomization alleviate the
problem?
Approach:
– Randomize the minRTO parameter
– min RTO  uniform(a, b)
Insight:
– The most vulnerable time-scale is T=b

Wait for flows to recover and then hit them again
Aleksandar Kuzmanovic
End-point minRTO Randomization
TCP throughput formula on T=b time-scale of
the low-rate attack

n ba
 (T  b) 
n 1 b
1
1/2
 (T  b; b  1)
Spurious
re-transmissions
[AllPax99]
high
aggregation
low
aggregation
a
1
Aleksandar Kuzmanovic
1
1/2
n - number of TCP flows
a,b - param. of unif. dist.
 (T  b; a  1)
Bad for short-lived
(HTTP) traffic
high
aggregation
low
aggregation
1
b
2
End-point minRTO Randomization

TCP throughput formula on T=b time-scale of
the Shrew attack
n ba
 (T  b) 
n 1 b
n - number of TCP flows
a,b - param. of unif. dist.

Randomizing the minRTO parameter shifts and
smoothes TCP’s null time-scales

Fundamental tradeoff between TCP
performance and vulnerability to low-rate DoS
attacks remains
Aleksandar Kuzmanovic
An End-Point Solution

Sender-side
verification:
– Ping Agent:

Measures RTT
without a
cooperation from
the receiver
– TFRC Agent:

Computes “TCPfair” rate
– Control Agent:

Enforces the
sending rate
Aleksandar Kuzmanovic
SEG.SEQ
SND.NXT
Send
SEG.REQ
SEG.DEQ
send buffer
Measured
Control
Agent
Computed
Throughput
Throughput
Ploss
TFRC
Agent
PNG.SND
RTT
Ping
Agent
PNG.RCV
Evaluation

Scenarios:
– with behaving receiver (to study false positives)
– with misbehaving receivers (to study detection)
Slight inaccuracy for higher
packet loss ratios (due to TFRC
conservatism)
Aleksandar Kuzmanovic
End-point
scheme is able
to detect even
very moderate
misbehaviors
Summary

Denial of Service attacks represent a
fundamental threat to today’s Internet

Network-based solutions are necessary, yet are
quite often very limited

End-point protocols optimized for performance,
not security

DoS-resilient protocol design


Parameter randomization
Ability to control the other end-point
Aleksandar Kuzmanovic
Conclusions

Improve network performance via
– End-point QoS differentiation
– DoS-resilient protocol design

QoS differentiation
– Developed, implemented, and tested TCP-LP
– Can significantly improve the network performance

Denial of Service
– Pro-active approach
– Jointly consider both performance and security
aspects
Aleksandar Kuzmanovic
Publications
[1] Measuring Service in Multi-Class Networks, In IEEE INFOCOM 2001.
[2] Measurement Based Characterization and Classification of QoSEnhanced Systems, In IEEE TPDS, 14(7): 671-685, 2003.
[3] TCP-LP: A Distributed Algorithm for Low Priority Data Transfer, In
IEEE INFOCOM 2003.
[4] TCP-LP: Low-Priority Service via End-Point Congestion Control, To
appear in IEEE/ACM ToN.
[5]* HSTCP-LP: A Protocol for Low-Priority Bulk Data Transfer in HighSpeed High-RTT Networks, In PFLDnet 2004.
[6] Low-Rate TCP-Targeted Denial of Service Attacks
(The Shrew vs. the Mice and Elephants), In ACM SIGCOMM 2003.
[7] Low-Rate TCP-Targeted Denial of Service Attacks and Counter
Strategies, Submitted to IEEE/ACM ToN.
[8] A Performance vs. Trust Perspective in the Design of End-Point
Congestion Control Protocols, In IEEE ICNP 2004.
[9] Receiver-based Congestion Control with a Misbehaving Receiver:
Vulnerabilities and End-Point Solutions, Submitted to IEEE/ACM ToN.
* With R. Les Cottrell, SLAC.
Aleksandar Kuzmanovic