A Taxonomy of DDoS Attackand DDoS Defense Mechanisms∗

Jelena Mirkovic3564 Boelter Hall

Computer Science DepartmentLos Angeles, CA 90095

sunshine@cs.ucla.edu

Peter Reiher3564 Boelter Hall

Computer Science DepartmentLos Angeles, CA 90095

reiher@cs.ucla.edu

ABSTRACTDistributed denial-of-service (DDoS) is a rapidly growingproblem. The multitude and variety of both the attacksand the defense approaches is overwhelming. This paperpresents two taxonomies for classifying attacks and defenses,and thus provides researchers with a better understandingof the DDoS problem. The attack classification criteria wasselected to highlight commonalities and important featuresof attack strategies, that define challenges and dictate thedesign of countermeasures. The defense taxonomy classifiesthe body of existing DDoS defenses based on their designdecisions; it then shows how these decisions dictate the ad-vantages and deficiencies of a proposed solution.

1. INTRODUCTIONDistributed denial-of-service attacks pose an immense threat

to the Internet, and many defense mechanisms have beenproposed to combat the problem. Attackers constantly mod-ify their tools to bypass these security systems, and re-searchers in turn modify their approaches to handle newattacks. The DDoS field is quickly becoming more andmore complex, and has reached the point where it is dif-ficult to see the forest for the trees. On one hand, this hin-ders an understanding of the distributed denial-of-servicephenomenon. Multitudes of known attacks create the im-pression that the problem space is vast, and hard to exploreand address. On the other hand, existing defense systemsdeploy various strategies to counter the problem, and it isdifficult to asses their effectiveness and cost, and to comparethem to each other.

This paper proposes a taxonomy of DDoS attacks and ataxonomy of DDoS defense systems. Together, they struc-ture the DDoS field and facilitate a global view of the prob-lem and solution space. By setting apart and emphasizing

∗This work is funded by DARPA under contract numberN66001-01-1-8937.

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.Copyright 2002 ACM X-XXXXX-XX-X/XX/XX ...$5.00.

crucial features of attack and defense mechanisms, while ab-stracting detailed differences, these taxonomies can be usedby researchers to answer many important questions:

• What are the different ways of perpetrating a DDoSattack? Why is DDoS a difficult problem to handle?

• What attacks have been handled effectively by exist-ing defense systems? What attacks still remain unad-dressed and why?

• Given two defense mechanisms, A and B, how wouldthey perform if attack C occurred? What is their de-ployment cost? What are their vulnerabilities? Canthey complement each other and how? Are there somedeployment points that are better suited for A than Band vice versa?

• What are the unsolved problems and how can one con-tribute to the field?

The proposed taxonomies are complete in the followingsense: the attack taxonomy covers known attacks and alsothose which have not currently appeared but are poten-tial threats that would affect current defense mechanisms;the defense system taxonomy covers not only published ap-proaches but also some commercial approaches that are suf-ficiently documented to be analyzed. Along with classifica-tion, we provide representative examples of existing mecha-nisms.

We do not claim that these taxonomies are as detailed aspossible. Many classes could be divided into several deeperlevels. Also, new attack and defense mechanisms are likelyto appear, thus adding new classes to the ones we propose.Our goal was to select several important features of attackand defense mechanisms that might help researchers designinnovative solutions, and to use these features as classifi-cation criteria. It was also important not to confuse thereader with a too elaborate and detailed classification. It isour hope that our work will be further extended by otherresearchers.

We also do not claim that classes divide attacks and de-fenses in an exclusive manner, i.e. that an instance of anattack or a particular defense system must be classified intoa single class based on a given criterion. It is possible for anattack to be comprised of several mechanisms, each of thembelonging to a different class.

The depth and width of the proposed taxonomies are notsuitable for a traditional numbering of headings – numbers

would quickly become too elaborate to follow. We thereforeintroduce a customized marking (numbering) of subsectionheadings in Sections 3 and 5. Each classification criterionis marked abbreviating its name. Attack classes under thiscriterion are marked by criterion abbreviation and an ara-bic number, connected by a dash. To indicate depth of aspecific criterion or a class in the taxonomy, the completemark of a subsection is generated by traversing the tax-onomies depicted in Figure 1 and Figure 2, from root tothe object in question, concatenating levels with a colon.For example: if an attack classification criterion is degree ofautomation, it will bear the mark DA. The second attackclass under this criterion, semi-automatic attacks, will bearthe mark DA-2. One level below, semi-automatic attacksare divided according to communication mechanism (head-ing mark DA-2:CM ) into attacks with direct communica-tion (heading mark DA-2:CM-1 ) and attacks with indirectcommunication (heading mark DA-2:CM-2 ). To keep theheading names short, some words are omitted. In the pre-vious example, the subsection describing division by degreeof automation will bear the heading DA: Degree of Automa-tion, whereas the complete heading should be DA: AttackClassification by Degree of Automation. The subsection de-scribing attacks with indirect communication will bear theheading DA-2:CM-2: Indirect Communication, whereas thecomplete heading should be DA-2:CM-2: Semi-AutomaticAttacks with Indirect Communication.

This paper does not propose or advocate any specific DDoSdefense mechanism. Even though some sections might pointout vulnerabilities in certain classes of defense systems, ourpurpose is not to criticize, but to draw attention to theseproblems so that they might be solved. Following this intro-duction, Section 2 investigates the problem of DDoS attacks,and Section 3 proposes their taxonomy. Section 4 discussesthe DDoS defense challenge, and Section 5 proposes a tax-onomy of DDoS defense systems. Section 6 discusses howto use the taxonomies. Section 7 provides an overview ofrelated work, and Section 8 concludes the paper.

2. DDOS ATTACK OVERVIEWA denial-of-service attack is characterized by an explicit

attempt by attackers to prevent the legitimate use of a ser-vice [12]. A distributed denial-of-service attack deploys mul-tiple machines to attain this goal.

There are many ways to perpetrate a denial-of-service at-tack. One frequently exercised approach is for the attackerto send a stream of packets to a victim; this stream con-sumes some key resource, thus rendering it unavailable tothe victim’s legitimate clients. Another common approachis for the attacker to send a few malformed packets that con-fuse an application or a protocol on the victim machine andforce it to freeze or reboot. In September 2002 there was anonset of attacks that overloaded the Internet infrastructurerather than targeting specific victims [48]. Yet another pos-sible way to deny service is to subvert machines in a victimnetwork and consume some key resource so that legitimateclients from the same network cannot obtain some inside oroutside service. This list is far from exhaustive. It is cer-tain that there are many other ways to deny service on theInternet, some of which we cannot predict, and these willonly be discovered after they have been exploited in a largeattack. In an attempt to better understand the denial-of-service phenomenon, this section will answer following ques-

tions: (1) what makes DDoS attacks possible, (2) how doDDoS attacks occur, and (3) what is the attacker’s motiva-tion.

2.1 Internet ArchitectureThe Internet was designed with functionality, not secu-

rity, in mind, and it has been very successful in reachingits goal. It offers participants fast, simple and cheap com-munication mechanisms, enforced with various higher-levelprotocols that ensure reliable or timely delivery of messagesor a certain level of quality of service. Internet design fol-lows the end-to-end paradigm: communicating end hosts de-ploy complex functionalities to achieve desired service guar-antees, while the intermediate network provides the bare-minimum, best-effort service of simply forwarding packetsfrom the source to the destination. The Internet is man-aged in a distributed manner; therefore, no common policycan be enforced among its participants. The Internet de-sign opens several security issues concerning opportunitiesfor distributed denial-of-service attacks:

1. Internet security is highly interdependent. DDoSattacks are commonly launched from systems that aresubverted through security-related compromises. Re-gardless of how well secured the victim system maybe, its susceptibility to DDoS attacks depends on thestate of security in the rest of the global Internet [19].

2. Internet resources are limited. Each Internet en-tity (host, network, service) has limited resources thatcan be consumed by too many users.

3. The power of many is greater than the power

of few. Coordinated and simultaneous malicious ac-tions by some participants will always be detrimentalto others if the resources of the attackers are greaterthan the resources of the victims.

4. Intelligence and resources are not collocated.

An end-to-end communication paradigm led to stor-ing most of the intelligence needed for service guaran-tees with end hosts, limiting the amount of processingin the intermediate network so that packets could beforwarded quickly and at minimal cost. At the sametime, a desire for large throughput led to the designof high bandwidth pathways in the intermediate net-work, while the end networks invested in only as muchbandwidth as they thought they might need. Thus,malicious clients can misuse the abundant resourcesof the unwitting intermediate network for delivery ofnumerous messages to a less provisioned victim.

5. Accountability is not enforced. In IP packets thesource address field is assumed to carry the IP addressof the machine that originated the packet. This as-sumption is not generally validated or enforced at anypoint on route from the source to the destination. Thiscreates the opportunity for source address spoofing –the forging of source address fields in packets. Sourceaddress spoofing gives attackers a powerful mechanismto escape accountability for their actions, and some-times even the means to perpetrate attacks (reflectorattacks, such as the Smurf [17] attack).

6. Control is distributed. Internet management is dis-tributed, and each network is run according to local

policies defined by its owners. The implications of thisare many. There is no way to enforce global deploy-ment of a particular security mechanism or securitypolicy, and due to privacy concerns, it is often impos-sible to investigate cross-network traffic behavior.

2.2 DDoS Attack StrategyA distributed denial-of-service is carried out in several

