See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/233916411

Mitigating Economic Denial of Sustainability (EDoS) in Cloud Computing

using In-Cloud Scrubber Service

Conference Paper · November 2012

DOI: 10.1109/CICN.2012.149

CITATIONS READS

63 558

6 authors, including:

Madarapu Naresh Kumar Sujatha Pothula

National Informatics Centre Pondicherry University
9 PUBLICATIONS   82 CITATIONS    53 PUBLICATIONS   197 CITATIONS   

SEE PROFILE SEE PROFILE

Vamshi Kalva Rohit Nagori

2 PUBLICATIONS   63 CITATIONS   
Pondicherry University
1 PUBLICATION   63 CITATIONS   
SEE PROFILE
SEE PROFILE

All content following this page was uploaded by Madarapu Naresh Kumar on 01 June 2014.

The user has requested enhancement of the downloaded file.

 2012 Fourth International Conference on Computational Intelligence and Communication Networks

Mitigating Economic Denial of Sustainability (EDoS) in Cloud Computing using

In-Cloud Scrubber Service

Madarapu Naresh Kumar1, P Sujatha2, Vamshi Kalva3, Rohit Nagori4, Anil Kumar Katukojwala5 and Mukesh
kumar6
1
National Informatics Centre (NIC) under IVFRT Project, New Delhi, INDIA
2
School of Engineering and Technology, Department of Computer Science, Pondicherry University, INDIA,
3
Indigo Technologies, Greater Chicago, Illinois, US.
4
Quantitative Research Group at Evalueserve, Gurgaon, INDIA.
5
Software Engineer, iGate at Pune, INDIA.
6
Prasad Institute of Technology, Department of Computer Science, Uttar Pradesh Technical University (UPTU), INDIA
e-mail: madarapu.naresh@gmail.com; spothula@gmail.com; vamshi53@gmail.com
rohitnagori.cse@gmail.com; anilcsd@gmail.com; prof.mkg@gmail.com

Abstract— Cloud computing is not a new technology; it is a
new way of delivering computing resources. Elastic cloud
computing enables services to be deployed and accessed
globally on demand with little maintenance by providing
QoS as per service level agreement (SLA) of customer. The
Cloud-based DDoS attacks or outside DDoS attacks can
make ostensibly legitimate requests for a service to generate
an economic Distributed Denial of Service (eDDoS) -- where
the elastic nature of the cloud allows scaling of service
beyond the economic means of the purveyor to pay their
cloud-based service bills which leads to Economic Denial of
Sustainability (EDoS). Attacks mimicking legitimate users
are on the climb. For cloud computing to remain attractive,
the DDoS threat is to be addressed before it triggers the
billing mechanism. This problem can be addressed by using
reactive/on-demand in-cloud eDDoS mitigation service
(scrubber Service) for mitigating the application-layer and
network-layer DDOS attacks with the help of an efficient
client-puzzle approach.
Index Terms— Cloud computing, Economic Denial of
Service (EDoS), Mitigation, Distributed Denial of Service
(DDoS), cryptographic puzzles.
I. INTRODUCTION
In the age of virtualization and cloud, old world
denial-of-service attacks have become more targeted,
causing new worries. Cloud computing has created a lot of
buzz lately and many companies have started venturing in
this domain and providing cloud-based services. Likewise,
most companies have also started moving some of their IT
operations on to the Cloud. Cloud computing has become
the latest craze in a series of popular industry terms.
Elastic cloud computing is an attractive proposition; It
offers convenience in setup, on-demand capacity and a
highly dependable computing platform while requiring
little maintenance. These value propositions have spurred
many businesses to adopt cloud computing technology.
With cloud computing, companies can scale up to
massive capacities in an instant without having to invest in
new infrastructure, train new personnel, or license new
software. Cloud computing is of particular benefit to small
and medium-sized businesses who wish to completely
outsource their data-center infrastructure, or large
companies who wish to get peak load capacity without
incurring the higher cost of building larger data centers
internally. In both instances, service consumers use what
they need on the Internet and pay only for what they use.
The cloud computing model causing a shift from DDoS to
EDoS (Economic Denial of Sustainability).In an EDDoS,
the elasticity of the cloud and surplus of available resources
might be used in such a way that large botnets generating
seemingly legitimate "targeted" requests for service
causing the victim to cloudburst in order to keep pace with
the scale of the requests. Even though the victim can
sustain business operations, the cost of doing so may be so
exorbitantly expensive that to do so threatens economic
sustainability i.e., the elastic property of the infrastructure
allows scaling of service beyond the economic means of the
vendor to pay their cloud-based service bills.
Distributed Denial of Service (DDoS) attacks target
web sites, hosted applications or network infrastructures by
absorbing all available bandwidth and disrupting access
for legitimate customers and partners. DDoS attacks can
bring mission critical systems and business operations to a
halt, resulting in lost revenue opportunities, decreased
productivity or damage to your reputation [2]. As
cloud-based eDDoS mitigation mechanism itself is
susceptible to eDDoS, it is imperative to drop eDDoS
traffic before it triggers the billing mechanism [1]. For
cloud computing to remain attractive, the EDDoS threat is
to be addressed. This can be done possibly by dropping
EDDoS traffic before it triggers the billing mechanism.
Hence, the application-layer and network-layer DDOS
attacks are to be mitigated.
The automation of attacks, spoofing and the rise in the
number of infected clients available as well as the ease with
which HTTP based botnets can be created have all
contributed to the evolution in sophistication of DDoS
attacks. Most existing distributed denial-of-service
(DDoS) mitigation proposals are reactive in nature, i.e.,
they are deployed to limit the damage caused by attacks
after they are detected. Hence, we advocate proactive
mechanisms that are ready to defend against DDoS attacks
before they happen. Distributed denial-of service is a grave
problem that requires a complex solution.
The rest of the paper organized as follows: section II
describes the background and related works. Section III
describes the case study. Section IV describes Service
Level Agreement. Section V describes the proposed work
and Section VI concludes the paper.

