Deployable DDoS Resiliency

1
Deployable DDoS Resiliency

• Ph.D. Candidate Soon Hin Khor
• Advisor Assoc. Prof. Akihiro Nakao

2
Outline

• DDoS definition and types
• Motivation
• Problem statement
• Existing research
• Approach
• Our contribution
• Overview of research
• Conclusion

3
Distributed Denial-of-Service (DDoS)
Internet
Network bottleneck
Server bottleneck
4
DDoS Types

• Spoofed/Net-level
• Non-filterable
• Economic

5
Spoofed/Net-Level DDoS
Spoofed
Payload
Source
8_at_
Arbitrary
Internet
6
Non-filterable DDoS
DDoS Defense
7
Non-filterable DDoS
Send legitimate packets
DDoS Defense
Network bottleneck
Server bottleneck
8
Internet Cloud New DDoS
Internet
Elastic Cloud
9
New Problem eDDoS
Internet
Pay- as- attacker-use
Elastic Cloud
10
The Issue is Real

• http//developer.amazonwebservices.com/connect/mes
  sage.jspa?messageID120089

aiCache
11
If eDDoS Happens

• Historical Data
• Attack on BetCris, Nov 2003, 1.5 3Gbps
• Attack on DNS root servers, Mar 2007, 1 Gbps
• Assuming 1Gbps, and data transfer is 0.1/GB
• 24 hours gt 24 3600 0.1/8 11k
• Internet connectivity cost
• T3 (45 Mbps) 3k to 12k/mth
• OC3 (155 Mbps) 15k to 100k/mth
• http//www.broadbandlocators.com/

12
Motivation

• End-users anecdotal evidence
• CSI Computer Crime 2008
• 21 of participants experienced DoS
• Infrastructure providers (ISPs) anecdotal
  evidence
• ArborNetworks Infrastructure Security Report 2008
• 21 indicated DoS is top consumer of operation
  resource
• Measured statistics from researchers
• Inferring DDoS paper (Savage et al.)
• 2001-2004 68,700 attacks on 5,300 domains

Problem is real!
13
Motivation (cont.)

• Analysis of 10 years of DDoS research
• 2000 CenterTrack, Blackhole routing
• 2001 DPF, Traceback ICMP, Algebraic traceback,
  Various traceback
• 2002 D-WARD, SOS, Pushback
• 2003 HCF, Capabilities, Mayday
• 2004 SIFF
• 2005 WebSOS, AITF, TVA, Route Tunnel
• 2006 Speak-Up, Flow-Cookies (CAT)
• 2007 Portcullis
• 2008 Phalanx
• 2009 StopIt

No Practically Deployable Research
14
Problem Statement
Deployable DDoS Mitigation

• Practically deployable
• Effective against all DDoS types

15
Practically Deployable Definition

• DDoS mitigation service as common as firewall
• Cost-benefit affordability
• Manageability
• Not restricted to those large organizations

Why is practical deployment HARD?
16
Location of Defense Server
Attacker
Attacker
Server
Attacker
Attacker
Attacker
17
Location of Defense Network
Attacker
Attacker
Server
Attacker
Attacker
Attacker
18
Location of Defense Distributed
Attacker
Attacker
Server
Attacker
Attacker
Attacker
19
Why Is the Problem Hard?
Point Defense at Server Point Defense in Internet Distributed Defense near Client
Effectiveness Stops attack at door step. Uplink may still be clogged Stops attack without clogging uplink Stops attack early near sources
Resource Requirement Require huge resources from a single entity/location Require huge resources from single entity Require limited resources from each entity/location
Traffic Available for Attack Detection All traffic since detection at server Partial traffic since detection at various points Partial traffic since detection at various points
Collateral Damage to neighbors Yes No No
Incentive High Medium Poor
Modification Ease High Low Medium (multi points)
20
Why Is the Problem Hard?
Each have their pros cons
Point Defense at Server Point Defense in Internet Distributed Defense near Client
Effectiveness Stops attack at door step. Uplink may still be clogged Stops attack without clogging uplink Stops attack early near sources
Resource Requirement Require huge resources from a single entity/location Require huge resources from single entity Require limited resources from each entity/location
Traffic Available for Attack Detection All traffic since detection at server Partial traffic since detection at various points Partial traffic since detection at various points
Collateral Damage to neighbors Yes No No
Incentive High Medium Poor
Modification Ease High Low Medium (multi points)
21
Why Is the Problem Hard?
Cooperation is most effective
Point Defense at Server Point Defense in Internet Distributed Defense near Client
Effectiveness Stops attack at door step. Uplink may still be clogged Stops attack without clogging uplink Stops attack early near sources
Resource Requirement Require huge resources from a single entity/location Require huge resources from single entity Require limited resources from each entity/location
Traffic Available for Attack Detection All traffic since detection at server Partial traffic since detection at various points Partial traffic since detection at various points
Collateral Damage to neighbors Yes No No
Incentive High Medium Poor
Modification Ease High Low Medium (multi points)
React
Mixed Mechanism
Detection
Deployability Factors
22
Existing Research Visualization