phases. The attacker first recruits multiple agent (slave)machines. This process is usually performed automaticallythrough scanning of remote machines, looking for securityholes that will enable subversion. Vulnerable machines arethen exploited using the discovered vulnerability, and theyare infected with the attack code. The exploit/infect phaseis also automated, and the infected machines can be usedfor further recruitment of new agents. Agent machines areused to send the attack packets. Attackers usually hide theidentity of subverted machines during the attack throughspoofing of the source address field in attack packets. Note,however, that spoofing is not always required for a success-ful DDoS attack. With the exception of reflector attacks,all other attack types use spoofing only to hinder attackdetection and discovery of agent machines.

2.3 DDoS GoalsThe goal of a DDoS attack is to inflict damage on the vic-

tim. Frequently the ulterior motives are personal reasons (asignificant number of DDoS attacks are perpetrated againsthome computers, presumably for purposes of revenge), orprestige (successful attacks on popular Web servers gain therespect of the hacker community). However, it is not un-likely that some DDoS attacks are performed for materialgain (damaging competitor’s resources) or for political rea-sons (a country at war could perpetrate attacks against itsenemy’s critical resources, potentially enlisting a significantportion of the entire country’s computing power for this ac-tion). In some cases, the true victim of the attack might notbe the actual target of the attack packets, but others whorely on the target’s correct operation.

3. TAXONOMY OF DDOS ATTACKSIn order to devise a taxonomy of distributed denial-of-

service attacks, we observe the means used to prepare andperform the attack (recruit, exploit and infect phases), thecharacteristics of the attack itself (use phase) and the effectit has on the victim. Figure 1 summarizes the taxonomy. Inthe remainder of this section we discuss each of the proposedcriteria and classes.

DA: Degree of AutomationEach of the recruit, exploit, infect and use phases can beperformed manually or can be automated. Based on the de-gree of automation, we differentiate between manual, semi-automatic and automatic DDoS attacks.

DA-1: ManualOnly the early DDoS attacks belonged to the manual cat-egory. The attacker scanned remote machines for vulner-abilities, broke into them, installed attack code, and thencommanded the onset of the attack. All of these actionswere soon automated.

DA-2: Semi-AutomaticIn semi-automatic attacks, the DDoS network consists ofhandler (master) and agent (slave, daemon) machines. Therecruit, exploit and infect phases are automated. In the usephase, the attacker specifies the attack type, onset, durationand the victim via the handler to agents, who send packetsto the victim.

DA-2:CM: Communication MechanismBased on the communication mechanism deployed betweenagent and handler machines, we divide semi-automatic at-tacks into attacks with direct communication and attackswith indirect communication.

DA-2:CM-1: Direct CommunicationDuring attacks with direct communication, the agent andhandler machines need to know each other’s identity in orderto communicate. This is usually achieved by hard-codingthe IP address of the handler machines in the attack codethat is later installed at the agent machine. Each agentthen reports its readiness to the handlers, who store its IPaddress for later communication. The obvious drawback ofthis approach is that discovery of one compromised machinecan expose the whole DDoS network. Also, since agents andhandlers listen to network connections, they are identifiableby network scanners.

DA-2:CM-2: Indirect CommunicationAttacks with indirect communication deploy a level of indi-rection to increase the survivability of a DDoS network. Re-cent attacks provide the example of using IRC channels [19]for agent/handler communication. Further, the attack codecan be changed over time. For instance, the W32/leavesworm [49] used for automatic propagation can receive andinterpret commands through an IRC service which enablesdynamic updates of the attack code. The use of IRC servicesreplaces the function of a handler, since the IRC channel of-fers sufficient anonymity to the attacker. Since DDoS agentsestablish outbound connections to a standard service portused by a legitimate network service, agent communicationsto the control point may not be easily differentiated fromlegitimate network traffic. The agents do not incorporate alistening port that is easily detected by network scanners.An attacker controls the agents using IRC communicationschannels. Thus, discovery of a single agent may lead nofurther than the identification of one or more IRC serversand channel names used by the DDoS network. From there,identification of the DDoS network depends on the ability totrack agents currently connected to the IRC server. To avoiddiscovery, attackers frequently deploy channel-hopping, us-ing any given IRC channel for short periods of time. TheIRC service is maintained in a distributed manner, and theIRC server hosting a particular IRC channel may be locatedon a home computer or in a different country. This makesit hard to prevent inappropriate use of IRC functionality.Although the IRC service is the only current example of in-direct communication, there is nothing to prevent attackersfrom subverting other legitimate services for similar pur-poses.

DDoS Attack Mechanisms

Manual (DA-1)

Semi-automatic (DA-2)

Automatic (DA-3)

Direct (CM-1)

Indirect (CM-2)

Random (SS-1)

Hitlist (SS-2)

Signpost (SS-3)

Permutation (SS-4)

Local subnet (SS-5)

Central (PM-1)

Back-chaining (PM-2)

Autonomous (PM-3)

Semantic (EV-1)

Brute-force (EV-2)

Filterable (RAVS-1)

Non-filterable (RAVS-2)

Characterizable (PC-1)

Non-characterizable (PC-2)

Constant rate (ARD-1)

Variable rate (ARD-2)

Increasing (RCM-1)

Fluctuating (RCM-2)

Disruptive (IV-1)

Degrading (IV-2)

Host (VT-2)

Application (VT-1)

Network (VT-3)

Infrastructure (VT-4)

Constant set (PAS-1)

Variable (PAS-2)

Spoofed (SAV-1)

Valid (SAV-2)

Non-routable (AR-2)

Routable (AR-1)

Random (ST-1)

Subnet (ST-2)

En route (ST-3)

Classification by degree of automation (DA)

Classification by scanning strategy (SS)

Classification by propagation mechanism (PM)

Classification by communication mechanism (CM)

Classification by attack rate dynamics (ARD)

Classification by rate change mechanism (RCM)

Classification by possibility of characterization (PC)

Classification by relation of attack to victim services (RAVS)

Classification by source address validity (SAV)

Classification by victim type (VT)

Classification by persistence of agent set (PAS)

Classification by impact on the victim (IV)

Recoverable (PDR-1)

Non-recoverable (PDR-2)

Classification by possibility of dynamic recovery (PDR)

Classification by exploited vulnerability (EV)

Classification by address routability (AR)

Classification by spoofing technique (ST)

Figure 1: Taxonomy of DDoS Attack Mechanisms

DA-3: AutomaticAutomatic DDoS attacks automate the use phase in addi-tion to the recruit, exploit and infect phases, and thus avoidthe need for communication between attacker and agent ma-chines. The start time of the attack, attack type, durationand victim are preprogrammed in the attack code. Deploy-ment mechanisms of this attack class offer minimal exposureto the attacker, since he is only involved in issuing a singlecommand – the start of the attack script. The hardcoded at-tack specification suggests a single-purpose use of the DDoSnetwork, or the inflexible nature of the system. However,the propagation mechanisms usually leave a backdoor to thecompromised machine open, enabling easy future access andmodification of the attack code. Further, the code that con-trols all phases can be arbitrarily complex and adaptive,checking for updates at pre-arranged places. The drawbackof automated attacks is that all flexibility must be designedin advance and built into the code.

DA-2 and DA-3:SS: Scanning StrategyBoth semi-automatic and automatic attacks recruit the agentmachines by deploying automatic scanning and propagationtechniques, usually through use of worms. The goal of thescanning strategy is to locate as many vulnerable machinesas possible while creating a low traffic volume to escape de-tection. Based on the scanning strategy, we differentiatebetween attacks that deploy random scanning, hitlist scan-ning, signpost scanning, permutation scanning and local sub-net scanning. We give a brief description of these scanningtechniques here and refer the reader to [62] for a detaileddescription and performance comparison. Attackers usu-ally combine the scanning and exploit phases, thus gaininga larger agent population, and our description of scanningtechniques relates to this model.

DA-2 and DA-3:SS-1: Random ScanningDuring random scanning, each compromised host probesrandom addresses in the IP address space, using a differentseed. Code Red (CRv2) performed random scanning [47].

Random scanning potentially creates a high traffic volumesince many machines are likely to probe the same addresses.The probability for collision increases as a larger portion oftotal address space gets infected. The high traffic volumecan lead to attack detection.

DA-2 and DA-3:SS-2: Hitlist ScanningA machine performing hitlist scanning probes all addressesfrom an externally supplied list. When it detects a vul-nerable machine, it sends a portion of the initial hitlist tothe recipient and keeps the rest. Hitlist scanning allows forgreat propagation speed and no collisions during the scan-ning phase. The disadvantage is that the hitlist needs tobe assembled in advance. The information contained in thelist is not likely to be gathered through scanning (since itwould duplicate the effort) but rather collected over timethrough some less conspicuous techniques. For instance, thehitlist could be assembled using information published atnetscan.org related to domains that still support directedIP broadcast and can thus be used for a Smurf attack [17].The hitlist also needs to be transmitted to machines thatare being infected. If the list is too large, this traffic mightbe of high volume and lead to attack detection; if it is toosmall, it will generate a small agent population.