978-0-7695-4850-0/12 $26.00 © 2012 IEEE 535

DOI 10.1109/CICN.2012.149
 II. BACKGROUND AND RELATED WORKS
A. Mitigation Schemes
In general, there are 2 basic mitigation schemes for
defending DDoS attacks, namely reactive and proactive.
Reactive mitigation strategies often proceed in 3
phases: In first phase, distributed monitoring components
try to detect on-going DDoS attacks. Once an attack is
detected, the detector triggers the second phase that aims at
locating the attack sources. In the third phase,
countermeasures are deployed to mitigate the attacks.
Proactive Mitigation Strategies intend to reduce the
possibility of successful DDoS attacks by taking
appropriate provisions prior to attacks.
Ingress filtering [3] rejects packets with a spoofed
source address at the ingress of a network. As spoofed
source addresses are used in several attacks, this approach
when put into widespread operation renders many attacks
inefficient. Performing ingress filtering puts a
management burden on ISPs because they must keep all
filtering rules up to date and defective rules will disgruntle
their customers.
Secure overlay networks such as SOS [4] and Mayday
[5] require each communicating user of a group to
pre-establish a trust relationship with the other group
members. Hence user may be required to participate in
many groups. As management of many trust relationships
is costly and potentially large amount of traffic is routed
among overlay nodes, overlay-based proactive solutions
are not adequate for communication with popular web
servers (e.g., yahoo, Google, ebay, etc)), which include
millions of communicating hosts.
PRIMED is an Community-of-Interest-Based DDoS
Mitigation technique [7] in which a bad communities of
interest (COIs) is a set of network entities that previously
engaged in unwanted behavior, whereas a good COI
contains network entities that participated in legitimate
communication with a particular destination (host or stub
network). They combined these good and bad COIs with
destination-specific policies to proactively restrict
any-to-any communication in an attempt to predictively
mitigate against upcoming DDoS attacks. In particular
PRIMED may be ineffective against reflector attacks that
abuse different reflectors at different times. Attackers will
inevitably try to game on this system, e.g., by attempting to
pollute good and bad COIs and by circumventing simple
heuristics using flash crowd style attacks.
A new scheme for filtering spoofed packets (DDOS
attack) is proposed in [8], which is a combination of path
fingerprint and client puzzle concepts. A unique
fingerprint is embedded in each IP packet this represents
the route a packet has traversed. The server maintains a
mapping table which contains the client IP address and its
corresponding fingerprint. The client puzzle is being
placed in ingress router. For each request, the puzzle issuer
provides a puzzle which the source has to solve.
A Puzzle-based approach is being designed for the
bandwidth-exhaustion attacks [13]. This puzzle
mechanism permits routers to cooperatively impose and
check puzzles; thereby it will effectively defend networks
536
from flooding attacks without relying on the formulation of
attack signatures to filter traffic.
Overlay networks have recently been proposed as a
proactive approach to defend against DoS attacks [9], [5].
Overlay networks introduce a system with a protected
internal network that only allows approved traffic to enter.
To protect the resources of the victim, it is placed inside
this protected internal network. Filtering is performed at
the edge of the protected network so malicious users cannot
enter. When a packet reaches the protected network, it is
routed through a series of routers until it reaches its final
destination. This process is referred to as overlay routing.
The identities of some of the routers within the network are
hidden so they cannot be targeted unless they enter at the
network edge. To enter the network edge, decisions are
made based on the credibility of the client.
Lakshminarayan et al. identified weaknesses of overlay
networks by stating that they assume that the list of clients
are known in advance and that it does not scale very well to
the current Internet setting [10]. This certainly holds true,
because it is very difficult to determine if the client in
question is malicious.
B. Difference between DDoS and eDDoS
The DDoS attacks are the Class of attacks on targets,
which exhaust target resources resulting in unavailability,
thereby denying service to other valid users. The DDoS
attack will stop the legitimate user from gaining access to
the resources or it causes the network and server
bottlenecks as shown in Fig. 1.
Fig. 1. Distributed Denial of Service (DDoS)
The eDDoS (economic Distributed Denial of Service)
in cloud is due to the DDoS attack, where the service to the
legitimate user is never restricted also server and network
are not target of attack, as shown in Fig. 2. But the service
provider who is using cloud will incur a debilitating bill by
using highly elastic (auto-Scaling) capacity to unwittingly
serve a large amount of undesired traffic in order to
maintain the QoS as per the SLA. This leads to Economic
Denial of Sustainability (EDoS). Hence it is necessary to
drop the DDoS before the billing mechanism starts for the
service provider.
Fig. 2. eDDoS (Economic Distributed Denial of Service)
III. CASE STUDY
Toronto based Enomaly Inc. has defined ‘Infinite
Capacity in Cloud Computing’ as [6] follows:
“Amazon EC2 (Elastic Compute Cloud) is certainly
finite, but for the user who needs quick access to a 1,000
AMI's (Amazon Machine Image) it appears to be infinite.
Or to put it another way, there is more capacity than any
one user will ever need to use”
A. DDoS attack rains down on Amazon cloud
Web-based code hosting service Bitbucket experienced
more than 19 hours of downtime over the weekend after an
apparent DDoS attack on the sky-high compute
infrastructure it rents from Amazon.com. This in turn left
many developers without access to code projects hosted on
Bitbucket. The attack might help other attackers to develop
new ways of DDoSing the site. After uncovering the
problem - at least 16 hours after it was first reported -
Amazon blocked the offending traffic, and service returned
to normal. But by the next morning (Sunday), the problem
returned, and another two hours passed before this second
outage was reversed. According to Nohr, Amazon told him
the second attack used a flood of TCP SYN connection
requests, rather than UDP packets [14]. As the cloud
computing has the ability to hastily provision resources,
such DOS attacks can be easier to recover from. The
much-touted agility of the cloud really comes into play
during a DOS attack. But it certainly leads to Economic
Denial of Sustainability (EDoS) for the service Provider
using cloud.
IV. SERVICE LEVEL AGREEMENT
An SLA is a formal contract used to guarantee that
consumer’s service quality expectation can be achieved.
537
The aim of this agreement is to provide a basis for close
co-operation between Service Provider and End Users or
Service Consumers, for support services to be provided by
Service Provider to End Users/Clients, thereby ensuring a
timely and efficient support service is available to End
Users or Service Consumers. SLA include Service Terms
in terms of QoS parameters, the delivery ability of the
provider, the performance target of diversity components
of user’s workloads, the bounds of guaranteed availability
and performance, the measurement and reporting
mechanisms, the cost of the service, the data set for
renegotiation, and the penalty terms for SLA violation.
Hence the violation of SLA lead to penalties that should be
paid to dissatisfied customer [16]. According to Amazon,
the SLA is a contract between customers and service
providers of the level of service to be provided [15]. It
contains the performance metrics (e.g., uptime,
throughput, and response time), security and problem
management details. Service provider is required to
execute service requests from a customer within negotiated
quality of service (QoS) requirements for a given price. It
contains penalties for non-performance. Penalty
calculation is based on unit-price per hour from the
moment when SLA violation happened for that service
instance.
V. PROPOSED WORK
DDoS attacks are a growing menace on the Internet
and are here to stay. Attacks mimicking legitimate users
are on the rise. Even low-bandwidth attacks seem to bring
down the servers. Existing tools fail to stop such attacks
because they don’t have visibility and control over such
behavioral attacks. Though the industry has come up with
some innovative techniques to combat this menace, but
unfortunately none of these solutions are fool proof.
Mitigating eDDoS or DDoS attack requires a careful
design of the network much in advance of the attack.
The proposed work will focus on in-cloud eDDoS
mitigation web service (Scrubber Service) which is being
used on-demand. In-Cloud Scrubber Service functionality
is to generate and verify the crypto puzzle (Client puzzle).
The generated crypto puzzle is being solved by the Service
Consumer/ User by brute force method in order to prove its
legitimacy for acquiring Service.
A. Proposed Architecture
The Proposed Architectural model is as shown in Fig.
3. The Service Provider switches either in Normal mode or
suspected mode depending on the situation. Whenever the
Service Provider enters into suspected mode, an
on-demand request is being sent to In-Cloud eDDoS
mitigation service. The generated crypto puzzle is needed
to be solved with brute force method by users in order to
avail the requested service.
In-cloud eDDoS Mitigation service functionality can be
depicted as follows, shown in Fig. 4. :
• Step1: The service can act in 2 modes depending on
the Server load and Bandwidth load.
1). Normal mode
2). Suspected Mode
 2.2. High-rated DDoS attack unfeasible.
