Outline : Part 1

! Introduction
Protocol Attacks ! What is a protocol attack?
! How does it work?

By ! Different types of protocol attack

Sushant Rewaskar

Introduction: Types of attacks What is a protocol attack?

! Buffer overflow ! Exploit a specific feature or

! Weak authentication/encryption implementation bug of some
! Inadequate argument checking protocol installed at the victim in
order to consume excess amounts of
! Configuration errors its resources
! Insecure program features
! Kernel-level problems
! Protocol attack

Popular Protocol attack Smurf Attack

! Smurf Attack
! SYN attack
! UDP Attack, ICMP Attack
ICMP echo ICMP echo
! CGI request attack request response
SRC :X SRC :X
! Authentication server attack
! Attack using DNS systems.
! Attack using spoofed address in ping Y X
UDP Attack, ICMP Attack, Ping attack TCP SYN

! Uses TCPs 3 way hand shake

! Send a SYN packet with a spoofed IP
address
! Server is not able to complete the
echo request
echo response handshake and as a result wastes all its
SRC:Y Y network resources

CGI request attack Authentication server attack

! CGI script uses CPU cycles to satisfy a ! Authentication server validates a

request. signature
! Attacker send multiple CGI requests ! It takes more resources to check a
! This consumes precious CPU cycle on bogus signature then to create it.
the server ! Attacker send a bogus signature to the
server

Server X

Attack using DNS systems. Feature of these attacks

! All attacks need a lot of attackers

DNS response
(zombies)
! Mitigate by changing the protocol

DNS request
features
SRC X ! Line between protocol and brute force
X
commands is very thin
! Can these attacks be identified?
! YES
Conclusion : Part 1 Alternate Protocol attacks

! High-Rate Protocol attack ! Use some feature of the protocol to

! Very close to Brute force attack
launch an attack without being
aggressive
! Can this be done?
! Yes
! Misbehaving receiver attack
! Shrew attack

Outline : Part 2 TCP Congestion Control

Senders Congestion Window

! TCP mechanism Byte 1st

sequence Byte
Last
Byte

! Congestion window modification Sent and Sent and not Eligible to

Ineligible
ACKed ACKed be sent
! Congestion avoidance
nextSeqNum (= LastByteSent + 1)
! Design attack to make use of congestion sendBase (= LastByteACKed + 1)
window update on acks ! Transmission rate is limited by the congestion
! Evaluate attacks efficiency window size, congWin
LastByteSent - LastByteACKed ! MIN(congWin,RcvWindow)
! TCP modification to prevent the attack ! Maximum rate is w MSS byte segments sent every
RTT throughput = w x MSS bytes/sec
RTT

TCP Congestion Control TCP Congestion Control

Host A Host B Senders Congestion Window
! If w ! MSS/R < RTT, then Byte 1st Last
the maximum rate at which sequence Byte Byte
a TCP connection can wMSS
data
transmit data is bytes
data
data
w x MSS RTT
data ! TCP connections probe for available bandwidth
bytes/sec K ! Increase the congestion window until loss occurs
RTT secs AC
! When loss is detected decrease window, then begin probing
data
(increasing) again
! w is the minimum of the data ! The congestion window grows in two phases:
number of segments in the data ! Slow start Ramp up transmission rate until loss occurs
receivers window or the data
congestion window ! Congestion avoidance Keep connection close to sustainable
AC
K bandwidth
! A window size threshold (bytes transmitted) distinguishes
between slow start and congestion avoidance phases
Time
 TCP Congestion Control TCP Congestion Control
Host A Host B
congWin = 1 MSS ! Increase congestion window by 1 segment each RTT,
for (each original ACK received) congWin++ one se
gmen
decrease by a factor of 2 when packet loss is detected
t
until (loss event OR congWin > threshold) ! Additive Increase, Multiplicative Decrease (AIMD)