DA-2 and DA-3:SS-3: Signpost ScanningSignpost scanning (also called topological scanning in [62])uses information on the compromised host to select new tar-gets. E-mail worms use signpost scanning, exploiting theinformation from address books of compromised machinesfor their spread. A Web-server-based worm could spread byinfecting each vulnerable Web browser of clients that clickon the server’s Web page, and then further infect serversof subsequent Web pages visited by these clients. Signpostscanning does not generate a high traffic load and thus re-duces chances of attack detection. The drawback is that thespreading speed depends on agent machines and their userbehavior, i.e. it is not controllable by the attacker. Theagent mobilization may be slower and less complete thanwith other scanning techniques.

DA-2 and DA-3:SS-4: Permutation ScanningDuring permutation scanning, all compromised machinesshare a common pseudo-random permutation of the IP ad-dress space; each IP address is mapped to an index in thispermutation. Permutation scanning is preceded by smallhitlist scanning during which an initial population of agentsis formed. A machine infected during this initial phase be-gins scanning through the permutation by using the indexcomputed from its IP address as a starting point. When-ever it sees an already-infected machine, it chooses a newrandom start point. A machine infected by permutationscanning always starts from a random point in the permu-tation. Permutation scanning has the effect of providing asemi-coordinated, comprehensive scan while maintaining thebenefits of random probing. This technique is described in[62] as not yet deployed. The analysis provided there showsthat the spreading speed could be on the order of severalminutes, while small number of collisions should not lead toattack detection.

DA-2 and DA-3:SS-5: Local Subnet ScanningLocal subnet scanning can be added to any of the previouslydescribed techniques to preferentially scan for targets thatreside on the same subnet as the compromised host. Usingthis technique, a single copy of the scanning program cancompromise many vulnerable machines behind a firewall.Code Red II [11] and Nimda Worm [15] used local subnetscanning.

DA-2 and DA-3:PM: Propagation MechanismAfter the recruit and exploit phases, the agent machine isinfected with the attack code. Based on the attack codepropagation mechanism during the infect phase, we differ-entiate between attacks that deploy central source propaga-tion, back-chaining propagation and autonomous propaga-tion, building on the propagation models described in [19].

DA-2 and DA-3:PM-1: Central Source PropagationDuring central source propagation, the attack code resideson a central server or set of servers. After compromise ofthe agent machine, the code is downloaded from the centralsource through a file transfer mechanism. The 1i0n [14]worm operated in this manner. Central source propagationimposes a large burden on a central server, generating hightraffic and possibly leading to attack discovery. The centralserver is also a single point of failure; its removal prohibitsfurther agent mobilization.

DA-2 and DA-3:PM-2: Back-Chaining PropagationDuring back-chaining propagation, the attack code is down-loaded from the machine that was used to exploit the system.The infected machine then becomes the source for the nextpropagation step. The Ramen worm [16] and Morris Worm[28] used back-chaining propagation. Back-chaining prop-agation is more survivable than central-source propagationsince it avoids a single point of failure (central server).

DA-2 and DA-3:PM-3: Autonomous PropagationAutonomous propagation avoids the file retrieval step by in-jecting attack instructions directly into the target host dur-ing the exploit phase. Code Red [10], Warhol Worm [62]and numerous E-mail worms use autonomous propagation.

Autonomous propagation reduces the frequency of networktraffic needed for agent mobilization, and thus further re-duces chances of attack discovery.

Note that one could easily imagine an attack that wouldnot fall into any of the proposed manual, semi-automaticand automatic classes. For instance, just the recruit anduse phases of the attack could be automated, and the exploitand infect phases could be performed manually. Generatingclasses to accommodate all combinations of automated andnon-automated phases would introduce unnecessary com-plexity since most of these attacks are not likely to occur.We therefore limited our attention to known and probablecombinations.

EV: Exploited Vulnerability to Deny ServiceDistributed denial-of-service attacks exploit different strate-gies to deny the service of the victim to its clients. Basedon the vulnerability that is exploited to deny service, wedifferentiate between semantic and brute-force attacks.

EV-1: SemanticSemantic attacks exploit a specific feature or implementa-tion bug of some protocol or application installed at the vic-tim in order to consume excess amounts of its resources. Forexample, in the TCP SYN attack, the exploited feature isthe allocation of substantial space in a connection queue im-mediately upon receipt of a TCP SYN request. The attackerinitiates multiple connections that are never completed, thusfilling up the connection queue. In the CGI request attack,the attacker consumes the CPU time of the victim by is-suing multiple CGI requests. In the authentication serverattack, the attacker exploits the fact that the signature ver-ification process consumes significantly more resources thanbogus signature generation. He sends numerous bogus au-thentication requests to the server, tying up its resources.The NAPTHA [53] attack is an especially powerful attackon the TCP protocol. It initiates and establishes numerousTCP connections that consume the connection queue at thevictim. NAPTHA bypasses the TCP protocol stack on theagent machine, not keeping the state for connections it orig-inates. Instead it participates in the connection, inferringits attributes from received packets. Thus a single agentmachine can easily deplete the resources of any victim.

EV-2: Brute-ForceBrute-force attacks (or, as they are frequently called, flood-ing attacks) are performed by initiating a vast amount ofseemingly legitimate transactions. Since an upstream net-work can usually deliver higher traffic volume than the vic-tim network can handle, a high number of attack packetscan exhaust the victim’s resources.

There is a thin line between semantic and brute forceattacks. Semantic attacks also overwhelm a victim’s re-sources with excess traffic, and badly designed protocol fea-tures at remote hosts are frequently used to perform “re-flector” brute-force attacks, such as the DNS request at-tack [13] or the Smurf attack [17]. The difference is thatthe victim can usually substantially mitigate the effect ofsemantic attacks by modifying the misused protocols or de-ploying proxies. However, it is helpless against brute-forceattacks due to their misuse of legitimate services (filteringof the attack packets would also mean filtering legitimaterequests for service) or due to its own limited resources (a

victim cannot handle an attack that swamps its networkbandwidth). Countering semantic attacks by modifying thedeployed protocol or application pushes the correspondingattack mechanism into the brute-force category. For exam-ple, if the victim deploys TCP SYN cookies [18] to combatTCP SYN attacks, it will still be vulnerable to TCP SYNattacks that generate more requests than its network canaccommodate. Classification of the specific attack needs totake into account both the attack mechanisms used, andthe victim’s configuration and deployed protocols. It shouldbe noted that brute-force attacks need to generate a muchhigher volume of attack packets than semantic attacks toinflict damage to the victim. So by modifying the deployedprotocols, the victim pushes its vulnerability limit higher.It is interesting to note that the variability of attack packetcontents is determined by the exploited vulnerability. Pack-ets comprising semantic and some brute force attacks mustspecify some valid header fields and possibly some valid con-tents. For example TCP SYN attack packets cannot varythe protocol or SYN flag field, and HTTP flood packets mustbelong to an established TCP connection and therefore can-not spoof source addresses.

SAV: Source Address ValiditySource address spoofing plays a crucial role in denial-of-service, since malicious packets cannot be traced to thesource, and responsibility for actions cannot be assigned.If source address spoofing were eliminated, many denial-of-service attacks could be solved through resource manage-ment techniques – giving the fair share of host or networkresources to each source IP address. Based on the source ad-dress validity, we distinguish between spoofed source addressand valid source address attacks.

SAV-1: Spoofed Source AddressThis is the prevalent type of attack since it is always toattacker’s advantage to spoof the source address, avoid ac-countability, and possibly create more noise for detection.

SAV-1:AR: Address RoutabilityWe further divide spoofed source address attacks based onthe address routability into routable source address and non-routable source address attacks.

SAV-1:AR-1: Routable Source AddressAttacks that spoof routable addresses take over the IP ad-dress of another machine. This is sometimes done, not toavoid accountability, but to perform a reflection attack onthe machine whose address was hijacked. During a reflectionattack many requests for some service are made using thespoofed address of the victim machine, and multiple repliesare then sent back to the victim, overwhelming it. One ex-ample of a reflection attack is a Smurf attack.

SAV-1:AR-2: Non-Routable Source AddressAttackers can spoof non-routable source addresses, some ofwhich can belong to a reserved set of addresses (such as192.168.0.0/16) or be part of an assigned but not used ad-dress space of some network. Attack packets carrying re-served addresses can be easily detected and discarded, whilethose packets carrying non-used addresses would be signifi-cantly harder to detect.

SAV-1:ST: Spoofing TechniqueSpoofing technique defines how the attacker chooses thespoofed source address in its attack packets. Based on thespoofing technique, we divide spoofing attacks into random,subnet and en route spoofed source address attacks.

SAV-1:ST-1: Random Spoofed Source AddressMany attacks spoof random source addresses in the attackpackets, since this can simply be achieved by generatingrandom 32-bit numbers and stamping packets with them.Recent attempts to prevent spoofing using ingress filtering[25] and route-based filtering [39, 51] force attackers to de-vise more sophisticated techniques, such as subnet and enroute spoofing that can avoid current defense approaches.

SAV-1:ST-2: Subnet Spoofed Source AddressIn subnet spoofing, the attacker spoofs a random addressfrom the address space assigned to the agent machine’s sub-net. Since machines at a subnet share the medium (Eth-ernet) to reach the exit router (first hop en route to theoutside world), spoofing can be detected by this router us-ing fairly complicated techniques. It is impossible to detectit anywhere between the exit router and the victim.

SAV-1:ST-3: En Route Spoofed Source AddressAn en route spoofed source address attack would spoof theaddress of a machine or subnet that is en route from theagent machine to the victim. There have not been anyknown instances of attacks that use en route spoofing, butthis potential spoofing technique could affect route-basedfiltering [39, 51] and is thus discussed here.