2.3. Low-Rated DDoS attack 5. Having solved new puzzles does not aid in solving
• Step2: When the service provider perceives that new given puzzles.
the web server is under normal situation, then it In a Scrubber Service-generated puzzle, the server
runs in Normal mode. generates the partial hash input and hash output, and
• Step3: When the service Provider perceives the transmits both pieces of information to the client. The
web server resource depletion is beyond an solution to the puzzle is the value k. The server provides X,
acceptable limit k1 and bandwidth traffic is high, Y, and the hash function h ( ) to the client
then high-rated DDoS attacks are expected.
Hence, service Provider will switch to Suspected Η(Χ||κ)=Υ (1)
mode and an On-Demand request is sent to the
Scrubber Service, which generates and verifies Where,
Hard_puzzle ( ). X=puzzle parameter provided by server
• Step4: When the service Provider perceives the Y=puzzle parameter provided by server
web server resource depletion beyond an k= puzzle solution
acceptable limit k1 and bandwidth traffic is normal The difficulty of this puzzle is defined by the size of k in
or less than threshold, then Low-rated DDoS bits. The greater k is in size, the more difficult the puzzle is
attacks are expected. Hence, service will switch to to solve.
Suspected mode and an On-Demand request is
sent to the Scrubber Service, which generates and Proposed Algorithm:
verifies Moderate_puzzle( ). Here Web Server will
decrease the timeout duration for the existing 1. While(RDAL > k1)
requests. 2. {
3. If(BWTAL > b1)
4. {
5. High-rated DDoS Attacks expected.
6. Send request to Scrubber Service.
7. Generate Client_Puzzle(k-bit Hard puzzle);
8. Verify Client_Puzzle(k-bit Hard puzzle);
9. }
10. Else
11. {
12. Expected Low-Rated DDoS Attacks.
13. Decrease session timeouts of existing
requests.
14. Generate Client_Puzzle(k-bit Moderate
puzzle);
15. Verify Client_Puzzle(k-bit Moderate puzzle);
16. }
17. }
18. While(RDAL < k1)
19. Server is in Normal Condition and send stop
request to scrubber service.

