Towards Robust Protocol Design: 4 Ways to Kill TCP without Much Trouble

1
Towards Robust Protocol Design 4 Ways to Kill
TCP without Much Trouble

• Aleksandar Kuzmanovic
• Northwestern University

http//networks.cs.northwestern.edu
2
The Internet

• 1969

• 2007

The system of astonishing scale and complexity
3
Denial of Service Problem

• Assumption
• Trust and cooperation among endpoints
• Denial of Service Attacks
• A malicious way to consume resources in a
  network, a server cluster or in an end host,
  thereby denying service to other legitimate users
• FBI Computer Crime Security Survey
• Overall financial losses 201,000,000
• Denial of Service 65,000,000

4
Approach

• Should we find ways to defend the Internet from
  DoS attacks?
• Of course!
• Anticipating novel types of DoS attacks is
  essential
• More relevant and more challenging
• My focus TCP
• More than 90 of traffic today is TCP

5
Outline

• Brief background on TCP
• Four ways to kill TCP
• Shrew attacks
• Padding misbehavior
• TCP poisoning attacks
• Receiver-driven TCP stacks

6
TCP Congestion Control

• Slow-start phase
• Double the sending ... ... rate each round-trip
  ... time
• Reach high throughput ...quickly

7
TCP Congestion Control

• Additive Increase ...Multiplicative
  Decrease
• Fairness among flows

8
TCP Congestion Control

• Exponential
• .backoff
• System stability
• Vulnerability to ... ..high-rate attacks

9
Shrew Attacks

• TCP is vulnerable to low-rate DoS attacks

10
Shrew

• Very small but aggressive mammal that ferociously
  attacks and kills much larger animals with a
  venomous bite

• Reviewer 3 only some shrews are venomous and
  the amount of venom in even the venomous species
  is very mild.

11
TCP a Dual Time-Scale Perspective

• Two time-scales fundamentally required
• RTT time-scales (10-100 ms)
• AIMD control
• RTO time-scales (RTOSRTT4RTTVAR)
• Avoid congestion collapse
• Lower-bounding the RTO parameter
• AllPax99 minRTO 1 sec
• to avoid spurious retransmissions
• RFC2988 recommends minRTO 1 sec

12
The Shrew Attack
13
The Shrew Attack

• A short burst (RTT) sufficient to create outage
• Outage event of correlated packet losses that
  forces TCP to enter RTO mechanism

14
The Shrew Attack

• The outage synchronizes all TCP flows
• All flows react simultaneously and identically
• backoff for minRTO

15
The Shrew Attack

• Once the TCP flows try to recover hit them
  again
• Exploit protocol determinism

16
The Shrew Attack

• And keep repeating
• RTT-time-scale outages inter-spaced on minRTO
  periods can deny service to TCP traffic

17
Shrews are Hard to Detect

• l/T ltlt 1
• Low-rate flow is hard to detect
• Most counter-DOS mechanisms tuned for high-rate
  attacks
• Detecting Shrews may have unacceptably many false
  alarms (due to legitimate bursty flows)

18
Outline

• Brief background on TCP
• Four ways to kill TCP
• Shrew attacks
• Padding misbehavior
• TCP poisoning attacks
• Receiver-driven TCP stacks

19
The Source of the Problem

• TCP optimized for throughput
• Interactive applications may suffer
• telnet, ssh, games, chat

RTO
Incentive for misbehavior!
20
Upgrading Mice to Elephants
data packets
strict priority
TCP-fair rate
dummy packets
Padding misbehavior
21
Implication
Packet switched gt Circuit switched
22
Gain
Fully-backlogged flows always achieve gain
relative to interactive flows
23
Sustainable Countermeasures

• Short-term padding with dummy packets
• Enable that a packet loss is detected via fast
  retransmit mechanism
• Actual packet followed by three tiny dummy
  packets.
• A diversity approach
• TCP sends k (kgt1, k is a small integer) copies of
  the packet without violating congestion control
  mechanism
• In reality k2 is sufficient

Both approaches de-motivate greedy users from
using the fully-backlogged approach
24
Outline

• Brief background on TCP
• Four ways to kill TCP
• Shrew attacks
• Padding misbehavior
• TCP poisoning attacks
• Receiver-driven TCP stacks

25
A TCP Poisoning Attack

• Background
• Mis-configured load balancers can reset TCP
  connections
• Simply send a RST packet to an endpoint
• Implication
• Monitoring -gt DoS attacks
• Just send a bogus packet and poison an endpoint
• TCP behaves as a dummy state machine
• Both control and data planes are vulnerable

26
Large-Scale TCP Poisoning Attacks

• Example
• Poison clients instead of a server

A2
C1
C2
A1
Server
Cn
27
Why Not Cryptography?

• Explicit monitoring required in networks
• Advanced congestion control protocols (e.g., XCP)
• Intrusion-detection mechanisms
• Not implemented widely
• E.g., IPSec
• Even cryptography wont help
• Key exchange vulnerable to poisoning

28
Our Approach

• Deferred protocol reaction
• Attack detection
• Forward nonces
• Distinguish packet streams from different hosts
• Self-clocking based correlation
• Identify the valid packet stream

29
How long to defer?
30
Forward Nonces

• Chaining mechanism to distinguish among different
  packet sources
• Past and future nonce
• 8-bit random numbers
• Overhead 2 bytes/packet

31
Self Clocking Based Correlation
Idea Exploit strong correlation among
inter- departure and inter-arrival times at an
endpoint
IDTi
ACKi
IDTi1
ACKi1
ACKi2
IDTi2
ACKi3
DATAi
DATAi1
IATi
DATAi2
IATi1
DATAi3
IATi2
32
Evaluation

• Our approach dramatically improves performance
  over standard TCP

33
Outline

• Brief background on TCP
• Four ways to kill TCP
• Shrew attacks
• Padding misbehavior
• TCP poisoning attacks
• Receiver-driven TCP stacks

34
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

35
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

36
An Example Request-Flood Attack

• Request flood attack
• A misbehaving receiver
• floods the server with
• requests, which replies and
• congests the network

37
Conclusions

• Think of attacks, not just defenses
• More challenging and more relevant
• Robust protocol design
• Avoid determinism whenever you can
• Understand extreme scenarios
• Explore novel defense mechanisms
• E.g., use measurements to achieve DoS resilience
• Anticipate effects before applying a change

38
Thank You!

• More information available at
• http//networks.cs.northwestern.edu
• Questions?