SAV-2: Valid Source AddressAttackers benefit from source address spoofing and are likelyto deploy it whenever possible. Valid source address attacksfrequently originate from agent machines running Windows,since all Windows versions prior to XP do not export user-level functions for packet header modification. Those at-tacks that target specific applications or protocol featuresmust use valid source addresses if the attack strategy re-quires several request/reply exchanges between an agent andthe victim machine. One example of such an attack isNAPTHA [53]. While spoofing is desirable for the attacker,effective attacks are generally possible without spoofing.

ARD: Attack Rate DynamicsDuring the attack, each participating agent machine sendsa stream of packets to the victim. Depending on the attackrate dynamics of an agent machine, we differentiate betweenconstant rate and variable rate attacks.

ARD-1: Constant RateThe majority of known attacks deploy a constant rate mech-anism. After the onset is commanded, agent machines gen-erate attack packets at a steady rate, usually as many astheir resources permit. The sudden packet flood disruptsthe victim’s services quickly. This approach provides thebest cost-effectiveness to the attacker since he can deploya minimal number of agents to inflict the damage. On theother hand, the large, continuous traffic stream can be de-tected as anomalous and arouse suspicion in the networkhosting an agent machine, thus provoking attack discovery.

ARD-2: Variable RateVariable rate attacks vary the attack rate of an agent ma-chine to delay or avoid detection and response.

ARD-2:RCM: Rate Change MechanismBased on the rate change mechanism, we differentiate be-tween increasing rate and fluctuating rate attacks.

ARD-2:RCM-1: Increasing RateAttacks that have a gradually increasing rate lead to a slowexhaustion of the victim’s resources. A victim’s servicescould degrade slowly over a long time period, thus substan-tially delaying detection of the attack.

ARD-2:RCM-2: Fluctuating RateAttacks that have a fluctuating rate adjust the attack ratebased on the victim’s behavior or preprogrammed timing,occasionally relieving the effect to avoid detection. A puls-ing attack provides one example of a fluctuating rate attack.During a pulsing attack, agent hosts periodically abort theattack and resume it at a later time. If this behavior is simul-taneous for all agents, the victim experiences periodic servicedisruptions. If, however, agents are divided into groups thatcoordinate so that one group is always active, then the vic-tim experiences continuous denial-of-service while the net-work hosting agent machine may not notice any anomaloustraffic.

PC: Possibility of CharacterizationLooking at the content and header fields of attack packets,it is sometimes possible to characterize the attack. Based onthe possibility of characterization, we differentiate betweencharacterizable and non-characterizable attacks.

PC-1: CharacterizableCharacterizable attacks are those that target specific pro-tocols or applications at the victim and can be identifiedby a combination of IP header and protocol header values,or maybe even packet contents. Examples include the TCPSYN attack (only packets with SYN bit set in the TCPheader can potentially be part of the attack), ICMP ECHOattack, DNS request attack, etc.

PC-1:RAVS: Relation of Attack to Victim ServicesCharacterizable attacks are further divided, based on therelation of attack to victim services, into filterable and non-filterable attacks.

PC-1:RAVS-1: FilterableFilterable attacks are those that use malformed packets orpackets for non-critical services of the victim’s operation.These can thus be filtered by a firewall. Examples of suchattacks are a UDP flood attack or an ICMP ECHO floodattack on a Web server. Since a Web server only needs TCPtraffic and some DNS traffic (which can be characterized aspermitting only those inbound UDP packets that are DNSreplies to previous outbound DNS requests), it can easilyblock all other inbound UDP traffic and all ICMP traffic,and still operate correctly.

PC-1:RAVS-2: Non-FilterableNon-filterable attacks use well-formed packets that requestlegitimate services from the victim. Thus, filtering all pack-ets that match the attack characterization would lead to animmediate denial of the specified service to both attackersand legitimate clients. Examples are HTTP requests flood-ing a Web server or a DNS request flood targeting a nameserver. In the case of non-filterable attacks, the contents ofan attack packet are indistinguishable from the contents ofpackets originating from a legitimate client.

PC-2: Non-CharacterizableNon-characterizable attacks attempt to consume networkbandwidth using a variety of packets that engage differentapplications and protocols. Sometimes packets will even berandomly generated using reserved protocol numbers.

Note that classification of attack as characterizable or notdepends strongly on the resources that can be dedicatedto characterization and the level of characterization. Forinstance, an attack using a mixture of TCP SYN, TCPACK, ICMP ECHO, ICMP ECHO REPLY and UDP pack-ets would probably be characterizable, but only after con-siderable effort and time, and only if one had access to asophisticated characterization tool. Also, an attack using amixture of TCP packets with various combinations of TCPheader fields can be characterized as a TCP attack, butfiner characterization would probably fail. So, when per-forming classification of attacks into characterizable or non-characterizable, a lot is left to interpretation, and ease ofcharacterization should be taken into account.

PAS: Persistence of Agent SetAttacks have been known to vary different features: type oftraffic and attack packets’ header and contents can be variedduring the attack, decoy packets can be interleaved with at-tack packets, attack rate can be adjusted dynamically, etc.All these techniques hinder attack detection. Recently therewere occurrences of attacks that varied the set of agent ma-chines active at any one time, further avoiding detectionand hindering traceback. We regard this technique as im-portant since it invalidates assumptions underlying manydefense mechanisms – that agents are active throughout theattack and can thus be traced back following the path of theattack traffic. We divide attacks, based on the persistenceof the agent set, into attacks with constant agent set andattacks with variable agent set.

PAS-1: Constant Agent SetDuring attacks with the constant agent set, all agent ma-chines act in a similar manner, taking into account resourceconstraints. They receive the same set of commands and areengaged simultaneously during the attack. Examples are anattack in which all agents start sending attack traffic simul-taneously,1 or they engage in a pulsing attack but the “on”and “off” periods for pulses match over all agent machines.

1The definition of a “simultaneous start” is somewhat re-laxed in this context since the attacker’s command travelsto the agents with a variable delay. Further, because agentmachines are under different loads they do not start sendingat the exact same moment.

PAS-2: Variable Agent SetDuring attacks with a variable agent set, the attacker dividesall available agents into several groups and engages only onegroup of agents at any one time – like the army generalwho deploys his battallions at different times and places. Amachine could belong to more than one group, and groupscould be engaged again after a period of inactivity. Oneexample attack of the variable agent set type is an attack inwhich several agent groups take turns pulsing, while floodingthe victim with a constant flow of packets.

VT: Victim TypeAs discussed briefly in Section 2, attacks need not be per-petrated against a single host machine. Depending on thetype of victim, we differentiate between application, host,network and infrastructure attacks.

VT-1: ApplicationApplication attacks exploit some feature of a specific appli-cation on the victim host, thus disabling legitimate clientuse of that application and possibly tying up resources ofthe host machine. If the shared resources of the host ma-chine are not completely consumed, other applications andservices should still be accessible to the users. For example,a bogus signature attack on an authentication server ties upresources of the signature verification application, but thetarget machine will still reply to ICMP ECHO requests, andother applications that do not require authenticated accessshould still work.2

Detection of application attacks is challenging becauseother applications on the attacked host continue their oper-ations undisturbed, and the attack volume is usually smallenough not to appear anomalous. The attack packets arevirtually indistinguishable from legitimate packets at thetransport level (and frequently at the application level), andthe semantics of the targeted application must be heavilyused for detection. Since there are typically many appli-cations on a host machine, each application would have tobe modelled in the defense system and then its operationmonitored to account for possible attacks. Once detectionis performed, the host machine has sufficient resources todefend against these small volume attacks, provided that itcan separate packets that are legitimate from those that arepart of the attack.

VT-2: HostHost attacks disable access to the target machine completelyby overloading or disabling its communication mechanism.Examples of this attack are a TCP SYN attack [18] andattacks that overload the network interface or network linkof the target machine. All attack packets carry the desti-nation address of the target host. If protocols running onthe host are properly patched, the host attacks likely to beperpetrated against it are reduced to attacks that consumenetwork resources. The high packet volume of such attacksfacilitates detection. Since its network resources are con-sumed, the host cannot defend against these attacks alone,but can usually request help from some upstream machine(e.g., an upstream firewall).

2This example assumes that CPU time is shared in a fairmanner between all active applications.

VT-3: Network AttacksNetwork attacks consume the incoming bandwidth of a tar-get network with attack packets whose destination addresscan be chosen from the target network’s address space. Theseattacks can deploy various packets (since it is volume andnot content that matters) and are easily detected due totheir high volume. The victim network must request helpfrom upstream networks for defense since it cannot handlethe attack volume itself.

VT-4: InfrastructureInfrastructure attacks target some distributed service that iscrucial for global Internet operation or operation of a sub-network. Examples include the recent attacks on domainname servers [48], large core routers, routing protocols, cer-tificate servers, etc. The key feature of these attacks is notthe mechanism they deploy to disable the target (e.g., fromthe point of view of a single attacked core router, the attackcan still be regarded as a host attack), but the simultaneityof the attack on multiple instances of a critical service in theInternet infrastructure. Infrastructure attacks can only becountered through the coordinated action of multiple Inter-net participants.

IV: Impact on the VictimDepending on the impact of a DDoS attack on the victim,we differentiate between disruptive and degrading attacks.