RTT
/* slowstart is over; 12
! Exponential increase in window two se
gments congWin > threshold 11
size each RTT until:

Congestion window size

10
*/ 9
! Loss occurs until (loss event) { 8
congWin = threshold

(segments)
! whenever congWin segments 7
Threshold
(Not so slow!) four s
ACKed: 6
Threshold
egmen congWin++ 5
! Note: TCP implementations ts
} 4 Loss
detect loss differently /* loss event timeout */ 3 event
2
! TCP Tahoe: Timeout threshold = congWin/2 1
! TCP Reno: Timeout or three congWin = 1 MSS 0
duplicate ACKs perform slowstart 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Time Window transmissions

TCP Congestion Control TCP Congestion Control

! The threshold is an estimate
Congestion window size (segments)

24
Slow Congestion

Congestion window size (segments)

24
of a safe level of throughput 22 Start Avoidance ! Loss (at any time) reduces Slow Congestion
that is sustainable in the 20 the safe throughput 22 Start Avoidance
network 18 estimate to 1/2 of the 20

! The threshold specifies a 16 current throughput 18

16
throughput that was 14 ! This is the throughput
sustainable in the recent 12 that resulted in loss 14
past 10
12

8 ! Slow-start begins anew 10

! Slow-start quickly increases 6
whenever there is loss 8
throughput to this threshold 4
6

2
! Throughput at initial 4
! Congestion avoidance slows 0
threshold = 1 MB/RTT 2
probes for additional 0 2 4 6 8 10 12 14 16 18 20 ! At 1st threshold: 16MSS/RTT 0
available bandwidth beyond Window transmissions ! At 2nd threshold: 10MSS/RTT
0 2 4 6 8 10 12 14 16 18 20
the threshold Window transmissions
w x MSS w x MSS
Assume RTT > Assume RTT >
R R

TCP Congestion Control Outline : Part 2

24
Congestion window size (segments)

! TCP Tahoe: Slow Congestion

! TCP mechanism
22 Start Avoidance
! Loss signaled by timeout 20
! threshold = congWin/2 18
! Congestion window modification
! congWin = 1 MSS 16
14 ! Congestion avoidance
! TCP Reno: 12
! Fast retransmit Receipt 10 ! Design attack to make use of congestion
of 3 duplicate ACKs also
signals a packet loss
8
6
3 duplicate ACKs
window update on acks
! Fast recovery Skips
slowstart and continue in
4
! Evaluate attacks efficiency
2
congestion avoidance new
slowstart threshold 0
0 2 4 6 8 10 12 14 16 18 20
! TCP modification to prevent the attack
! Others: TCP NewReno, Window transmissions
SACK,
w x MSS
Assume RTT >
R
TCP Mechanism Ack division

! Tcp work at two granularities

! Acks received and processed at bytes
granularity
! Updates to window performed at packet
granularity

A clever receiver can use this to its benefit

Expected behavior

Misbehavior

DupAck spoofing Optimistic Acking

Expected behavior

Misbehavior

Outline : Part 2 Evaluation: Ack division

! TCP mechanism
! Congestion window modification
! Congestion avoidance

! Design attack to make use of congestion

window update on acks
! Evaluate attacks efficiency
! TCP modification to prevent the attack
Evaluation : Ack spoofing Evaluation : Optimistic acking

Outline : Part 2 Solution

! TCP mechanism ! Ack division

! Congestion window modification ! Increment congestion window only when
! Congestion avoidance you get MSS bytes of data
! Design attack to make use of congestion ! DupAck spoofing
window update on acks ! Use a Nonce
! Evaluate attacks efficiency ! Optimistic Acking
! TCP modification to prevent the attack ! Sum of Nonce in the acks

Conclusion Part 2 Part 3 : Outline

! Features of a Protocol can be used to ! Design attack to take advantage of the

modify its behavior in a harmful way. congestion avoidance mechanism
(shrew attack)
! Explore TCPs response to shrew attack
! Modeling, simulation, Internet experiments
! Evaluate detection mechanism
 w
o

Shrew TCP mechanism- AIMD

d
n
i
W

n
o
i
t
s
e
g
n
o
C
Time
! Very small but aggressive mammal that
ferociously attacks and kills much larger ! Operates at the RTT time-scale
animals with a venomous bite

w
o
TCP mechanism- timeout
d
n TCP dual time scale operation
i
W

n ! TCP operates at two time-scales