• Deployable Resiliency
• Ease of deployment
• Incentive
• Effectiveness

23
Existing Research
Goal
Size of circle gt Effectiveness
24
Our Contribution
Goal
KUMO
sPoW
Overfort
AI-RON-E
Size of circle gt Effectiveness
Burrows
25
Our Contribution (cont.)
Goal
26
Problem Statement
Deployable DDoS Mitigation

• Practically deployable
• Effective against all DDoS types

How?
27
Approach

• Economic Inefficiency Rectification Framework
• Burrows
• Reference architecture to overcome deployability
  factors
• KUMO
• Resource accumulation economic incentives
• Multi-prong defense based on Burrows
• AI-RON-E
• Client React To Hotspots (Path variety)
• Overfort
• Server React (Auto traceback and punish) and
  Deter (Cleanup)
• sPoW
• Client React To Attacker Mimicry (Urgency
  signaling)
• Server React To Prioritize Connection (Protect
  established conn)

Enhance Deployability
Enhance Deployability
Spoofed/Net-level DDoS Bypass
Spoofed/Net-level DDoS Defense
Non-filterable/Economic DDoS Defense
Spoofed/Net-level DDoS Defense
28
Research in Chronological Order

• Burrows
• Overfort
• AI-RON-E
• sPoW
• KUMO

29
Presentation Format

• Publication info
• Contribution
• Overview
• Conclusion
• Deployable Resiliency

30
Burrows Publication

• Power to the People Securing One-Edge at a Time
• ACM SIGCOMM Large-Scale Attack Defence (LSAD)
  Workshop 2007
• Acceptance Rate (Official 45)
• Based on Masters Thesis

31
Burrows Contribution

• Category Economic Inefficiency Rectification
• Design to uphold deployability economic
  principles
• A guide to design deployable DDoS mechanism

32
Practical Deployment Issues
Deployability Factors
Incentive
Modification Ease
Inability to cooperate Realign economic
incentive (Empower cooperation)
Reliance on indifferent parties Minimize negative
externality (Exclude Insecurity)
Require infrastructure overhaul Protect existing
investment (Modification Ease)
33
Burrows Architecture
Intermediary
Legit
Server
Minimize Negative Externality (Exclude Insecurity)
Attacker
Intermediary
34
Burrows Architecture
Minimize modification (use edge nodes)
Intermediary
Intermediary
Legit
Realign Incentive (Empower cooperation)
Minimize Negative Externality (Exclude Insecurity)
Attacker
Intermediary
Intermediary
Legit
35
Burrows Conclusion

• Intermediary-based architecture
• A design guide for deployable mechanisms
• Our subsequent work is based on Burrows
• Deployable Resiliency
• Addresses economic issues

36
Overfort Publication

• Ovefort Combating DDoS with Peer-to-Peer DDoS
  Puzzle
• IEEE International Parallel and Distributed
  Processing Symposium (IPDPS) Secure Systems and
  Network (SSN) Workshop 2007
• Acceptance rate Unavailable

37
Overfort Contribution

• Category
• Server React (Auto traceback and punish)
• Deter/Prevent (Cleanup)
• Deter/Prevent
• Auto blacklist clusters that have DDoS agents
• Server React
• Quickly segregate bad clusters and snub their
  request for server location
• Defend using cheap virtual resources instead of
  expensive physical resources
• Works even if attackers have more resources

38
Overfort DDoS Puzzle
Protected Server
Total Available Bandwidth
Where to attack?
Volume required to clog?
Connectivity Possible Despite Attacker Having
More Bandwidth
Total Attacker Bandwidth
Zombie PC courtesy of crazy-vincent.com
39
Overfort Gateway (OFG) Module
Auth DNS
PC
Internet
PC
IP A
OFG
stub router
stub router
Local DNS
40
Overfort DDoS Puzzle
Protected Server
Where to attack?
Connectivity Possible Despite Attacker Having
More Bandwidth
Volume required to clog?
OFG
OFG
OFG
OFG
Zombie PC courtesy of crazy-vincent.com
41
Distributed OFG Deployment
Random access channel IP Random access channel
capacity
OFG
OFG
OFG
Internet
OFG
OFG
OFG
OFG
42
Overfort Detection
OFG A -
OFG B -
Auth DNS
OFG Monitor
LDNS B
OFG A
Internet
OFG B
LDNS A
43
Overfort Detection (Cont.)
LDNS A
OFG A -
OFG B -
LDNS B
Auth DNS
OFG Monitor
LDNS B
OFG A
Internet
Cluster
OFG B
LDNS A
44
Observation

• There are 800,000 LDNSes on the Internet
• One LDNS-to-one OFG mapping may not be feasible
• Reduce the quantity of physical OFGs required
• Use of virtual links
• Algorithm to assign LDNSes to virtual links

45
OFG Virtual Links
Virtual Links
IP C
IP D
IP E
IP F
Internet
OFG
OFG
Local DNS
46
Evaluation Goal

• Is it feasible?
• How many virtual links to find all bad LDNSes?
• What parameter value represents Internet?
• NLDNS Total number of LDNSes
• R Ratio of good vs. bad LDNS