IV-1: DisruptiveThe goal of disruptive attacks is to deny the victim’s serviceto its clients. All currently known attacks belong to thiscategory.

IV-1:PDR: Possibility of Dynamic RecoveryDepending on the possibility of dynamic recovery during orafter the attack, we differentiate between recoverable andnon-recoverable attacks.

IV-1:PDR-1: RecoverableIn the case of recoverable attacks, the victim recovers assoon as the influx of attack packets is stopped. For exam-ple, if the attack was a UDP flooding attack, tying up thevictim’s network resources, the victim will be able to usethese resources as soon as the attack is stopped.

IV-1:PDR-2: Non-RecoverableA victim of a non-recoverable attack cannot automaticallyrecover after the attack is stopped, but requires some humanintervention (e.g., rebooting the victim machine or reconfig-uring it). For example, an attack that causes the victimmachine to crash, freeze or reboot would be classified as anon-recoverable attack.

IV-2: DegradingThe goal of degrading attacks is to consume some (presum-ably constant) portion of a victim’s resources. Since theseattacks do not lead to total service disruption, they could re-main undetected for a significant time period. On the otherhand, damage inflicted on the victim’s business could be im-mense. For example, an attack that effectively ties up 30%of the victim’s resources would lead to a denial-of-serviceto some percentage of customers during high load periods,

and possibly slower average service. Some customers, dis-satisfied with the quality, would consequently change theirservice provider, and the attack victim would lose income.Alternately, the false load could result in the victim spend-ing money to upgrade its servers and networks. The additionof new resources would easily be countered by the attackerthrough more powerful attacks. Almost all existing propos-als to counter DDoS attacks would fail to address degradingattacks.

4. DDOS DEFENSE CHALLENGEThe seriousness of the DDoS problem and the increased

frequency, sophistication and strength of attacks have led tothe advent of numerous defense mechanisms. Yet, althoughit has been more than three years since the first distributedattacks were perpetrated, and many solutions have been de-veloped since then, the problem is hardly tackled, let alonesolved. Why is this so?

There are several serious factors that hinder the advanceof DDoS defense mechanisms:

1. Need for a distributed response at many points

on the Internet. The previous sections have elabo-rated on the fact that there are many possible DDoSattacks, very few of which can be handled only by thevictim. Thus it is necessary to have a distributed,possibly coordinated response system. It is also cru-cial that the response be deployed at many points onthe Internet to cover diverse choices of agents andvictims. Since the Internet is administered in a dis-tributed manner, wide deployment of any defense sys-tem (or even various systems that could cooperate)cannot be enforced or guaranteed. This discouragesmany researchers from even designing distributed so-lutions.

2. Economic and social factors. A distributed re-sponse system must be deployed by parties that do notsuffer direct damage from the DDoS attack (source orintermediate networks). This implies an unusual eco-nomic model since parties that will sustain the deploy-ment cost are not the parties that directly benefit fromthe system. Similar problems, such as the Tragedyof the Commons [29], have been handled historicallythrough legislative measures, and it is possible thatthe DDoS problem will eventually attract sufficient at-tention of lawmakers to invoke a legislative response.Until then, it is possible that many good distributedsolutions will achieve only sparse deployment and willthus have a very limited effect.

3. Lack of detailed attack information. It is widelybelieved that reporting occurrences of attacks damagesthe business reputation of the victim network. There-fore, very limited information exists about various at-tacks, and attacks are reported only to governmentorganizations under obligation to keep them secret. Itis difficult to design imaginative solutions to the prob-lem if one cannot become familiar with it. Note thatthe attack information should not be confused withattack tool information, which is publicly available atmany Internet sites. Attack information would includethe attack type, time and duration of the attack, at-

tempted response and its effectiveness, damages suf-fered, etc.

4. Lack of defense system benchmarks. Many ven-dors make bold claims that their solution completelyhandles the DDoS problem. There is currently nobenchmark suite of attack scenarios that would enablecomparison between defense systems. Such a situationis likely to discourage networks from investing in DDoSprotection, since they cannot be assured of the qualityof the product being purchased.

5. Difficulty of large-scale testing. DDoS defensesneed to be tested in a realistic environment. Thisis currently impossible due to the lack of large-scaletestbeds, safe ways to perform live distributed exper-iments across the Internet, or detailed and realisticsimulation tools that can support several thousandsof nodes. Claims about defense system performanceare thus made based on small-scale experiments andsimulations, and are not credible.

5. TAXONOMY OF DDOS DEFENSESSome DDoS defense mechanisms address a specific kind

of DDoS attack – such as attacks on Web servers or au-thentication servers. Other approaches attempt to be effec-tive against a wider range of attacks. Most of the proposedapproaches require certain features to achieve peak perfor-mance, and will perform quite differently if deployed in anenvironment where these requirements are not met. As isfrequently pointed out, there is no “silver bullet” againstDDoS attacks. Therefore we need to understand not onlyeach existing DDoS defense approach, but also how those ap-proaches might be combined together to effectively and com-pletely solve the problem. The proposed taxonomy, shownin Figure 2 should help us reach this goal. The remainderof this section will discuss each of the proposed classes ofdefense mechanisms.

AL: Activity LevelBased on the activity level of DDoS defense mechanisms, wedifferentiate between preventive and reactive mechanisms.

AL-1: PreventivePreventive mechanisms attempt either to eliminate the pos-sibility of DDoS attacks altogether or to enable potentialvictims to endure the attack without denying services tolegitimate clients.

AL-1:PG: Prevention GoalAccording to the prevention goal, we further divide preven-tive mechanisms into attack prevention and denial-of-serviceprevention mechanisms.

AL-1:PG-1: Attack PreventionAttack prevention mechanisms modify systems and proto-cols on the Internet to eliminate the possibility of a DDoSattack. The history of computer security suggests that a pre-vention approach can never be 100% effective, since globaldeployment cannot be guaranteed. However, doing a goodjob here will certainly decrease the frequency and strength ofDDoS attacks. Deploying comprehensive prevention mech-anisms can make a host completely resilient to protocol

DDoS Defense Mechanisms

Preventive (AL-1) Reactive (AL-2)

Attack prevention (PG-1)

DoS prevention (PG-2)

Classification by activity level (AL)

Classification by prevention goal (PG)

System security (ST-1)

Protocol security (ST-2)

Classification by secured target (ST)

Resource accounting (PM-1)

Resource multiplication (PM-2)

Classification by prevention method (PM)

Classification by attack detection strategy (ADS)

Pattern (ADS-1)

Anomaly (ADS-2)

Third-party (ADS-3)

Classification by attack response strategy (ARS)

Agent identification (ARS-1)

Rate-limiting (ARS-2)

Filtering (ARS-3)

Reconfiguration (ARS-4)

Classification by cooperation degree (CD)

Autonomous (CD-1)

Cooperative (CD-2)

Interdependent (CD-3) Classification by deployment location (DL)

Victim network (DL-1)

Intermediate network (DL-2)

Source network (DL-3)

Classification by normal behavior specification (NBS)

Standard (NBS-1)

Trained (NBS-2)

Figure 2: Taxonomy of DDoS Defense Mechanisms

attacks. Also, these approaches are inherently compatiblewith and complementary to all other defense approaches.

AL-1:PG-1:ST: Secured TargetBased on the secured target, we further divide attack pre-vention mechanisms into system security and protocol secu-rity mechanisms.

AL-1:PG-1:ST-1: System SecuritySystem security mechanisms increase the overall security ofInternet hosts and routers, guarding against illegitimate ac-cesses to a machine, removing application bugs and updat-ing protocol installations to prevent intrusions and misuseof the system. DDoS attacks owe their power to large num-bers of subverted machines that cooperatively generate at-tack streams. If these machines were secured, the attackerswould lose their army, and the DDoS threat would then dis-appear. On the other hand, systems vulnerable to intrusionscan themselves become victims of denial-of-service attacksin which the attacker, having gained unlimited access to themachine, deletes or alters its contents. Potential victims ofDDoS attacks can be easily overwhelmed if they deploy vul-nerable protocols. Examples of system security mechanismsinclude monitored access to the machine [61], applicationsthat download and install security patches, firewall systems[43], virus scanners [44], intrusion detection systems [5], ac-cess lists for critical resources [20], capability-based systems[56] and client-legitimacy-based systems [50].

AL-1:PG-1:ST-2: Protocol SecurityProtocol security mechanisms address the problem of a badprotocol design. For example, many protocols contain op-erations that are cheap for the client but expensive for theserver. Such protocols can be misused to exhaust the re-sources of a server by initiating large numbers of simultane-ous transactions. Classic misuse examples are the TCP SYNattack, the authentication server attack, and the fragmentedpacket attack (in which the attacker bombards the victimwith malformed packet fragments, forcing it to waste its re-sources on reassemble attempts). IP source address spoofingis another important example. Examples of protocol secu-

rity mechanisms include guidelines for a safe protocol designin which resources are committed to the client only aftersufficient authentication is done [38, 45], or the client haspaid a sufficient price [4], deployment of a powerful proxyserver that completes TCP connections [55], protocol scrub-bing that removes ambiguities from protocols that can bemisused for attacks [41], approaches that eliminate spoofing[51, 39, 25], etc.

AL-1:PG-2: DoS PreventionDenial-of-service prevention mechanisms enable the victimto endure attack attempts without denying service to le-gitimate clients. This is done either by enforcing policiesfor resource consumption or by ensuring that abundant re-sources exist so that legitimate clients will not be affectedby the attack.