o
i
! RTT time-scales (~10-100 ms)
t ! AIMD control
s
e ! RTO time-scales (RTO=SRTT+4*RTTVAR)
g ! Avoid congestion collapse
n
o minRTO
! RTO must be lower bounded to avoid
C
Time
spurious retransmissions
! [AllPax99] and RFC2988 recommends
! Operates at the RTO timer time-scale minRTO = 1 sec
! seconds

Outline : Part 3 Shrew

w
Attack
o
d
! Analyze TCP congestion avoidance n
i ! Pulse induced outages
! Design attack to take advantage of the W ! create along enough outage so that all flows
experience a loss
mechanism (shrew attack) n
o
! Explore TCP response to shrew attack Short outages (~RTT)
i
! Modeling, simulation, Internet experiments t force TCP to timeout
s
! Evaluate detection mechanism e
g All flows simultaneously
n enter this state
o minRTO

C
Time
 w
o
d
n
w
Shrew
o Attack Shrew Attack
i
W
d
n n
i o
! Induce
W
an outage again after minRTO i
t
s
n
e
o g
i n
t o minRTO minRTO
s C
e
Time
g
n ! Shrew periodically repeats pulse
o minRTO minRTO

C ! RTT-time-scale outages inter-spaced on

minRTO periods can deny service to TCP
Time

Principles of Shrew Creating periodic outage

! Shrews exploit protocol homogeneity and
determinism DoS burst length l
! Protocols react in a pre-defined way rate burst rate R
! Tradeoff of vulnerability vs. predictability

! Periodic outages synchronize TCP flow states and

period T
deny their service
! Let
! Slow time scale protocol mechanisms enable low- ! l = l1+l2
rate attacks
! l1 = time to fill the queue
! Outages at RTO scale, pulses at RTT scale imply low average
rate ! l2 = RTT time-scale
! T = minRTO time-scale

Aggressiveness of stream Optimized stream

! Average rate of the stream

! Avg = ( l * R ) /T
! l = 10-100 ms

! T= 1 second

! R >=link capacity ! Average rate

! Average rate is ~1/10th of the link ! (l1*R + l2*C ) /T
capacity
Analytical model for shrew Outline : Part 3

! Consider a periodic DOS stream. Let, ! Analyze TCP congestion avoidance

outage duration satisfy following two ! Design attack to take advantage of the
conditions mechanism (shrew attack)
! L>RTT
! Explore TCP response to shrew attack
! minRTO >SRTT+4*RTTVAR
! Modeling, simulation, Internet experiments
! Throughput is given by
! Evaluate detection mechanism
! min RTO
ceil ( ) * T ! min RTO
" (T ) = T
T

Shrew : DOS rate Shrew: model

! Analytical model predicts the outage at

! Let C=R=1.5Mbps TCP
C= 1.5M
minRTO
! L = 70ms DoS

Null TCP time-scales

Shrew's Average Rate (minRTO/2; minRTO)

Shrew :Simulation Challenge for shrew

! Aggregation
! Ns simulation with l = 150ms, RTT = 12- ! Vulnerable due to Shrew-induced flow synchronization
132ms, C= 1.5ms and minRTO =1 s ! RTT heterogeneity
! Shrews are high-RTT pass filters
! DoS peak rate
! Less-than-bottleneck bursts can damage short-RTT flows
! TCP Variants
! For short burst length, TCP Reno is more fragile
! Short-lived TCP flows
! Web browsing
! Internet experiments
! Can Shrews be successful on the Internet?
Aggregation RTT heterogeneity
! TCP flows with homogeneous RTT are vulnerable ! Shrew acts as a high-RTT pass filter
! Shrews induce flow synchronization

RTT heterogeneity DoS peak rate

! 20 TCP flows; RTT ~ 20-460ms ! Long flows collaborate in the attack
! Cut off timescale ~180ms
TCP (long-RTT)
TCP (short- RTT) TCP (short- RTT)

C C
DoS DoS TCP (long-RTT)

DoS peak rate TCP variants

