Edge-based Inference, Control, and DoS Resilience for the Internet

1
Edge-based Inference, Control, and DoS Resilience
for the Internet
Ph.D. Thesis Presentation Aleksandar Kuzmanovic
2
The Internet

• 1969

• 2004

The system of astonishing scale and complexity
3
Internet Design Principles

• Network as a black-box

• Implications
• Easy to upgrade the network
• Easy to incrementally deploy new services

• End-to-end argument Clark84
• The core is simple
• Intelligence at the
• endpoints

4
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 Improve network performance
right here right now!
5
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

6
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

7
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 TCPs
• vulnerability to
• high-rate
• non-responsive flows

8
Design Principles - Revisited

• Design Principles
• Intelligence at the endpoints
• The core is simple
• Trust and cooperation among the endpoints

• Implications
• Easy to incrementally implement new services

• .
• Easy to upgrade the network

• .
• Large-scale system

• Implement more intelligence at routers?
• Scalability issue
• Detect misbehaving flows in routers is a hard
  problem
• Needle in a haystack

9
Design Principles - Revisited

• Design Principles
• Intelligence at the endpoints
• The core is simple
• Trust and cooperation among the endpoints

• Implications
• Malicious clients may misuse the intelligence

• .
• Easy to upgrade the network

• .
• Large-scale system

• Implement more intelligence at routers?
• Scalability issue
• Detect misbehaving flows in routers is a hard
  problem
• Needle in a haystack

10
Design Principles - Revisited

• Malicious clients may misuse the intelligence

• Design Principles
• Intelligence at the endpoints
• The core is simple
• Trust and cooperation among the endpoints

• Implications

• .
• Hard to detect endpoint misbehavior

• .
• Large-scale system

• Implement more intelligence at routers?
• Scalability issue
• Detect misbehaving flows in routers is a hard
  problem
• Needle in a haystack

11
Design Principles - Revisited

• Malicious clients may misuse the intelligence

• Design Principles
• Intelligence at the endpoints
• The core is simple
• Trust and cooperation among the endpoints

• Implications

• .
• Hard to detect endpoint misbehavior

• .
• Large-scale system

• Implement more intelligence at routers?
• Scalability issue
• Detect misbehaving flows in routers is a hard
  problem
• Needle in a haystack

12
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
• DoS-resilient protocol design
• Jointly optimize
• performance
• and security
• Outperforms the
• core-based solutions

13
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

14
Low-Rate Attacks

• TCP is vulnerable to low-rate DoS attacks

15
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

16
The Low-Rate Attack
17
The Low-Rate Attack

• 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

18
The Low-Rate Attack

• The outage synchronizes all TCP flows
• All flows react simultaneously and identically
• backoff for minRTO
• The attacker stops transmitting to elude detection

19
The Low-Rate Attack

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

20
The Low-Rate Attack

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

21
Low-Rate Attacks

• TCP is vulnerable to low-rate DoS attacks

22
Vulnerability of Receiver-Based TCP to
Misbehaviors

• Sender-based TCP
• Control functions given to the sender

23
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

24
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

25
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

26
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

27
Remaining Outline

• End-Point protocol vulnerabilities
• Limitations of network-based solutions
• Low rate attacks
• Misbehaving receivers
• DoS-resilient end-point protocol design

28
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 RTT40ms
• If Ti gt TB gt 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?

29
The Time-Scale Issue

• Scenario 9 TCP Sack flows with RED and RED-PD
• RED-PD detects high
• bandwidth flows
• DoS inter-burst period lt 500 ms

30
The Time-Scale Issue

• Scenario 9 TCP Sack flows with RED and RED-PD
• RED-PD detects high but fails to detect
  low-rate attacks
• bandwidth flows DoS inter-burst
  period gt 500 ms
• DoS inter-burst period lt 500 ms

31
CHOKe

• CHOKe PPP00 controls misbehaving flows by
  preventing a flow to monopolize buffer resources

• Question
• Why dont we use CHOKe against low-rate attacks?

32
Flow Filtering Scenario

• Heterogeneous RTT environment
• Short-RTT flows are the most vulnerable to
  low-rate attacks

• Implications
• Long-RTT flows collaborate in the attack
• Less-than bottleneck rates needed to attack
  short-RTT flows

33
CHOKe and Flow Filtering

• DoS flow utilizes only 3.3 of the bottleneck
  capacity
• CHOKe fails to throttle the low-rate attack
  against short-RTT flows

34
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

35
Bandwidth Stealing

• Fact
• Network-based schemes lack the exact knowledge of
  end-point parameters
• Example
• RED-PD doesnt know about RTT TBf(Ploss,
  RTT40ms)
• Implication
• Clients with RTT gt 40 ms can exploit this
  vulnerability
• Algorithmic misbehavior
• We generalized the TCP formula
• Tf(Ploss, RTT, a, b)
• Our algorithm tells how to re-tune AIMD
  parameters to steal bandwidth, yet elude
  detection

36
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
• End-point TCP-fairness verification

37
End-point minRTO Randomization

• Observe
• Low-rate attacks exploit protocol determinism
• minRTO1sec
• Question
• Can minRTO randomization alleviate the problem?
• Approach
• Randomize the minRTO parameter
• Insight
• The most vulnerable time-scale is Tb
• Wait for flows to recover and then hit them again

38
End-point minRTO Randomization

• TCP throughput formula on Tb time-scale of the
  low-rate attack

39
End-point minRTO Randomization

• TCP throughput formula on Tb time-scale of the
  Shrew attack
• Randomizing the minRTO parameter shifts and
  smoothes TCPs null time-scales
• Fundamental tradeoff between TCP performance and
  vulnerability to low-rate DoS attacks remains

40
An End-Point Solution

• Sender-side verification
• Ping Agent
• Measures RTT without a cooperation from the
  receiver
• TFRC Agent
• Computes TCP-fair rate
• Control Agent
• Enforces the sending rate

41
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)
42
Summary

• Denial of Service attacks represent a fundamental
  threat to todays 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

43
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

44
Publications

• 1 Measuring Service in Multi-Class Networks,
  In IEEE INFOCOM 2001.
• 2 Measurement Based Characterization and
  Classification of QoS-Enhanced 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 High-Speed 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.