AL-1:PG-2:PM: Prevention MethodBased on the prevention method, we divide DoS preventionmechanisms into resource accounting and resource multipli-cation mechanisms.

AL-1:PG-2:PM-1: Resource AccountingResource accounting mechanisms police the access of eachuser to resources based on the privileges of the user and hisbehavior. The user in this case might be a process, a person,an IP address, or a set of IP addresses having something incommon. Resource accounting mechanisms guarantee fairservice to legitimate well-behaved users. In order to avoiduser identity theft, they are usually coupled with legitimacy-based access mechanisms that verify the user’s identity. Ap-proaches proposed in [34, 64, 60, 26, 37] illustrate resourceaccounting mechanisms.

AL-1:PG-2:PM-2: Resource MultiplicationResource multiplication mechanisms provide an abundanceof resources to counter DDoS threats. The straightforwardexample is a system that deploys a pool of servers with aload balancer and installs high bandwidth links between it-self and upstream routers. This approach essentially raisesthe bar on how many machines must participate in an at-

tack to be effective. While not providing perfect protection,for those who can afford the costs this approach has oftenproved sufficient. For example, Microsoft has used it toweather large DDoS attacks. Another approach is the useof Akamai services for distributed Web site hosting. Userrequests for a Web page hosted in such a manner are redi-rected to an Akamai name server, which then distributes theload among multiple, geographically distributed Web servershosting replicas of the requested page.

AL-2: ReactiveReactive mechanisms strive to alleviate the impact of an at-tack on the victim. To attain this goal they need to detectthe attack and respond to it. The goal of attack detection isto detect every attempted DDoS attack as early as possibleand to have a low degree of false positives. Upon attackdetection, steps can be taken to characterize the packetsbelonging to the attack stream and provide this characteri-zation to the response mechanism.

AL-2:ADS: Attack Detection StrategyWe classify reactive mechanisms based on the attack detec-tion strategy into mechanisms that deploy pattern detection,anomaly detection, and third-party detection.

AL-2:ADS-1: Pattern DetectionMechanisms that deploy pattern detection store the signa-tures of known attacks in a database. Each communicationis monitored and compared with database entries to discoveroccurrences of DDoS attacks. Occasionally the database isupdated with new attack signatures. The obvious drawbackof this detection mechanism is that it can only detect knownattacks, and it is usually helpless against new attacks or evenslight variations of old attacks that cannot be matched tothe stored signature. On the other hand, known attacksare easily and reliably detected, and no false positives areencountered. Snort [59] provides one example of a DDoS de-fense system that uses pattern attack detection. A similarapproach has been helpful in controlling computer viruses.Like in virus detection programs, signature databases mustbe regularly updated to account for new attacks.

AL-2:ADS-2: Anomaly DetectionMechanisms that deploy anomaly detection have a modelof normal system behavior, such as normal traffic dynamicsor expected system performance. The current state of thesystem is periodically compared with the models to detectanomalies. Approaches presented in [63, 40, 32, 27, 21, 42, 2,6, 7, 46] provide examples of mechanisms that use anomalydetection. The advantage of anomaly detection over patterndetection is that previously unknown attacks can be discov-ered. The caveat is that anomaly detectors must trade offtheir ability to detect all attacks against their tendency tomisidentify normal behavior as an attack.

AL-2:ADS-2:NBS: Normal Behavior SpecificationBased on a normal behavior specification, we divide anomalydetection mechanisms into standard and trained mechanisms.

AL-2:ADS-2:NBS-1: StandardMechanisms that use standard specifications of normal be-havior rely on some protocol standard or a set of rules to

specify this behavior. For example, the TCP protocol speci-fication describes a three-way handshake that has to be per-formed for TCP connection setup. Attack detection mecha-nism can make use of this specification to detect half-openTCP connections and delete them from the queue, or it canuse TCP SYN cookies to defend against TCP SYN attack.The advantage of a standard-based specification is that itgenerates no false positives; all legitimate traffic must com-ply to the specified behavior. The disadvantage is that at-tackers can still perform sophisticated attacks which, on thesurface, seem compliant to the standard and thus pass un-detected.

AL-2:ADS-2:NBS-2: TrainedMechanisms that use trained specifications of normal behav-ior monitor network traffic and system behavior and gener-ate threshold values for different traffic parameters. All traf-fic exceeding these values is regarded as anomalous. Thisapproach catches a broad range of attacks, but it has fol-lowing disadvantages:

1. Threshold setting. Anomalies are detected whenthe current system state differs from the model by acertain threshold. The setting of a low threshold leadsto many false positives, while a high threshold reducesthe sensitivity of the detection mechanism.

2. Model update. Systems and communication pat-terns evolve with time, and models need to be updatedto reflect this change. Trained specification systemsusually perform automatic model update using statis-tics gathered at a time when no attack was detected.This approach makes the detection mechanism vulner-able to slowly increasing rate attacks that can, over along period of time, mistrain models and delay or evenavoid attack detection.

AL-2:ADS-3: Third-Party DetectionMechanisms that deploy third-party detection do not han-dle the detection process themselves, but rely on an externalmessage that signals the occurrence of the attack and pro-vides attack characterization. Examples of mechanisms thatuse third-party detection are easily found among tracebackmechanisms [8, 54, 23, 58, 57].

AL-2:ARS: Attack Response StrategyThe goal of the attack response is to relieve the impact of theattack on the victim while imposing minimal collateral dam-age to legitimate clients. We classify reactive mechanisms,based on the response strategy, into mechanisms that deployagent identification, rate-limiting, filtering and reconfigura-tion.

AL-2:ARS-1: Agent IdentificationAgent identification mechanisms provide the victim with in-formation about the identity of the machines that are per-forming the attack. This information can then be combinedwith other approaches to alleviate the impact of the attack.Agent identification examples include numerous tracebacktechniques [8, 54, 23, 58, 57]. One frequently mentionedmotivation for deployment of defense mechanisms by inter-mediate and source networks is possible enforcement of lia-bility for attack traffic. A successful mechanism for reliable

agent identification would be necessary for liability enforce-ment.

AL-2:ARS-2: Rate-LimitingRate-limiting mechanisms impose a rate limit on a streamthat has been characterized as malicious by the detectionmechanism. Examples of rate-limiting mechanisms are foundin [40, 27, 21, 46, 2]. Rate-limiting is a lenient responsetechnique that is usually deployed when the detection mech-anism has a high level of false positives or cannot preciselycharacterize the attack stream. The disadvantage is thatsuch an approach will allow some attack traffic through, soextremely high-scale attacks might still be effective even ifall traffic streams are rate-limited.

AL-2:ARS-3: FilteringFiltering mechanisms use the characterization provided bydetection mechanisms to filter out the attack streams com-pletely. Examples include dynamically deployed firewalls[22], and also a commercial system, TrafficMaster [42]. Un-less the detection strategy is very reliable, filtering mecha-nisms run the risk of accidentally denying service to legiti-mate traffic. Worse, clever attackers might leverage them asdenial-of-service tools.

AL-2:ARS-4: ReconfigurationReconfiguration mechanisms change the topology of the vic-tim or the intermediate network to either add more resourcesto the victim or to isolate the attack machines. Examples in-clude reconfigurable overlay networks [1, 32], resource repli-cation services [63], attack isolation strategies [3, 6], etc.

CD: Cooperation DegreeDDoS defense mechanisms can perform defensive measureseither alone or in cooperation with other entities in the In-ternet. Based on the cooperation degree, we differentiatebetween autonomous, cooperative and interdependent mech-anisms.

CD-1: AutonomousAutonomous mechanisms perform independent defense atthe point where they are deployed (a host or a network).Firewalls and intrusion detection systems provide easy ex-amples of autonomous mechanisms. Even if a defense systemperforms its function in a distributed manner it would stillbe considered autonomous if it can be completely deployedwithin the network it protects (like a network intrusion de-tection system).

CD-2: CooperativeCooperative mechanisms are capable of autonomous detec-tion and response, but can achieve significantly better per-formance through cooperation with other entities. The ag-gregate congestion control (ACC) system [40] deploying apushback mechanism [33] provides an example. ACC de-tects the occurrence of a DDoS attack by observing con-gestion in a router’s buffer, characterizes the traffic thatcreates the congestion, and acts locally to impose a ratelimit on that traffic. However, it achieves significantly bet-ter performance if the rate-limit requests can be propagatedto upstream routers that otherwise may be unaware of theattack.

CD-3: InterdependentInterdependent mechanisms cannot operate autonomouslyat the deployment point; they rely on other entities eitherfor attack prevention, attack detection or for efficient re-sponse. Traceback mechanisms [8, 54, 23, 58, 57] provideexamples of interdependent mechanisms. A traceback mech-anism deployed at a victim site would provide no benefit.Secure overlay services [36] are another example of an inter-dependent mechanism. They provide successful protectionto the victim, rerouting legitimate traffic through the In-ternet, but only if victim’s clients are aware and cooperatewith the mechanism.

DL: Deployment LocationWith regard to deployment location, we differentiate be-tween mechanisms deployed at the victim, intermediate, orsource network.