Fig. 3. In-cloud eDDoS mitigation web service (Scrubber Service) Where,

The client puzzle protocol should have the following RDAL is Resource Depletion Acceptable Limit.
characteristics [12][11]: BWTAL is Bandwidth traffic Acceptable Limit
1. The computational costs employed by the server and k1 , b1 represents the threshold limits of
(Scrubber Service) in generating and verifying the Resource Consumption and bandwidth
consumption respectively.
puzzles must be significantly less expensive than
the computational costs employed by the client in
solving puzzles. Fig. 4. Proposed Algorithm.
2. The puzzle difficulty, which depends on the
server’s resources availability, should be easily and VI. CONCLUSION
dynamically adjusted during attacks.
The denial-of-service attacks have become more
3. Client have limited amount of time to solve puzzles.
targeted on cloud services, causing new worries to the
4. Pre-computing puzzle solutions should be
cloud-based service providers by forcing them to pay their

538
 cloud-based service bills for serving illegitimate clients in
order to maintain the SLA of a client. In order to overcome
such troubles we proposed an in-cloud eDDoS mitigation
service (Scrubber Service), which is used on-demand and
is charged according to pay-per use basis. As the Puzzle
generation and Verification is done by the Scrubber
Service, the burden on Service Provider server’s can be
triumphed. There by reducing the cloud-based bills to the
service provider and guaranteed availability of service can
be ensured.
REFERENCES
[1] Soon Hin Khor and A. Nakao, “sPoW: On-Demand Cloud-based
eDDoS Mitigation Mechanism,” HotDep (Fifth Workshop on Hot
Topics in System Dependability), co-located with the 39th Annual
IEEE/IFIP International Conference on Dependable Systems and
Networks, June 29, 2009.
[2] “DDoS Detection and Mitigation- Ensure application availability,”
2P_TC_case_study_readyaccess_ver1.0_jun-2008, Tata
Communications Ltd.
[3] P. Ferguson and D. Senie, “RFC 2267: Network Ingress Filtering:
Defeating of Service Attacks which employ IP Source Address
Spoofing,” January 1998.
[4] A. D. Keromytis, V. Misra, and D. Rubenstein, “SOS: Secure Overlay
Services,” In Proceedings of ACM Sigcomm 2002, Pittsburgh, USA,
August 2002.
[5] D. G. Andersen. “Mayday: Distributed Filtering for Internet Services,”
in 4th USENIX Symposium on Internet Technologies and Systems
(USITS), March 26-28, 2003, pp. 31-42.
[6] Reuven Cohen, “Infinite Capacity in Cloud Computing,” June 26,
2009, Available: http://www.elasticvapor.com
/2009/06/defining-infinite.html#links.
[7] Patrick Verkaik, Oliver Spatscheck, Jacobus Van der Merwe, and Alex
C. Snoeren, “PRIMED: Community-of- Interest-Based DDoS
Mitigation,” SIGCOMM'06 Workshops September 11-15, 2006,
Pisa, Italy. ACM 1-59593-417-0/06/0009.
[8] V. Praveena, and N. Kiruthika, “New Mitigating Technique to
Overcome DDOS Attack,” World Academy of Science, Engineering
and Technology 45 2008, pp. 442-447
[9] A. D. Keromytis, V. Misra, and D. Rubenstein. “SOS: An Architecture
for Mitigating DDoS Attacks,” in IEEE Journal on Selected Areas in
Communications, Vol. 22, Issue 1, January 2004, pp. 176-188.
[10] K. Lakshminarayanan, D. Adkins, A. Perrig, and I. Stoica. “Taming IP
Flooding attacks,” in ACM SIGCOMM Computer Communication
Review (Papers from HotNets-II), Vol. 34, Issue 1, January 2004, pp.
45 – 50.
[11] D. Dean and A. Stubblefield. “Using Client Puzzles to Protect TLS,” in
Proceedings of the 10th USENIX Security Symposium, August
13-17, 2001.
[12] W. Feng, E. Kaiser, W. Feng, and A. Luu, "The Design and
Implementation of Network Puzzles", in Proceedings of IEEE
INFOCOM 2005, March 13-17, 2005.
[13] X. Wang and M. K. Reiter. “Mitigating Bandwidth-Exhaustion
Attacks using Congestion Puzzles (Extended Abstract),” in
Proceedings of the 11th ACM Conference on Computer and
Communications Security (CCS ’04). October 25-29, 2004, pp.
257–267.
[14] Cade Metz, “DDoS attack rains down on Amazon cloud,” Available:
http://www.theregister.co.uk/2009/10/05/
amazon_bitbucket_outage/, Posted in Enterprise Security, 5th October
2009 15:32 GMT
[15] Source SLA Zone: http://www.sla-zone.co.uk/
[16] Linlin Wu and Rajkumar Buyya, “Service Level Agreement (SLA) in
Utility Computing Systems,” Technical Report,
CLOUDS-TR-2010-5, Cloud Computing and Distributed Systems
Laboratory, The University of Melbourne, Australia, September 3,
2010.

539

View publication stats