1 / 20

Preventing Internet Denial-of-Service with Capabilities

Preventing Internet Denial-of-Service with Capabilities. Tom Anderson, David Wetherall Univ. of Washington Timothy Roscoe Intel Research at Berkeley. Paper Summary. An approach to prevent DoS attacks Nodes obtain “permission to send” from destination Capabilities

locke
Download Presentation

Preventing Internet Denial-of-Service with Capabilities

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Preventing Internet Denial-of-Service with Capabilities Tom Anderson, David Wetherall Univ. of Washington Timothy Roscoe Intel Research at Berkeley Anupam Chanda, Khaled Elmeleegy. Comp 629

  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 Anupam Chanda, Khaled Elmeleegy. Comp 629

  3. Overview • Motivation • Related work • Proposed solution • Conclusion Anupam Chanda, Khaled Elmeleegy. Comp 629

  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 Anupam Chanda, Khaled Elmeleegy. Comp 629

  5. Related Work Anupam Chanda, Khaled Elmeleegy. Comp 629

  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 Anupam Chanda, Khaled Elmeleegy. Comp 629

  7. IP Traceback • Traces the source of the attack • Detection rather than prevention • Can do post-mortem traceback • Marking of IP packets Anupam Chanda, Khaled Elmeleegy. Comp 629

  8. IP Traceback (contd.) A1 A2 A3 R4 R5 R6 R2 R3 R1 V Anupam Chanda, Khaled Elmeleegy. Comp 629

  9. Pushback • Pushback daemon • Monitors traffic pattern • Rules to indicate DoS attack • Communicates with upstream routers (pushback) • Upstream routers drop packets Anupam Chanda, Khaled Elmeleegy. Comp 629

  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 Anupam Chanda, Khaled Elmeleegy. Comp 629

  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 Anupam Chanda, Khaled Elmeleegy. Comp 629

  12. Proposed Solution Anupam Chanda, Khaled Elmeleegy. Comp 629

  13. System’s 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 Anupam Chanda, Khaled Elmeleegy. Comp 629

  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 Anupam Chanda, Khaled Elmeleegy. Comp 629

  15. Token Generation and passing • Destination generates a hash chain • 64-bit one way hash values h1,h2…hk • Destination sends hk back to the source through RTS servers • RTS servers and VPs remember the token and associates it with the flow Anupam Chanda, Khaled Elmeleegy. Comp 629

  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 Anupam Chanda, Khaled Elmeleegy. Comp 629

  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) Anupam Chanda, Khaled Elmeleegy. Comp 629

  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 Anupam Chanda, Khaled Elmeleegy. Comp 629

  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 Anupam Chanda, Khaled Elmeleegy. Comp 629

  20. Questions ? Anupam Chanda, Khaled Elmeleegy. Comp 629

More Related