DL-1: Victim NetworkDDoS defense mechanisms deployed at the victim networkprotect this network from DDoS attacks and respond to de-tected attacks by alleviating the impact on the victim. His-torically, most defense systems were located at the victimsince it suffered the greatest impact of the attack and wastherefore the most motivated to dedicate some resources tosecurity mechanisms. Resource accounting [34, 64, 60, 26,37] and protocol security mechanisms [38, 45, 4, 55] provideexamples of these systems.

DL-2: Intermediate NetworkDDoS defense mechanisms deployed at the intermediate net-work provide infrastructural protection service to a largenumber of Internet hosts. Victims of DDoS attacks can con-tact the infrastructure and request the service, possibly pro-viding adequate compensation. Pushback [40] and traceback[8, 54, 23, 58, 57] techniques are examples of intermediate-network mechanisms. Such mechanisms are not yet widelydeployed, and many of them can only be effective in widedeployment.

DL-3: Source NetworkThe goal of DDoS defense mechanisms deployed at the sourcenetwork is to prevent network customers from generatingDDoS attacks. Such mechanisms are necessary and desir-able, but motivation for their deployment is low since it isunclear who would pay the expenses associated with this ser-vice. Mechanisms proposed in [27, 21, 46] provide examplesof source-network mechanisms.

6. USING THE TAXONOMIESIn designing the above taxonomies, we selected those fea-

tures of attack and defense mechanisms that, in our opinion,offer critical information regarding seriousness and type ofthreats, and effectiveness and cost of defenses. Some at-tack features, such as damage inflicted, duration, number ofagents involved, etc., were not included as criteria. Althoughthese are critical when investigating or understanding the in-cident, there is currently no publicly available informationbase that would allow us to design meaningful classifications.A standardized incident-reporting system would greatly im-prove that. Some defense mechanism characteristics, suchas timeliness of response, level of false positives, collateral

damage, etc., were also not included as criteria. We believethat these are important but they must be strictly measuredin a controlled and realistic environment using a widely ac-cepted benchmark suite. Without meeting these require-ments, we felt that any classification on these criteria thatwe could design would be uninformed and likely unjust tosome mechanisms.

In attack taxonomy design, the selected criteria coversvarious preparatory phases that preclude the attack (degreeof automation, scanning and propagation strategy, commu-nication mechanism), the organization of agent machines(persistence of the agent set), the way the attack is perpe-trated (exploited vulnerability), the attack packet contents(source address validity, address routability, spoofing tech-nique, possibility of characterization, relation of attack tovictim services), behavior of the individual agent streams(attack rate dynamics, rate change mechanism), and the vic-tim (victim type, impact on the victim, possibility of dynamicrecovery). In defense taxonomy design, the selected criteriacovers the defense goal (activity level), how it is achieved(prevention goal, secured target, prevention method, attackdetection strategy, normal behavior specification, attack re-sponse strategy), where the system should be deployed (de-ployment location), and what the requirements are for de-ployment scope (cooperation degree). It would be beneficialto summarize here how each of the attack and defense classesinteract. Instead, due to the limited length of the paper wewill offer an example case analysis and leave the rest to theinterested reader.

Let us assume that we want to protect our medium-sizeWeb server from attacks that deplete server resources only,and do this in a manner that guarantees continued goodservice to legitimate clients. Based on an analysis of at-tacks suffered so far, we are convinced that we will not bethe subject of attacks that deplete network resources andwe decide not to protect against those. First, using the at-tack taxonomy, we conclude that the attacks from whichwe want protection can be both semantic (EV-1, e.g., mal-formed packets or misuse of faulty server protocols) andbrute force (EV-2, e.g., too many legitimate-like requests).These attacks are likely to be characterizable (PC-1) butnon-filterable (RAVS-2, since we host a Web server and arelikely to receive many legitimate requests that obscure theattack). They are application (VT-1, Web server) and host(VT-2, machine hosting the server) attacks, and they arelikely to be disruptive recoverable (IV-1, PDR-1) and de-grading (IV-2) attacks. We have no information about de-gree of automation (DA), source address validity (SAV), at-tack rate dynamics (ARD) or persistence of agent set (PAS),so we assume that attack can belong to any of correspondingclasses.

Next, using the defense taxonomy, we would like to chooseeffective protection measures. To prevent semantic attackswe need to apply attack prevention measures (PG-1) whichinclude system and protocol security measures (ST-1 andST-2). Semantic attacks are likely to target Web serversoftware, the TCP implementation and HTTP/CGI proto-col. As defense measures, we need to update our softwareregularly and deploy TCP SYN [18] cookies. Additionally,we will close all unused ports to prevent intrusions and in-stall a firewall that protects from semantic attacks that usemalformed packets. To defend against brute force attacksthat consume more resources than a Web server has (once

all its protocols have been updated and protected), we caneither use DoS prevention measures (PG-2) to help us sus-tain the attack (PM-1 and PM-2), or deploy reactive de-fense systems (AL-2) that detect the attack and recognizeand preferentially serve legitimate requests. Since the at-tack is recoverable, a reactive defense should lead to contin-ued good service to legitimate clients. However, since theattack is likely to be non-filterable, differentiating the le-gitimate from the attack packets may be impossible. Ourbest option is to resort to DoS prevention measures: deployresource accounting (PM-1) and purchase resource multipli-cation services from another organization (PM-2).

7. RELATED WORKAt the time of finalizing this paper, we became aware of

related work in [9]. As that paper has not yet been printed,we were not able to obtain a copy and cannot offer com-parison to our work. In [35] authors present a classificationof denial-of-service attacks according to the type of the tar-get (e.g., firewall, Web server, router), a resource that theattack consumes (network bandwidth, TCP/IP stack) andthe exploited vulnerability (bug or overload). This classifi-cation focuses more on the actual attack phase, while we areinterested in looking at the complete attack mechanism inorder to highlight features that are specific to distributed at-tacks. In [30] and [31], Howard proposes a taxonomy of com-puter and network attacks. This taxonomy focuses on com-puter attacks in general and does not sufficiently highlightfeatures particular to distributed denial-of-service attacks.CERT is currently taking the initiative to devise a compre-hensive taxonomy of computer incidents as part of the designof common incident data format and exchange procedures,but unfortunately results are not yet available. BBN is alsoworking on generation of a DDoS attack overview, but its re-sults are not yet released. The work in [52] provides a verynice discussion of the DDoS problem and of some defenseapproaches. A solid body of work on classification exists inthe field of intrusion detection systems [31, 24, 5] and of-fers informative reading for researchers in the DDoS defensefield.

8. CONCLUSIONDistributed denial-of-service attacks are a complex and se-

rious problem, and consequently numerous approaches havebeen proposed to counter them. However, the multitudeof current attack and defense mechanisms obscures a globalview of the DDoS problem. This paper is a first attemptto cut through the obscurity and achieve a clear view ofthe problem and the existing solutions. The taxonomies de-scribed here are intended to help the community think aboutthe threats we face and the measures we can use to counterthose threats.

One benefit we foresee from the development of DDoStaxonomies is that of fostering easier cooperation among re-searchers developing DDoS defense mechanisms. Attackerscooperate to exchange attack code and information aboutvulnerable machines, and to organize their agents into coor-dinated networks to achieve immense power and survivabil-ity. The Internet community must be equally cooperativewithin itself to counter DDoS threat. Good taxonomies forDDoS attack and defense mechanisms will facilitate commu-nications and offer the community a common language for

discussing its solutions. They will also clarify how differ-ent mechanisms are likely to work in concert, and identifyareas of remaining weaknesses that require additional mech-anisms. Similarly, the research community needs to developcommon metrics and benchmarks to evaluate the efficacyof DDoS defense mechanisms, and these taxonomies can behelpful in shaping these tasks, as well.

We do not claim that these taxonomies are complete andall-encompassing. We must not be deceived by the simplic-ity of the current attacks. For the attackers, this simplicityarises more from convenience than necessity. As defensemechanisms are deployed to counter simple attacks, we arelikely to see more complex attack scenarios. Many moreattack possibilities exist and must be addressed before wecan completely handle the DDoS threat; some of these arelikely to be outside the current boundaries of the taxonomiespresented here. Thus, these taxonomies are likely to re-quire expansion and refinement as new threats and defensemechanisms are discovered. The DDoS attack taxonomyand DDoS defense taxonomy outlined in this paper are use-ful to the extent that they clarify our thinking and guideus to more effective solutions to the problem of distributeddenial-of-service. The ultimate value of the work describedhere will thus lie in the degree of discussion and future re-search that it provokes.

9. ACKNOWLEDGEMENTSAuthors would like to thank Dr. Sven Dietrich for his

helpful comments on previous versions of this paper, mem-bers of the UCLA LASR group for engaging in numerous dis-cussions on the denial-of-service problem, and Janice Wheelerfor her infinite patience in editing this and many other pa-pers. Verica Savic-Jovcic generated the customized mark-ing scheme for subsections, a task that authors have beenstruggling with for months. This scheme has made the pa-per infinitely easier to read, and we are deeply grateful forthat.

10. REFERENCES[1] D. G. Andersen, H. Balakrishnan, M. F. Kaashoek,

and R. Morris. Resilient Overlay Networks. InProceedings of 18th ACM SOSP, October 2001.

[2] Arbor Networks. The Peakflow Platform.http://www.arbornetworks.com.

[3] Asta Networks. Vantage System Overview.http://www.astanetworks.com/products/vantage/.

[4] T. Aura, P. Nikander, and J. Leiwo. DOS-ResistantAuthentication with Client Puzzles. Lecture Notes inComputer Science, 2133, 2001.