47
Number of Virtual Links Required is Linearly
Proportional to Number of LDNS
For LDNS 800,000, R0.9 gt Nadd 120,000
IDs (2 class B IPs)
Total OFG IDs for complete segregation
Physical OFG 120,000/10 12,000 units
Different of good LDNS
As the number of NLDNS increases, the number of
Nadd increases LINEARLY.
Total number of LDNSes
48
Overfort Conclusion

• Delegate security responsibility through
  blacklisting
• Defense against DDoS with less resource
• Deployable Resiliency
• A meager 12,000 physical OFGs to defend against
  DDoS
• Unilaterally deployable by single ISP
• Share blacklist

Feature Checklist
Spoofed/Net-level DDoS 0 (Overfort)
Non-filterable DDoS X
eDDoS X
49
AI-RON-E Publication

• AI-RON-E Prophecy of One-Hop Source Routers
• IEEE Globecom Next Generation Networks (NGN)
  Symposium 2008
• Acceptance rate (Unofficial 36.8)
• http//www.cs.ucsb.edu/almeroth/conf/stats/globe
  com

50
AI-RON-E Contribution

• Category Client React (Path variety)
• Empower clients to route around hotspots
• With minimum CPU, memory, network resource
• With NO change to existing infrastructure

51
Path Congestion
End-host System
Router
52
One-Hop Source Routing (OSR)
Which OSR?
End-host System
One-hop Source Routing (OSR)
Router
53
What Research Has Proved

• OSR is effective for failure masking

OSR Scheme Percentage Failures Masked
Cha et al (Infocomm 06) 77 (intra-domain)
RON (SOSP 01) 60-100
SOSR (OSDI 04 ) 66
Fei et al (Infocomm 06) 61.9
RON-DG (ICC 07) 60
Randomly select 4 from 39 end-hosts
54
Path Length/Latency
Path length 7 hops
End-host System
Router
Path length 6 hops
55
Low Failure Mask Rate
Prophecy of OSR Mobilize all routers as OSR
End-host System
Success 7/12
Router
Success 1/3
56
Smart OSR Selection Algorithm

• Choose good OSR without
• Excessive active network probes
• Storing entire Internet topology
• Complex resource-consuming processing

57
Result I Shorter Indirect Paths
indirect/direct 1.6
indirect/direct 2.3
30 improvement
58
Result II Failure Masking Rate
69
60
SOSR 66 7-day, 3153 dst
59
What About Deployability?

• Ease of Modification (Near Future)
• AI-RON-E code is similar to existing source
  routing code
• No Modification
• Employ source IP spoofing

60
AI-RON-E Conclusion

• Empowers client to react to hotspots
• Select OSR with lightweight algorithm
• Deployable Resiliency
• Mobilize all existing routers for OSR with no
  change

Feature Checklist
Spoofed/Net-level DDoS O (Overfort, AI-RON-E)
Non-filterable DDoS X
eDDoS X
Server React vs. Client React
61
KUMO Publication

• To be published in 2010
• Draft 15 pages

62
KUMO Contribution

• Category Economic Inefficiency Rectification
• Harness intermediaries/resource
• Can use any existing systems as intermediaries
• Intermediaries unaware of KUMO (No modification)
• Lots of intermediaries
• Widespread over the Internet
• Future intermediaries
• Pay-as-you-use defense
• Over-provisioned resource utilized for defense

63
Intermediary-Based Architecture
Internet
How to obtain intermediaries?
I3, Phalanx, SOS
Hidden
Server
Client
Enables traffic reception control
Attacker
64
KUMO Framework
Write-once Code extension How to send/receive
data
Incentive Accounting
Ease
Resilient
Internet
CDN
KUMO zero-install client-side
IRC
KUMO server-side
Forums
Web2.0
Server
Client
Unmodified
Unmodified
Future X
Pay-As-You-Use DDoS Mitigation
Unmodified
65
Data Transfer Time (User Experience)
decent speed h-forum, h-flickr, h-S3
good speed IRC, I3 lt 10kB
good speed I3 lt 100kB
66
KUMO Conclusion

• Harness distributed Internet resource for defense
• Deployable Resiliency
• No change to client, server and Internet resource
• Pay-as-you-use

Enhance resource for DDoS defense (KUMO)
Feature Checklist
Spoofed/Net-level DDoS O (Overfort, AI-RON-E)
Non-filterable DDoS X
eDDoS X
67
sPoW Publication

• sPoW On-Demand Cloud-Based eDDoS Mitigation
  Mechanism
• IEEE/IFIP HotDep Workshop 2009
• Acceptance rate (Official 37)

68
sPoW Contribution

• Category
• Client Reaction (Signal urgency)
• Server Reaction (Prioritize connections)
• Client/Server React
• Protect against spoofed/net-level DDoS
• Use cloud as intermediary
• Protect against non-filterable DDoS
• Use own resource to generate stronger signal and
  attain higher priority
• Protect against economic DDoS
• Self-verification PoW
• Without requiring changes to intermediaries

