Preventing Internet Denial-of-Service with Capabilities

1
Preventing Internet Denial-of-Service with
Capabilities

• Tom Anderson, David Wetherall
• Univ. of Washington
• Timothy Roscoe
• Intel Research at Berkeley

2
Paper Summary

• An approach to prevent DoS attacks
• Nodes obtain permission to send from
  destination
• Capabilities
• Verification points enforce capabilities
• Suitable for incremental deployment

3
Overview

• Motivation
• Related work
• Proposed solution
• Conclusion

4
Motivation

• DoS flooding limited resource
• CPU/Memory on hosts, routers, firewalls
• Anomaly detection
• Automated response often shutdown
• New applications likely to be anomalous
• Normal traffic could be an attack
• CodeRed virus

5
Related Work
6
Source Address Filtering

• At network ingress and egress points
• Prevents spoofing attacks
• However
• Addresses with same n/w prefix can be spoofed
• Attacks often consist of legitimate packets
  hosts under a virus attack

7
IP Traceback

• Traces the source of the attack
• Detection rather than prevention
• Can do post-mortem traceback
• Marking of IP packets

8
IP Traceback (contd.)
A1
A2
A3
R4
R5
R6
R2
R3
R1
V
9
Pushback

• Pushback daemon
• Monitors traffic pattern
• Rules to indicate DoS attack
• Communicates with upstream routers (pushback)
• Upstream routers drop packets

10
Anomaly Detection

• Rule-based or statistical techniques
• Classify traffic as friendly/malicious
• Malicious traffic detection
• Install network filters
• Emails to network administrators
• Legitimate applications may trigger alerts
• Application level end-to-end decision making is
  required

11
Overlay Filtering

• Traffic rerouted through special nodes
• Sophisticated analysis and filtering
• Traffic passed through overlay
• Adds a secret to the packets
• Downstream routers check for the secret
• Similar to capability-based filtering which adds
  nonce tokens in the capabilities

12
Proposed Solution
13
Systems components

• Request To Send (RTS) server
• Used by sources to get tokens to send
  (capabilities)
• Verification Points (VP)
• Perform access control by verifying the existence
  of a token in the packet
• VPs are coupled with RTS servers, both co-located
  with BGP speakers

14
Obtaining permission to send

• Autonomous Systems (AS) advertise they want their
  inbound traffic filtered
• Augment BGP advertisement
• Give the address of their RTS server
• Any AS along the way may add its RTS to the BGP
  advertisement
• Source can discover a chain of RTS servers
  through which it can send its request

15
Token Generation and passing

• Destination generates a hash chain
• 64-bit one way hash values h1,h2hk
• Destination sends hk back to the source through
  RTS servers
• RTS servers and VPs remember the token and
  associates it with the flow

16
Sending with capabilities

• Token (capability) allows source to send n
  packets in t seconds
• Source includes token in packets
• VPs along the path validates the token
• If token found and is valid, increment usage
  count
• Else drop packet

17
Acquiring new capabilities (in band)

• Could explicitly request new token
• Bad performance (overhead)
• Destination sends hk-1 ( new capability) after
  receiving nearly n packets
• Source switches to use hk-1 for the next n
  packets
• VPs switch to hk-1.
• They figure hk-1 as hk hash(hk-1) (hash chain)

18
Security issues

• RTS servers control RTS pkt rates to destinations
• RTS servers are protected against flood
• Only accessed by nodes on the same AS or another
  RTS servers
• Tokens are difficult to guess
• If you can sniff then you can disrupt the
  communication anyway

19
Conclusions

• Explicit authorization scheme to address DoS
• Paper argued that the scheme other than it solves
  the DoS problem, it is
• Feasible
• Incrementally deployable
• No experiments, so no sense of added overhead

20
Questions ?