[5] S. Axelsson. Intrusion detection systems: A surveyand taxonomy. Technical Report 99-15, Department ofComputer Engineering, Chalmers University, March2000.

[6] BBN Technologies. Applications that participate intheir own defense.http://www.bbn.com/infosec/apod.html.

[7] BBN Technologies. Intrusion tolerance byunpredictability and adaptation.http://www.bbn.com/infosec/itua.html.

[8] S. Bellovin, M. Leech, and T. Taylor. ICMPTraceback Messages. Internet draft, work in progress,October 2001.

[9] M. Blaze, J. Ioannidis, and A. D. Keromytis. TowardUnderstanding the Limits of DDoS Defenses. InProceedings of the Tenth International Workshop onSecurity Protocols, April 2002.

[10] CERT Coordination Center. CERT AdvisoryCA-2001-19 “Code Red” Worm Exploiting BufferOverflow In IIS Indexing Service DLL.http://www.cert.org/advisories/CA-2001-19.html.

[11] CERT Coordination Center. Code Red II.http://www.cert.org/incident notes/IN-2001-09.html.

[12] CERT Coordination Center. Denial of Service Attacks.http://www.cert.org/tech tips/denial of service.html.

[13] CERT Coordination Center. DoS using nameservers.http://www.cert.org/incident notes/IN-2000-04.html.

[14] CERT Coordination Center. erkms and li0n worms.http://www.cert.org/incident notes/IN-2001-03.html.

[15] CERT Coordination Center. Nimda worm.http://www.cert.org/advisories/CA-2001-26.html.

[16] CERT Coordination Center. Ramen worm.http://www.cert.org/incident notes/IN-2001-01.html.

[17] CERT Coordination Center. Smurf attack.http://www.cert.org/advisories/CA-1998-01.html.

[18] CERT Coordination Center. TCP SYN flooding andIP spoofing attacks.http://www.cert.org/advisories/CA-1996-21.html.

[19] CERT Coordination Center. Trends in Denial ofService Attack Technology, October 2001.http://www.cert.org/archive/pdf/DoS trends.pdf.

[20] Cisco. Strategies to protect against Distributed Denialof Service Attacks.http://www.cisco.com/warp/public/707/newsflash.html.

[21] Cs3. Inc. MANAnet DDoS White Papers.http://www.cs3-inc.com/mananet.html.

[22] T. Darmohray and R. Oliver. Hot spares for DDoSattacks.http://www.usenix.org/publications/login/2000-7/apropos.html.

[23] D. Dean, M. Franklin, and A. Stubblefield. Analgebraic approach to IP Traceback. In Proceedings ofthe 2001 Network and Distributed System SecuritySymposium, February 2001.

[24] H. Debar, M. Dacier, and A. Wespi. Towards ataxonomy of intrusion-detection systems. In ComputerNetworks, volume 31(8), pages 805–822, April 1999.

[25] P. Ferguson and D. Senie. Network Ingress Filtering:Defeating Denial of Service Attacks which Employ IPSource Address Spoofing. RFC 2827, May 2000.

[26] A. Garg and A. L. N. Reddy. Mitigation of DoSattacks through QoS Regulation. In Proceedings ofIWQOS workshop, May 2002.

[27] T. M. Gil and M. Poletto. MULTOPS: adata-structure for bandwidth attack detection. InProceedings of 10th Usenix Security Symposium,August 2001.

[28] K. Hafner and J. Markoff. Cyberpunk: Outlaws andhackers on the computer frontier. Simon & Schuster,1991.

[29] G. Hardin. The Tragedy of the Commons. Science,162(1968):1243–1248, 1968.

[30] J. D. Howard. An analysis of security incidents on theInternet. PhD thesis, Carnegie Mellon University,

August 1998.

[31] J. D. Howard and T. A. Longstaff. A commonlanguage for computer security incidents.

[32] Information Sciences Institute. Dynabone.http://www.isi.edu/dynabone/.

[33] J. Ioannidis and S. M. Bellovin. Pushback:Router-Based Defense Against DDoS Attacks. InProceedings of NDSS, February 2002.

[34] A. Juels and J. Brainard. Client puzzles: Acryptographic countermeasure against connectiondepletion attacks. In Proceedings of the 1999 Networksand distributed system security symposium, March1999.

[35] F. Kargl, J. Maier, and M. Weber. Protecting webservers from distributed denial of service attacks. InProceedings of 10th International World Wide WebConference, May 2001.

[36] A. D. Keromytis, V. Misra, and D. Rubenstein. SOS:Secure Overlay Services. In Proceedings of SIGCOMM2002, 2002.

[37] F. Lau, S. H. Rubin, M. H. Smith, and L. Trajkovic.Distributed Denial of Service Attacks. In IEEEInternational Conference on Systems, Man, andCybernetics, pages 2275–2280, Nashville, TN, USA,October 2000.

[38] J. Leiwo, P. Nikander, and T. Aura. Towards networkdenial of service resistant protocols. In Proceedings ofthe 15th International Information SecurityConference, August 2000.

[39] J. Li, J. Mirkovic, M. Wang, P. Reiher, and L. Zhang.SAVE: Source Address Validity Enforcement Protocol.In Proceedings of INFOCOM 2002, June 2002. toappear.

[40] R. Mahajan, S. Bellovin, S. Floyd, V. Paxson, andS. Shenker. Controlling high bandwidth aggregates inthe network. ACM Computer CommunicationsReview, 32(3), July 2002.

[41] G. R. Malan, D. Watson, F. Jahanian, and P. Howell.Transport and Application Protocol Scrubbing. InProceedings of INFOCOM 2000, pages 1381–1390,2000.

[42] Mazu Networks. Mazu Technical White Papers.http://www.mazunetworks.com/white papers/.

[43] McAfee. Personal Firewall.http://www.mcafee.com/myapps/firewall/ov firewall.asp.

[44] McAfee. VirusScan Online.http://www.mcafee.com/myapps/vso/default.asp.

[45] C. Meadows. A formal framework and evaluationmethod for network denial of service. In Proceedings ofthe 12th IEEE Computer Security FoundationsWorkshop, June 1999.

[46] J. Mirkovic, G. Prier, and P. Reiher. Attacking DDoSat the Source. In Proceedings of the ICNP 2002,November 2002.

[47] D. Moore. The spread of the code red worm (crv2).http://www.caida.org/analysis/security/code-red/coderedv2 analysis.xml.

[48] R. Naraine. Massive DDoS Attack Hit DNS RootServers, October 2002.http://www.esecurityplanet.com/trends/article/0,,10751 1486981,00.html.

[49] National Infrastructure Protection Center. Advisory01-014: New Scanning Activity (withW32-Leave.worm) Exploiting SubSeven Victims, June2001.http://www.nipc.gov/warnings/advisories/2001/01-014.htm.

[50] E. O’Brien. NetBouncer : A practicalclient-legitimacy-based DDoS defense via ingressfiltering.http://www.nai.com/research/nailabs/development-solutions/netbouncer.asp.

[51] K. Park and H. Lee. On the Effectiveness ofRoute-Based Packet Filtering for Distributed DoSAttack Prevention in Power-Law Internets. InProceedings of ACM SIGCOMM 2001, August 2001.

[52] V. Razmov. Denial of Service Attacks and How toDefend Against Them.http://www.cs.washington.edu/homes/valentin/papers/DoSAttacks.pdf.

[53] SANS Institute. NAPTHA: A new type of Denial ofService Attack, December 2000.http://rr.sans.org/threats/naptha2.php.

[54] S. Savage, D. Wetherall, A. Karlin, and T. Anderson.Practical Network Support for IP Traceback. InProceedings of ACM SIGCOMM 2000, August 2000.

[55] C. Schuba, I. Krsul, M. Kuhn, G. Spafford,A. Sundaram, and D. Zamboni. Analysis of a denial ofservice attack on TCP. In Proceedings of the 1997IEEE Symposium on Security and Privacy, May 1997.

[56] J. Shapiro and N. Hardy. EROS: A principle-drivenoperating system from the ground up. In IEEESoftware, pages 26–33, January/February 2002.

[57] A. C. Snoeren, C. Partridge, L. A. Sanchez, C. E.Jones, F. Tchakountio, S. T. Kent, and W. T. Strayer.Hash-Based IP Traceback. In Proceedings of ACMSIGCOMM 2001, August 2001.

[58] D. X. Song and A. Perrig. Advanced andauthenticated marking schemes for IP Traceback. InProceedings of IEEE Infocom 2001, 2001.

[59] Sourcefire. Snort: The Open Source Network IntrusionDetection System.

[60] O. Spatscheck and L. L. Petersen. Defending AgainstDenial of Service Attacks in Scout. In Proceedings ofthe 3rd Symposium on Operating Systems Design andImplementation, February 1999.

[61] Tripwire. Tripwire for servers.http://www.tripwire.com/products/servers/.

[62] N. Weaver. Warhol Worm.http://www.cs.berkeley.edu/ nweaver/worms.pdf.

[63] J. Yan, S. Early, and R. Anderson. The XenoService –A Distributed Defeat for Distributed Denial ofService. In Proceedings of ISW 2000, Oct. 2000.

[64] Y. L. Zheng and J. Leiwo. A Method to Implement aDenial of Service Protection Base. In InformationSecurity and Privacy, volume 1270 of LNCS, pages90–101, 1997.