! Scenario: 4 TCP flows + DoS ! So far we have seen TCP reno
! 1 short-RTT & 3 long-RTT flows ! What about newReno, SACK?
! DoS outage ~ RTT of the short-RTT flow
! Experiment
! TCP variant
TCP
! Reno
! New Reno
DoS flow: ! Tahoe
peak rate: C/3 DoS
average rate: C/30 (3.3%)
! SACK
! DoS stream
! Burst rate = bottleneck capacity.
! Burst length: 30ms, 50ms, 70ms, and 90ms
TCP variants TCP variants

! Burst length = 30ms ! Burst length = 50ms

! TCP Reno is most fragile ! TCP is the most vulnerable in 1-1.2 sec time-scale
region due to slow start

TCP variants TCP variants

! Burst length = 70ms ! Burst length = 90ms

! Sufficient pulse width ensures timeout ! With large burst length all TCP are equally fragile

Short-lived TCP flows Short-lived TCP flows

! Scenario: Web browsing (50% load) Server Pool
Client Pool ! Scenario: Web browsing (50% load) Server Pool
Client Pool
! Average damage to .
request
.
! Larger files more .
request
.
. . . .
! a mouse (<100pkts) . response R2 . . response R2 .
.
R1
. vulnerable .
R1
.
=400% delay increase
! an elephant (>100pkts)
. . ! most suffer . .
. . . .
=24500% delay increase
DoS ! some benefit DoS
Internet experiments Internet experiments
DoS-B ! Shrew average rate: 909 kb/sec
DoS-A
DoS-C LAN3 ! R = 10 Mb/sec, l = 100 msec, T = 1.1 sec
LAN2 ! TCP throughput
! 9.8 Mb/sec without Shrew
! 1.2 Mb/sec with Shrew, 87.8% degradation

TCP-S

WAN LAN1 TCP-R

! Scenario: victim on a lightly loaded 10 Mb/sec LAN

! Attacker on same LAN, nearby LAN, or over WAN
! WAN path:
! EPFL"ETH, 8 hops (10/100/OC-12)

Outline : Part 3 Detecting Shrews

! Analyze TCP congestion avoidance ! Shrews have low average rate, yet send high-
rate bursts on short time-scales
! Design attack to take advantage of the ! Key questions
mechanism (shrew attack) ! Can algorithms intended to find high-rate attacks
detect Shrews?
! Explore TCP response to shrew attack ! Can we tune the algorithms to detect Shrews
without having too many false alarms?
! Modeling, simulation, Internet experiments
! A number of schemes can detect malicious
! Evaluate detection mechanism flows
! E.g., RED-PD:
! use the packet drop history to detect high-bandwidth flows
and preferentially drop packets from these flows

Router-Assisted Mechanisms End-point minRTO Randomization

! Scenario: 9 TCP Sack flows with RED and RED-PD ! Observe

! RED-PD only detects Shrews with unnecessarily high ! Shrews exploit protocol homogeneity and determinism
rate
! Reducing RED-PD measurement time scale results in ! Question
excessive false positives ! Can minRTO randomization alleviate threat of Shrews?

! TCP flows approach

! Randomize the minRTO = uniform(a,b)

! Shrews counter approach

! Given flows randomize minRTO, the optimal Shrew
pulses at time-scale T=b
! Wait for all flows to recover and then pulse again
End-point minRTO Randomization Conclusions : Part 3
! TCP throughput for T=b time-scale of the Shrew attack ! Shrew principles
Exploit slow-time-scale protocol homogeneity and
n b!a n - number of TCP flows
!

" (T = b) = a,b - param. of unif. dist.

determinism
n +1 b
! Real-world vulnerability to Shrew attacks
! a small " spurious retransmissions [AllPax99] ! Internet experiment: 87.8% throughput loss without detection
! b large " bad for short-lived (HTTP) traffic
! Shrews are difficult to detect
! Randomizing the minRTO parameter shifts and ! Low average rate and TCP friendly
smoothes TCPs null time-scales
! Cannot filter short bursts
! Fundamental mismatch of attack/defense timescales
! Fundamental tradeoff between TCP performance and
vulnerability to low-rate DoS attacks remains

Open Questions

! Can filters specific to Shrews be

designed without excessive false
positives?

! Can end-point algorithms be sufficiently

randomized, so that
! attackers cannot exploit their known
reactions
! performance is not sacrificed