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 Portcullis is solution to solution to DoS Assumes capability systems Weaknesses (from Monday): – Questionable scalability – Does not address adaptive bandwidth issue – Questionable deployment plan

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?

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

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

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

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

Scalability?

Figure 3 shows graph (looks more than linear) that says with attackers, t = 8s Median botnet size = (source (Thursday, February 16, 2006; 3:12 PM): dyn/content/article/2006/02/16/AR ht ml) dyn/content/article/2006/02/16/AR ht ml 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 > now in 2008

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:”

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

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?

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