69
sPoW KUMO with Cloud
Too powerful to be attacked
Traffic reception control
Amazon EC2 Cloud Intermediary
Trusted Intermediaries Low Cost (Pay-As-You-Use)
Spoofed/Net-level Defense
Huge resource Few Intermediaries gt Tunnel setup
ease gt Unreachable private IP
Server
Client
Traffic reception control
Too powerful to be attacked
Google AppEngine Intermediary
70
Non-filterable DDoS
Too powerful to be attacked
Amazon EC2 Cloud Intermediary
Non-filterable DDoS
Server
Legit
Where is the server?
Too powerful to be attacked
Google AppEngine Intermediary
Attacker
71
Proof-of-Work (PoW)
PoW Verifier
Amazon EC2 Cloud Intermediary
5 reqs/sec
4
Server
Legit
Puzzle distributor
3
3
3
3
3
3
Number indicates puzzle level
4
Attacker
2
1
72
PoW (cont.)
PoW Verifier
Amazon EC2 Cloud Intermediary
3
4
3
5 reqs/sec
3
3
3
Server
Legit
Puzzle distributor
3
4
Attacker
2
1
73
PoW (cont.)
PoW Verifier
Forward highest puzzle with correct solution
Amazon EC2 Cloud Intermediary
3
5 reqs/sec
3
4
3
3
3
Server
Legit
Puzzle distributor
3
4
Attacker
2
1
74
Why Existing Mechanism Cant Use Cloud eDDoS
PoW Verifier
Amazon EC2 Cloud Intermediary
5 reqs/sec
4
Server
Attacker expend no resources to solve puzzles
Legit
Puzzle distributor
?
?
?
3
?
4
Attacker
2
1
75
Why Existing Mechanism Cant Use Cloud eDDoS
PoW Verifier
Amazon EC2 Cloud Intermediary
4

?
5 reqs/sec
?
?
?
Server
Legit
Puzzle distributor
3
4
Attacker
2
1
76
Self-Verifying PoW (sPoW)
Server Channel IDs (Amazon SQS)
a
Channel is ephemeral
b
3
Attacker
c
Channel C
1
d

1. No verifier
2. Verified traffic

Server
Legit
2
c
b
Puzzle Distributor
d
c
a
77
sPoW Result

• Prioritize traffic based on the resources
  expended by origin
• Reduce processing on intermediary/server
• Deployable Resiliency
• Use existing cloud without modification
• Pay-as-you-use service

Feature Checklist
Spoofed/Net-level DDoS O (Overfort, AI-RON-E, KUMO, sPoW)
Non-filterable DDoS O (sPoW PoW)
eDDoS O (sPoW Self-verifying)
78
Deployable Multi-layer DDoS Defense
Too powerful to be attacked
KUMO server-side (no app modification)
Cloud Intermediary
Internet
Server
AI-RON-E oracle

1. No Internet component
2. Component quantity few/replicable
3. Component location aligned with incentive

AI-RON-E client
KUMO client-side (zero install)
OFG Monitor
sPoW Puzzle Distributor
Legit
Attacker
Attacker
Auth DNS
79
Our Contribution
Goal
KUMO
sPoW
Overfort
AI-RON-E
Size of circle gt Effectiveness
Burrows
80
Future Work

• Tune KUMO Ruby network stack
• Better performance
• Port network stack to C and Java
• Performance and support for zero-install client
• Deploy service using Amazon Web Services
• Design new cloud intermediaries
• Larger data packet transfer
• Faster transfer
• Cloud firewall-friendly
• Gather feedback and attract interest in
  conferences
• Usenix HotCloud, ACM SOCC
• Work with ISPs/cloud-providers to test
  deployability

81
Unique Among Existing Research

• Overfort
• Defense with less physical resources
• Traceback and blacklist
• AI-RON-E
• Mobilize all Internet routers
• KUMO
• Intermediary resource harness
• sPoW
• Defense against eDDoS
• Make the cloud platforms responsible

82

• Thank you very much for listening

83
References

• Abadi, M., Burrows, M., Manasse, M. Wobber, T.
  (2003). Moderately Hard, Memory-bound Functions.
  In Network and Distributed System Security
  Symposium (NDSS).
• Abley, J. Lindqvist, K. (2006). RFC 4786
  Operation of Anycast Services (http//www.ietf.org
  /rfc/rfc4786.txt).
• Akamai Technologies (2008). State of the Internet
  Quarterly Reports (http//www.akamai.com/stateofth
  einternet/).
