Offense

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 fairqueuing, 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(nm) 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(nm) amount of
time in expectation, regardless of the strategy
employed by the adversary.
Scalability?
• Attacker’s goal: Conquer and use nm hosts
such that O(nm) > t such that user gives up
• => effective DDoS
Scalability?
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/wpdyn/content/article/2006/02/16/AR2006021601388.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 > 45000 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 costbenefit ratio (benefit is small)
– Questionable scalability