1 / 15

Portcullis: Protecting Connection Setup from Denial-of-Capability Attacks

Portcullis: Protecting Connection Setup from Denial-of-Capability Attacks. Bryan Parno, Dan Wendlandt, Elaine Shi, Adrian Perrig, Bruce Maggs, Yih-Chun Hu Offense: Kiaie, A., Teng, X. Outline. Relevance Deployment Scalability. Relevance?. Portcullis is not solution to DoS

colm
Download Presentation

Portcullis: Protecting Connection Setup from Denial-of-Capability Attacks

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. Portcullis: Protecting Connection Setup from Denial-of-Capability Attacks Bryan Parno, Dan Wendlandt, Elaine Shi, Adrian Perrig, Bruce Maggs, Yih-Chun Hu Offense: Kiaie, A., Teng, X.

  2. Outline • Relevance • Deployment • Scalability

  3. Relevance? • Portcullis is not solution to DoS • Portcullis is solution to solution to DoS • Assumes capability systems • Weaknesses (from Monday): • Questionable scalability • Does not address adaptive bandwidth issue • Questionable deployment plan

  4. Relevance? • Is TVA broken? • Portcullis authors argue TVA’s capability setup is broken due to (non-working) fair-queuing • However TVA paper, section 5.4, Figure 11 demonstrates that mechanism other than fair-queuing, expiring capabilities, limit DoS attack effectiveness to 5 seconds • Not good enough? • Conclusion: Portcullis solves nonexistent problem?

  5. Deployment? • Portcullis requires modification of hosts and routers • Section 6.1, Figure 3 has nice graph evaluating full deployment • Modification of all hosts and routers • Section 6.4, Figure 5 has nice graph evaluating ‘partial’ deployment • Only ISPs upgrade routers • All hosts still need to be modified! • Conclusion: Portcullis has no partial deployment, only partial partial deployment

  6. Scalability? • Theorem 4.1. Under the Portcullis router scheduling policy … legitimate sender utilizing the Portcullis sending policy … successfully transmits a request packet in O(nm) amount of time in expectation, regardless of the strategy employed by the adversary.

  7. Scalability? • Theorem 4.1. Under the Portcullis router scheduling policy … legitimate sender utilizing the Portcullis sending policy … successfully transmits a request packet in O(nm) amount of time in expectation, regardless of the strategy employed by the adversary.

  8. Scalability? • Attacker’s goal: Conquer and use nm hosts such that O(nm) > t such that user gives up • => effective DDoS

  9. Scalability?

  10. Scalability? • Figure 3 shows graph (looks more than linear) that says with 20000 attackers, t = 8s • Median botnet size = 45000 (source (Thursday, February 16, 2006; 3:12 PM): http://www.washingtonpost.com/wp-dyn/content/article/2006/02/16/AR2006021601388.html) • Assume linear: t(45000) = 45000*8/20000 = 18s • Would you give up and go elsewhere if after 18s the page has not loaded? • Conclusion: Portcullis has scalability problem? Median likely to be > 45000 now in 2008

  11. Scalability? • “Our second result states that for any scheduling policy and any sending algorithm, a legitimate sender cannot perform better than the guarantee provided by Theorem 4.1:”

  12. Scalability? • Interpretation 1: We are on the way to destruction. We have no chance to survive make our time.

  13. Scalability? • Interpretation 2: Big contribution of this paper is to show that we should not rely on scheduling policy and sending algorithm to solve DoS/DoC problem?

  14. Summary • Portcullis: • Questionable relevance • Questionable deployment plan given huge cost-benefit ratio (benefit is small) • Questionable scalability

More Related