• Akamai Technologies (2009). Akamai Technologies
  (http//www.akamai.com/).
• Amazon Cloud Computing Forum (2009). Unaddressed
  DDoS Concernsin Amazons Cloud (http//developer.a
  mazonwebservices.com/connect/search.jspa?qDDoS).
  
• Amazon Web Services (2009a). Amazon Simple Queue
  Services (SQS) (http//aws.amazon.com/sqs/).
• Amazon Web Services (2009b). Amazon Simple
  Storage Services (S3) (http//aws.amazon.com/s3/).
  
• Amazon Web Services (2009c). Amazons Web
  Services Case Studies (http//aws.amazon.com/solut
  ions/case-studies/).
• Amazon Web Services (2009d). Elastic Compute
  Cloud (EC2) (http//aws.amazon.com/ec2/).
• American Registry for Internet Numbers (ARIN)
  (2009). ARIN IPv4 Depletion Notice
  (https//www.arin.net/knowledge/about_resources/ce
  o_letter.pdf).
• Andersen, D. (2003). Mayday Distributed
  Filtering for Internet Services. In USENIX
  Symposia on Internet Technologies and Systems
  (USITS).
• Andersen, D., Balakrishnan, H., Kaashoek, F.
  Morris, R. (2001). Resilient Overlay Networks. In
  ACM Symposium on Operating Systems
  Principle(SOSP).
• Anderson, T., Roscoe, T. Wetherall, D. (2002).
  Preventing Internet Denial-of-Service with
  Capabilities. In ACM Hot Topics in Networks
  (Hotnets).
• Anjum, F.M. (2004). TCP Algorithms and Multiple
  Paths Considerations for the Future of the
  Internet.
• Arbor Networks (2005). Annual Infrastructure
  Security Report (http//www.arbornetworks.com/repo
  rt).
• Arbor Networks (2009). Arbor PeakFlow TMS
  (http//www.arbornetworks.com/peakflowsp).
• Arends, R., Austein, R., Larson, M., Massey, D.
  Rose, S. (2005). Resource Records for DNS
  Security Extensions (http//www.ietf.org/rfc/rfc40
  34.txt).
• Argyraki, K. Cheriton, D.R. (2005). Active
  Internet Traffic Filtering Real-time Response to
  Denial-of-Service Attacks. In USENIX Annual
  Technical Conference (ATC).
• Aura, T., Nikander, P. Leiwo, J. (2000).
  DOS-resistant Authentication with Client Puzzles.

84
References (cont.)

• Casado, M., Akella, A., Cao, P., Provos, N.
  Shenker, S. (2006). Cookies Along
  Trust-Boundaries (CAT) Accurate and Deployable
  Flood Protection. In USENIX Steps to Reducing
  Unwanted Traffic on the Internet (SRUTI).
• ccNSO (2009). DNSSec Survey Report 2009. ICANN.
• Cha, M., Moon, S., Park, C.D. Shaikh, A.
  (2006). Placing Relay Nodesfor Intra-Domain Path
  Diversity. In IEEE INFOCOM.
• Chen, X., Wang, H., Ren, S. Zhang, X. (2006).
  DNScup Strong Cache Consistency Protocol for
  DNS. In IEEE International Conference for
  Distributed Computing Systems(ICDCS).
• Cisco Networks (2009a). Cisco Anomaly Guard
  (http//www.cisco.com/en/US/products/ps6235/index.
  html).
• Cisco Networks (2009b). Understanding Unicast
  Reverse Path Forwarding (http//www.cisco.com/web/
  about/security/intelligence/unicast-rpf.html).
• Computer Emergency Response Team (CERT) (2009).
  Build Security In (https//buildsecurityin.us-cert
  .gov/daisy/bsi/home.html).
• Computer Security Institute (2008). CSI Computer
  Crime and Security Report (http//www.gocsi.com/).
  
• Cook, D.L., Morein, W.G., Keromytis, A.D., Misra,
  V. Rubenstein, D. (2003). WebSOS Protecting
  Web Servers From DDoS Attacks. In IEEE
  International Conference on Network (ICON).
• Dagon, D., Zou, C. Lee, W. (2006). Modeling
  Botnet Propagation Using Time Zones. In Network
  and Distributed System Security Symposium (NDSS).
• Dean, D. Stubblefield, A. (2001). Using Client
  Puzzles to Protect TLS. In USENIX Security
  Symposium.
• DETERlab (2000). DETERlab Testbed
  (http//www.isi.edu/deter/).
• Dierks, T. Rescorla, E. (2008). The Transport
  Layer Security (TLS) Protocol v1.2
  (http//www.ietf.org/rfc/rfc5246.txt).
• Dingledine, R. Nick (2004). Tor The
  Second-Generation Onion Router. In USENIX
  Security Symposium.
• Dixon, C., Anderson, T. Krishnamurthy, A.
  (2008). Phalanx Withstanding Multimillion-Node
  Botnets. In USENIX Network Systems Design and
  Implementation (NSDI).
• Dwork, C. Naor, M. (1993). Pricing via
  Processing or Combatting Junk Mail. In CRYPTO.
• Dwork, C., Goldberg, A. Naor, M. (2003).
  OnMemory-bound Functions for Fighting Spam. In
  CRYPTO.
• Fei, T., Tao, S., Gao, L. Guerin, R. (2006).
  How to Select a Good Alternate Path in Large
  Peer-to-Peer Systems. In IEEE INFOCOM.
• Ferguson, D. Senie, P. (2000). RFC 2827
  Network Ingress Filtering (http//www.ietf.org/rfc
  /rfc2827.txt).

85
References (cont.)

• Google (2009). Google App Engine
  (http//code.google.com/appengine/).
• Greene, B.R., Morrow, C. Gemberling, B. (2001).
  ISP Security Real World Techniques II. North
  America Network Operators Group (NANOG).
• Greenhalgh, A., Handley, M. Huici, F. (2005).
  Using Routing and Tunneling to Combat DoS
  Attacks. In USENIX Steps to Reducing Unwanted
  Traffic on the Internet (SRUTI).
• Gummadi, K.P., Madhyastha, H.V., Gribble, S.D.,
  Levy, H.M. Wetherall, D. (2004). Improving the
  Reliability of Internet Paths with One-hop Source
  Routing. In USENIX Operating Systems Design and
  Implementation (OSDI).
• ha.ckers.org (2009). Slow Loris HTTP DoS
  (http//ha.ckers.org/slowloris/).
• Haddad, I. (2001). Open-Source Web Servers
  Performance on a Carrier-Class Linux Platform
  (http//www.linuxjournal.com/article/4752). 123
• Hoff, C. (2008). Cloud Computing Security From
  DDoS (http//www.rationalsurvivability.com/blog/?p
  66).
• Hsieh, H.Y. Sivakumar, R. (2002). A Transport
  Layer Approach for Achieving Aggregate Bandwidths
  On Multi-Homed Mobile Hosts. In ACM Mobicom.
• Huston, G. (1999). Interconnection, Peering, and
  Settlements. In Internet Society INET.
• Intelliguard (2009). Intelliguard dps
  (http//www.intelliguardit.net/Docs/Whitepapers/In
  telliGuardIT_Inline_Deployment_Whitepaper.pdf).
• InternetWorld Stats (2009). Usage and Population
  Statistics (http//www.internetworldstats.com/stat
  s.htm).
• Jin, C., Wang, H. Shin, K.G. (2003). Hop-Count
  Filtering An Effective Defense Against Spoofed
  DDoS Traffic. In ACM Computer and Communications
  Security (CCS).
• Kent, S., Lynn, C. Seo, K. (2000). Secure
  Border Gateway Protocol (SBGP). In IEEE Journal
  on Selected Areas of Communication.
• Keromytis, A., Misra, V. Rubenstein, D. (2002).
  SOS Secure Overlay Services. In ACM Special
  Interest Group in Communications (SIGCOMM).
• Khor, S.H. Nakao, A. (2008a). AI-RON-E The
  Prophecy of One-hopSource Routers. In IEEE
  Globecom Next Generation Networks Symposium.
• Khor, S.H. Nakao, A. (2008b).
  OverfortCombating DDoS with Peer-to-Peer DDoS
  Puzzle. In IEEE Secure Systems and Nework
  Workshop.
• Khor, S.H. Nakao, A. (2009). sPoW On-Demand
  Cloud-based eDDoS Mitigation Mechanism. In
  IEEE/IFIP Hot Topics in Dependency
  WorkShop(HOTDEP).
• Khor, S.H., Christin, N., Wong, T. Nakao, A.
  (2007). Power to the People Securing the
  Internet One Edge at a Time. In ACM Large Scale
  Attack and Defense (LSAD).
• Kuzmanovic, A. Knightly, E.W. (2003). Low-Rate
  TCP-Targeted Denial of Service Attacks. In ACM
  Special Interest Group in Communications(SIGCOMM).
  

86
References (cont.)

• Madhyastha, H., Isdal, T., Piatek, M., Dixon, C.,
  Anderson, T., Krishnamurthy, A. Venkataramani,
  A. (2006). iPlane An Information
• Plane for Distributed Services. In USENIX
  Operating System Design and Implementation
  (OSDI).
• Mahajan, R., Bellovin, S.M., Floyd, S.,
  Ioannidis, J., Paxson, V. Shenker, S. (2002).
  Controlling High Bandwidth Aggregates in the
  Network. ACM Computer Communication Review (CCR).
• Mahimkar, A., Dange, J., Shmatikov, V., Vin, H.
  Zhang, Y. (2007). dFence Transparent
  Network-based Denial of Service Mitigation. In
  USENIX Network Systems Design and Implementation
  (NSDI).
• Markopoulou, A., Iannaccone, G., Bhattacharyya,
  S., nee Chuah, C. Diot, C. (2004).
  Characterization of Failures in an IP Backbone.
  In IEEE INFOCOM.
• Massachusetts Institute of Technology (2009).
  Spoofer Project Current State of IP Spoofing
  (http//spoofer.csail.mit.edu/summary.php).
• Mirkovic, J. Reiher, P. (2004). A Taxonomy of
  DDoS Attack and DDoS Defense Mechanism. In ACM
  Computer Communications Review (CCR).
• Mirkovic, J., Prier, G. Reiher, P. (2002).
  Attacking DDoS at the Source.In IEEE
  International Conference on Network Protocols
  (ICNP).
• Mirkovic, J., Robinson, M. Reiher, P. (2003).
  Alliance formation for DDoS defense. In Applied
  Computer Security Associates (ACSA) New Security
  Paradigms Workshop (NSPW).
• Mirkovic, J., Fahmy, S., Reiher, P. Thomas, R.
  (2009). How to Test DDoS Defenses. In
  Cybersecurity Applications Technology
  Conference For Homeland Security (CATCH).
• Mockapetris, P. (1987). Domain Names
  Implementation and Specification
  (http//www.ietf.org/rfc/rfc1035.txt).
• Moore, D., Voelker, G.M. Savage, S. (2001).
  Inferring Internet Denial-of-Service Activity. In
  USENIX Security Symposium.
• Moore, D., Paxson, V., Savage, S., Shannon, C.,
  Staniford, S. Weaver, N. (2003). Inside the
  Slammer Worm. IEEE Security and Privacy Magazine.
• National Institute of Science and Technology
  (NIST) (1993). Data Encryption Standard
  (http//csrc.nist.gov/publications/fips/fips46-3/f
  ips46-3.pdf).
• Oikarinen, J. Reed, D. (1993). RFC 1459
  Internet Relay Chat (http//www.ietf.org/rfc/rfc14
  59.txt).
• OnlineMQ (2009). OnlineMQ (http//www.onlinemq.com
  ).
• Park, K. Lee, H. (2001). On the Effectiveness
  of Route-based Packet Filtering for distributed
  DoS Attack Prevention in Power-Law Internets. In
  ACM Special Interest Group for Communications
  (SIGCOMM).
• Parno, B., Wendlandt, D., Shi, E., Perrig, A.,
  Maggs, B. Hu, Y.C. (2007). Portcullis
  Protecting Connection Setup from
  Denial-of-Capability Attacks. In ACM Special
  Interest Group for Communications (SIGCOMM).
• Planet Lab (2002). Planet Lab Consortium
  (http//www.planet-lab.org/consortium).

87
References (cont.)

• Rajab, M.A., Zarfoss, J., Monrose, F. Terzis,
  A. (2007). My Botnet is Bigger than Yours. In
  USENIX Hot Topics in Botnets (HOTBOT).
• Ramasubramanian, V. Sirer, E.G. (2004). The
  Design and Implementation of a Next Generation
  Name Service for the Internet. In ACM Special
  Interest Group for Communications (SIGCOMM).
• Rekhter, Y. Li, T. (1995). RFC 1771 Border
  Gateway Protocol (BGP) (http//www.ietf.org/rfc/rf
  c1771.txt).
• Rhea, S., Godfrey, B., B.Karp, Kubiatowicz, J.,
  Ratnasamy, S. Shenker, S. (2005). OpenDHT A
  Public DHT Service and its Uses. In ACM Special
  Interest Group for Communications (SIGCOMM).
• Rose, C. Gordon, J. (2003). Internet Security
  and the Tragedy of the Commons. In Journal of
  Business and Economics Research.
• RouteViews (2005). University of Oregon Route
  Views Project (http//www.routeviews.org/).
• Rowland, C. (1996). Covert Channels in the TCP/IP
  Suite. In First Monday, Peer Reviewed Journal on
  the Internet.
• sacrine (2009). Sil v1.0 - A tiny banner grabber
  (http//www.netric.org).
• Saltzer, J. Schroeder, M. (1975). The
  protection of information in computer systems.
• Savage, S., Anderson, T., Aggarwal, A., Becker,
  D., Cardwell, N., Collins, A., Hoffman, E.,
  Snell, J., Voelker, A.V.G. Zahorjan, J. (1999).
  Detour a Case for Informed Internet Routing and
  Transport. In IEEE Micro.
• Savage, S., Wetherall, D., Karlin, A. Anderson,
  T. (2000). Practical Network Support for IP
  Traceback. In ACM Special Interest Group for
  Communications (SIGCOMM).
• Shapiro, C. Varian, H. (1998). Networks and
  Positive Feedbacks
• Shi, E., Stoica, I., Andersen, D. Perrig, A.
  (2006). OverDoSe A Generic DDos Protection
  Service Using an Overlay Network.
• Snoeren, A.C., Partridge, C., Sanchez, L.A.,
  Jones, C.E., Tchakountio, F., Schwartz, B., Kent,
  S.T. Strayer, W.T. (2002). Single-packet IP
  traceback. In IEEE/ACM Transactions on Networking
  (TON).
• Spring, N., Mahajan, R., Wetherall, D.
  Anderson, T. (2004). Measuring ISP Topologies
  with Rocketfuel. IEEE/ACM Transactions in
  Networking.
• Stoica, I., Adkins, D., Zhuang, S., Shenker, S.
  Surana, S. (2002). Internet Indirection
  Infrastructure. In ACM Special Interest Group for
  Communications (SIGCOMM).
• Stone, R. (2000). CenterTrack an IP overlay
  network for tracking DoS floods. In USENIX
  Security Symposium.
• Subramaniam, K. (2008). Cloud Computing Risks
  eDoS (http//www.cloudave.com/link/cloud-computing
  -risks-edos).
• Sun, H., Lui, J.C.S. Yau, D.K.Y. (2006).
  Distributed Mechanism in Detecting and Defending
  Against the Low-rate TCP Attack. Computer
  Networks Journal .

88
References (cont.)

• Symantec (2008). Symantec report on the
  underground economy (http//eval.symantec.com/mktg
  info/enterprise/white_papers/b-whitepaper_undergro
  und_economy_report_11-2008-14525717.en-us.pdf.).
• T. Ylonen and C. Lonvick (2006). The Secure Shell
  (SSH) Authentication Protocol (http//www.ietf.org
  /rfc/rfc4252.txt).
• Team CYMRU (2009). CYMRU IP to ASN Service
  (http//www.team-cymru.org/Services/ip-to-asn.html
  ).
• Teixeira, R., Marzullo, K., Savage, S. Voelker,
  G.M. (2003). In search of path diversity in ISP
  networks. In ACM Internet Measurement
  Conference(IMC).
• Thomas, R. Martin, J. (2006). Underground
  Economy Priceless. In USENIX login.
• Traceroute (1987). Traceroute (http//www.openbsd.
  org/cgi-bin/man.cgi?querytraceroute).
• Turner, J. (2004). Virtualizing the Net - a
  strategy for enabling network innovation Keynote
  2. In IEEE Symposium on High Performance
  Interconnects.
• von Ahm, L., Blum, M., Hooper, N. Langford, J.
  (2004). CAPTCHAS Using Hard AI Problems for
  Security. In EuroCrypt .
• Walfish, M., Vutukuru, M., Balakrishnan, H.,
  Karger, D. Shenker, S. (2006). Ddos defense by
  offense. In ACM Special Interest Group for
  Communications (SIGCOMM).
• Wang, J., Liu, X. Chien, A.A. (2005). Empirical
  Study of Tolerating Denial-of-Service Attacks
  with a Proxy Network. In USENIX Security
  Symposium.
• Wang, L., Park, K.S., Pang, R., Pai, V.
  Peterson, L. (2004). Reliability and Security in
  the CoDeeN Content Distribution Network. In
  USENIX Annual Technical Conference (ATC).
• Wang, X. Reiter, M.K. (2003). Defending Against
  Denial-of-Service Attacks with Puzzle Auctions.
  In IEEE Symposium on Security and Privacy.
• White, B., Lepreau, J., Stoller, L., Ricci, R.,
  Guruprasad, S., Newbold, M., Hibler, M., Barb, C.
  Joglekar, A. (2002). An Integrated Experimental
  Environment for Distributed Systems and Networks.
  In USENIX Operating Systems Design and
  Implementation (OSDI).
• Yaar, A., Perrig, A. Song, D. (2004). SIFF A
  Stateless Internet Flow Filter to Mitigate DDoS
  Flooding Attacks. In IEEE Symposium on Security
  and Privacy.
• YAML (2009). Yet Another Mark-up Language
  (http//www.yaml.org/spec/1.2/spec.html).
• Yang, X. Wetherall, D. (2006). Source
  Selectable Path Diversity via Routing
  Deflections. In ACM Special Interest Group for
  Communications (SIGCOMM).
• Yang, X., Wetherall, D. Anderson, T. (2005). A
  DoS-limiting Network Architecture. In ACM Special
  Interest Group for Communications (SIGCOMM).
• Zhang, Z., Zhang, Y., Hu, Y.C. Mao, Z.M.
  (2007). Practical Defenses Against BGP Prefix
  Hijacking. In ACM CoNEXT.

89
My Toil

• Simulation code for Overfort
• Simulation for trace-back and punish algorithm
• Input parameters 2
• Operational parameters 5 (Number of requesters,
  Good vs. bad ratio, Request inter-arrival time)
• Output statistics 2
• AI-RON-E
• Components
• Oracle code (Respond to traceroute)
• Client code (Traceroute to target, Consult
  oracle, Determine failure-mask ability)
• Covert channel data transmission code (IP
  spoofing)
• Experiment deployment on Planet-Lab nodes
• 100 oracles, 15 clients, 25 targets 375 paths

Indirection Code
90
My Toil (cont.)

• KUMO
• KUMO network stack (Ruby and Java (unmaintained))
• Transmission/Reception over multipath
• Fragmentation/Reassembly
• Lost packet request/retransmission
• Unreliable channel tracking
• Plug-in support
• Plug-ins
• IRC, forum, Flickr (Web 2.0), Amazons S3, I3,
  direct, hybrid)
• Experiment deployment on Planet-Lab nodes
• Bullet time concept to enable experiments with
  more nodes
• Transfer 5 file sizes over 9 intermediary types
  by 20 nodes 900 runs
• Transfer 5 file sizes over 2 intermediary types
  by 10 nodes over 4 DoS conditions 400 runs

Multipath Capability
91
My Toil (cont.)

• sPoW
• Server-side
• Intermediary listener
• Connection manager
• Puzzle generator
• Puzzle distributor
• Client-side
• Puzzle requester/resolver
• Simulation/Experiment (In Progress)
• How connection establishment time under DoS is
  affected by
• Number of server connections
• Puzzle level of attacker (fixed)
• Puzzle level
• Number of attackers 3 times (60), 10 times
  (200), and 20 times (400)
• Algorithm parameter, T (puzzle resolution/request
  calculation period)
• 3.5 papers