Defending Against Spoofed DDoS Attacks

8/8/2019 Defending Against Spoofed DDoS Attacks

1/16

Defending against spoofed DDoS attackswith path fingerprint*

Fu-Yuan Lee *, Shiuhpyng Shieh

Department of Computer Science and Information Engineering,

National Chiao Tung University, Hsinchu 30010, Taiwan

Received 8 September 2004; revised 13 March 2005; accepted 28 March 2005

KEYWORDSNetwork security;Intrusion detection;DDoS;IP spoofing

Abstract In this paper, we propose a new scheme, called ANTID, for detecting andfiltering DDoS attacks which use spoofed packets to circumvent the conventionalintrusion detection schemes. The proposed anti-DDoS scheme intends to comple-ment, rather than replace conventional schemes. By embedding in each IP packeta unique path fingerprint that represents the route an IP packet has traversed,ANTID is able to distinguish IP packets that traverse different Internet paths. InANTID, a server maintains for each of its communicating clients the mapping fromthe clients IP address to the corresponding path fingerprint. The construction andrenewal of these mappings is performed in an on-demand fashion that helps toreduce the cost of maintenance. With presence of the mapping table, the onset ofa spoofed DDoS attack can be detected by observing a surge of spoofed packets.Consequently, spoofed attack packets are filtered so as to sustain the quality ofprotected Internet services. ANTID is lightweight, robust, and incrementallydeployable. Our experiment results showed that the proposed scheme can detect99.95% spoofed IP packets and can discard them with little collateral damage tolegitimate clients. It also showed that the higher the aggregated attack rate is, thesooner the attack can be detected. 2005 Elsevier Ltd. All rights reserved.

Introduction

Distributed Denial-of-Service (DDoS) attacks posea major threat to the availability of Internet

services. A DDoS attacker can greatly reduce thequality of a target Internet service or even cancompletely break the network connectivity ofa server by persistently overloading critical net-work or system resources of the target, such asnetwork bandwidth, router processing capability,or CPU/memory at the target machine. Generally,to achieve resource overloading, a DDoS attackerwill first compromise a large number of hosts and

* This work is supported in part by III and NSC of Taiwan.* Corresponding author.

E-mail address: [email protected] (F.-Y. Lee).URL: http://www.csie.nctu.edu.tw/wleefy.

0167-4048/$ - see front matter 2005 Elsevier Ltd. All rights reserved.doi:10.1016/j.cose.2005.03.005

Computers & Security (2005) 24, 571e586

www.elsevier.com/locate/cose
mailto:[email protected]://www.csie.nctu.edu.tw/~leefyhttp://www.csie.nctu.edu.tw/~leefyhttp://www.csie.nctu.edu.tw/~leefyhttp://www.csie.nctu.edu.tw/~leefyhttp://www.elsevier.com/locate/cosehttp://www.elsevier.com/locate/cosehttp://www.csie.nctu.edu.tw/~leefymailto:[email protected]://www.ee.mu.oz.au/pgrad/taop/research/detection.pdf


2/16

subsequently instructs these compromised hosts toattack the service by exhausting a target resource.Due to the lack of built-in security mechanisms inthe current Internet infrastructure, conductinga DDoS attack is easy. An attacker can easily getaccess to a large number of insecure computerswith exploit/attack programs, such as Trinoo, TFN

and TFN2k (CERT Coordination Center, 1999a,b,c,2000; Dittrich, 1999a,b). On the other hand,defending against DDoS attacks is extremely diffi-cult because there is usually no explicit attackpattern to distinguish legitimate packets frommalicious ones. Moreover, to hide the sources ofattack traffic and circumvent DDoS defense mech-anisms relying on inspecting IP header fields, DDoSattack programs generally fill IP header fields,especially the 32-bit source IP address, withrandomized values. This IP spoofing techniquehas made the detection and filtering of DDoStraffic extremely difficult, and it has become

a common feature of the many DDoS attack tools.To design an effective and feasible DDoS coun-

termeasure, there are several requirements a DDoSdefense mechanism should meet. These require-ments are listed as follows.

Discrimination: The ability of discriminatinglegitimate packets from attacking packets isconsidered the first fundamental requirementof a DDoS defense mechanism. In fact, this isa very challenging problem. Specifically, sincemost of current DDoS attack tools generate

spoofed IP packets, the ability to identifyspoofed IP packets becomes a key in defendingagainst DDoS attacks in which spoofed IPpackets dominate a significant share of attacktraffic.

Lightweight: The defense of DDoS mechanismshould not impose substantial load on both theInternet routing infrastructure and the victim.It is clear that heavy load imposed on Internetcore routers will seriously affect the through-put of these routers. For instance, complexpacket filtering operations should not be in-volved on the path of packet forwarding oncore routers. Moreover, the load on victimsshould also be lightweight. Otherwise, thedefense mechanism itself will become vulner-able to DDoS attacks.

Loose cooperations: The defending schemeshould avoid the assumption that tight co-operation is required among ISPs. This isbecause cooperation normally requires com-plex coordinations among ISPs and thereforeincurs substantial overhead. This will makedeployment of the DDoS defense mechanism

difficult in large networks, such as the Inter-net.

Incremental deployment: A defense mecha-nism should be incrementally deployed if itrequires enhancements on network entities,such as routers. It is unrealistic to assume thatall the enhancements can be achieved at the

same time. The incremental deployment prop-erty allows the defense to gradually gain itseffectiveness with respect to the degree ofdeployment.

Accuracy: An effective DDoS countermeasureshould be accurate, in terms of low falsepositive ratio and low false negative ratio.Low false positive ratio refers to that thedefense should not lead to significant collateraldamage to legitimate traffic, and low falsenegative ratio means that only a negligibleportion of attack traffic is undetected. Moreimportantly, accuracy must be maintained all

the time even when the DDoS defense mech-anism is under attacks launched by attackerswho possess reasonable and sufficient resour-ces, such as a complete topological map of theInternet and the IP addresses of the Internetrouters. Attackers would try all the possibilitiesto circumvent the defense such that (1) attacktraffic can circumvent detection and filteringmechanism, or (2) the defense mechanism willbe deceived into misjudging legitimate packetsas malicious ones. Thus, it is important fora DDoS defense mechanism to resist sophisti-

cated attacks and keep its accuracy under allcircumstances.

To defend against DDoS attacks, many counter-measures have been proposed in the literature inrecent years. (These DDoS defense mechanismsare reviewed in Section Related work.) Most ofthese schemes (Belenky and Ansari, 2003; Bellovinet al., 2003; Dean et al., 2002; Keromytis et al.,2002; Keromytis et al., 2004; Kung et al., 2002;Kung et al., 2003; Li et al., 2001; Ioannidis andBellovin, 2002; Mahajan et al., 2002; Mirkovicet al., 2002; Sanchez et al., 2001; Savage et al.,2000; Savage et al., 2001; Snoeren et al., 2001;Snoeren et al., 2002; Song and Perrig, 2001) aresomewhat weak against DDoS attacks in largenetworks, such as the Internet. Some of themrequire supports from all edge routers and com-plex cooperation among different ISP networks,while others do not provide real time response toan attack. Non-trivial packet filtering operationsare usually involved in the process of packetforwarding. Thus, the throughput of routers, whichparticipate in the defense of DDoS attacks, will be

572 F.-Y. Lee, S. Shieh
http://-/?-http://-/?-


3/16

significantly reduced. Other schemes (Jin et al.,2003; Peng et al., 2002; Peng et al., 2003; Sung,2002; Sung, 2003; Yaar et al., 2003) suffer fromtheir inherent design weaknesses. For instance,they are vulnerable to sophisticated DDoS attacks,unable to distinguish DDoS attacks from flashcrowd events, or are not effective under spoofed

DDoS attacks.To effectively detect and filter spoofed DDoSattacks, we propose a new anti-DDoS scheme,called ANTID. ANTID focuses on the identificationof spoofed IP packets and the filtering of attackpackets when a DDoS attack occurs. By weedingout spoofed IP packets constituting a dominantshare of DDoS attack traffic, DDoS attackers areforced to use real source IP addresses in attackpackets. This allows packet filtering mechanismsto discard packets according to their source IPaddresses. Moreover, sophisticated resource man-agement schemes can be used in conjunction with

the proposed scheme to sustain the quality ofprotected Internet services.

Our scheme is inspired by hop-count filteringscheme (Jin et al., 2003) and path identificationscheme (Yaar et al., 2003). In the proposedscheme, each Internet router participating in thedefense of DDoS attacks deterministically markseach incoming IP packet such that every IP packetcan arrive at its destination along with a unique path fingerprint representing the route it hastraversed. (In the context of this paper, routersthat participate in DDoS defense mechanisms are

referred to as participating routers.) As we shallsee shortly in Section Related work, though thereare other approaches attempting to createa unique path identifier for each Internet path,they are somewhat weak in defending againstsophisticated DDoS attacks. Our approach pro-posed a new method to create such a uniqueidentifier and can resist those sophisticatedattacks.

Since a spoofed IP packet is unlikely to havea path fingerprint identical to that of the source IPaddress being spoofed, a destination host canidentify a majority of spoofed IP packets and thendiscard these packets when it is under spoofedDDoS attacks. From this point of view, establishingthe mapping table, which contains the mappingsfrom communicating peers IP addresses to theircorresponding path fingerprints, is essential for theeffectiveness of our approach. Theoretically, itseems that the mapping table should contain themappings of all live IP addresses so that an Internetserver under attacks can judge IP packets sentfrom every possible IP addresses on the Internet.However, from a practice perspective, it is usually

unnecessary to do so since the set of IP addresseswhich frequently visits a normal site usually takesa relatively small portion of all live IP addresses(Jung et al., 2002; Peng et al., 2003). At the sametime, building such a mapping table containingonly frequently contacted clients will greatly re-duce the storage requirement and lookup time of

an Internet server. Thus, in addition to the pro-posed scheme for identifying/filtering spoofed IPpackets with path fingerprints, we give an efficientmethod that enables an Internet server to con-struct and update the database in an on-demandfashion. In this way, a mapping of an IP address iscreated or updated only when the Internet serverreceives an IP packet from the IP address or whenthere are changes on the Internet path betweenthe server and the IP address.

There are two execution modes in the pro-posed scheme, namely monitor mode and filtermode. By default, the proposed scheme stays in

the monitor mode. In this mode, the proposedscheme collects and updates the path finger-prints of clients who want to connect to theprotected Internet server. No spoofed packet isdiscarded in this mode. However, once the rateof spoofed packets received exceeds a pre-defined threshold, the proposed scheme switchesto the filter mode. In the filter mode, spoofedpackets and IP packets sent from infrequentlycontacted clients (that is, clients whose IPaddresses and correspondent path fingerprintsare not yet recorded) are discarded to guarantee

service quality to frequent clients.ANTID has the advantages of strong incrementaldeployment property, lightweight processing loadfor marking, decoding and filtering, and strongincentive of deployment. It does not requirecooperations between ISP networks, and the fil-tering of spoofed DDoS packets is performed ona per packet basis. ANTID also possesses otheruseful characteristics that are not present in otherschemes (Jin et al., 2003; Yaar et al., 2003). First,it can maintain high accuracy (i.e. low falsenegative ratio and low false positive ratio) evenwhen under a sophisticated DDoS attack (Detailswill be presented in Section New attacking tech-nique.). Second, it can differentiate Internet pathsin which the last 8 or 16 routers are identical.Third, the proposed scheme works well even whenattackers are near the victim (in terms of numberof hops) and conventional schemes cannot workwell. According to the experiment results, ANTIDcan identify 99.95% spoofed packets. Experimentresults also indicate that the higher an aggregatedattack rate is, the sooner the attack can bedetected.

Defending against spoofed DDoS attacks 573


4/16

Note that ANTID is designed to defend againstDDoS attacks which mainly consisted of spoofedpackets. Other types of DDoS attacks, such asDistributed Reflector DoS (DRDoS) is out of thescope of this paper. In a DRDoS attack, the attackpackets sent to the victim server are generally notspoofed and can be handled by conventional

schemes. In this case, DRDoS victim will notdirectly benefit from ANTID. However, since thepackets for triggering a DRDoS attack (the packetsdelivered to the reflectors) are generally spoofed,our approach can detect the spoofed packets, andmake it very difficult for attackers to collecta sufficiently large number of reflectors. In otherwords, with a wide deployment of our scheme, theDRDoS attack can also be hampered.

The paper is organized as follows. SectionRelated work reviews the conventional DDoS de-fense mechanisms. Section New attacking tech-nique presents a new attack that can circumvent

conventional DDoS defense schemes. Section Pro-posed scheme presents the details of the proposedpath fingerprint scheme. Section Robustnessagainst circumvention analyzes the robustness ofour approach against attacks. Section Evaluationpresents experimental results and this paper con-cludes with the last section.

Related work

Many DDoS defense mechanisms have been pre-

sented in the literature recently. These schemescan be roughly categorized into four classes:attacker-end based, network-based, victim-endbased, and hybrid. The attacker-end based ap-proaches (Li et al., 2001; Mirkovic et al., 2002)attempt to identify DDoS attack traffic or spoofedIP packets at attack sources. Once DDoS attacktraffic or spoofed packets are detected, proactivefiltering mechanisms are activated to stop attacktraffic from entering the Internet. Although theseapproaches can effectively reduce network con-gestions caused by attack traffic, their effective-ness of defending against DDoS attacks heavilydepends on the wide deployment on the Internet.Moreover, the lack of incentive for installing de-fense mechanisms at sources and the shortage ofincremental deployment property will weaken thefeasibility of these approaches in large networks,such as the Internet.

The network-based approaches count on Inter-net routers to defend against DDoS attacks ina cooperative manner. Schemes in this categoryperform either the traceback of the attack trafficor complex filtering operations on routers. IP

traceback schemes (Belenky and Ansari, 2003;Bellovin et al., 2003; Dean et al., 2002; Sanchezet al., 2001; Savage et al., 2000; Savage et al.,2001; Snoeren et al., 2001; Snoeren et al., 2002;Song and Perrig, 2001) focus on identifying theorigins of spoofed DDoS attacks, rather thanstopping these attacks. Thus, it does not provide

immediate help to victims when an attack occurs.On the other hand, the on-line filtering mecha-nisms (Ferguson et al., 2000; Keromytis et al.,2002; Keromytis et al., 2004; Kung et al., 2002;Kung et al., 2003; Li et al., 2001; Ioannidis andBellovin, 2002; Mahajan et al., 2002) can immedi-ately alleviate the syndrome of DDoS attacks.However, all these schemes require significantenhancements to the current routing infrastruc-ture, non-trivial filtering operations involved in thepacket forwarding process and complex coopera-tion among different ISP networks. These require-ments may increase the difficulty in deploying

these schemes, and thus, they may not be putinto practice in the near future.

The victim-end approaches (Jin et al., 2003;Peng et al., 2002; Peng et al., 2003) try to enhancethe resilience of Internet servers against DDoSattacks. The advantages of the victim-end ap-proaches are that they do not require supportfrom the Internet routing infrastructure and thatthey strongly motivate the victim to deploy theseschemes owing to the direct benefit to the victimitself. These schemes exploit essential character-istics of spoofed DDoS attacks in designing their

DDoS countermeasures. That is, the source IPaddresses of spoofed DDoS attack packets areusually spoofed randomly. In some schemes (Jinet al., 2003), spoofed DDoS packets are identifiedaccording to the hop-count information, whichrefers to the number of routers traversed in anInternet path. The effectiveness of hop-countfiltering is based on the assumption that mostspoofed IP packets do not have hop-count valuesidentical to those of IP addresses being spoofed. Byinferring the hop-count information from the TTLfield, spoofed IP packets can be easily identifiedand then be discarded when the victim is underattack. However, this assumption is somewhatweak. By observing network traffic or using trace-route technique, a DDoS attacker can obtain thehop-count value between the victim and a spoofedIP address. Thus, hop-count filtering is likely to becompromised by sophisticated DDoS attacks thatcan adjust the initial TTL value according to thecollected hop-count information.

Based on the 32-bit source IP address, an IPfiltering technique for defending against DDoSattacks is proposed (Peng et al., 2002;



5/16

Peng et al., 2003). In this approach, the number ofnew IP addresses connecting to the protectedserver is monitored, and IP addresses of frequentlycontacted clients are learned from past communica-tions. A surge in the number of new IP addresses isconsidered as a signal of the onset of a spoofedDDoS attack. Then, packets with source IP ad-

dresses not found in the IP address database willbe discarded during the attack. This approachsuffers from several drawbacks. First, it cannotdistinguish flash crowd events from real spoofedDDoS attacks. Second, before launching a realDDoS attack, an attacker can slowly pollute theIP address database of the victim by sending thevictim a set of malicious packets with an IP addressto be spoofed. Then, the attacker can use those IPaddresses used before to attack the target. Al-though it is indicated (Peng et al., 2003) that suchan attack can be prevented by increasing theperiod over which IP addresses must appear to be

considered frequent, this approach, on the otherhand, will exclude some legitimate clients fromthe IP address database. Subsequently, the num-ber of legitimate clients allowed to access theservice is reduced. In other words, the effective-ness of defending against spoofed DDoS attacks isnot significant since some frequent clients may beprohibited from accessing the protected service.

Schemes in the fourth category can be consid-ered a hybrid of network-based and victim-basedapproaches. These schemes require support fromthe Internet routing infrastructure and from the

victim or victim network. In these schemes,routers mark each incoming IP packet in a de-terministic or probabilistic manner. Then, in vic-tims or victim networks, attack packets areidentified and discarded on a per packet basisaccording to marks left by Internet routers (Sung,2002; Sung, 2003; Yaar et al., 2003). An IP trace-back method is employed to construct the attackgraph, and subsequently IP packets marked withone of network edges in the attack graph arediscarded (Sung, 2002; Sung, 2003). This schemesuffers from the large number of packets requiredto construct the attack graph. And, it may mis-classify legitimate packets as attack packets iflegitimate packets ever traversed the networkedge in the attack graph.

In another scheme (Yaar et al., 2003), eachparticipating router marks some bits (one or twobits) in the Identification field of an IP packetaccording to the routers IP address and the TTLvalue in the IP header. In this way, an IP packet willarrive at its destination along with a unique iden-tifier representing the path it has traversed. Sincethe marking is deterministic, packets traversing

the same path will share an identical path identi-fier. With this scheme, the path identifier ofa single identified attack packet will provide thevictim the ability to filter subsequent attackpackets with the same path identifier. However,the motivation of using this approach is unclear.Since the victim is capable of detecting a single

attack packet, the reason for not using the samedetecting facility to detect subsequent attackpackets is not mentioned. Moreover, consider thatpackets traversed the same last 8 routers beforethey enter the Autonomous System (AS) at whichthe victim resides, the victim will not be able todistinguish these packets since their path identi-fiers are identical (in the case of each router markstwo bits in the Identification field). As a result, IPpackets of legitimate clients that traverse thesame last 8 routers with attack packets will bediscarded. Furthermore, consider a special casewhere the number of participating routers be-

tween an attack and the victim is smaller then 8.The attack can partially pollute the attack marklist, which represents the marks of attack packets.It is because, in this case, some bits in theIdentification field are under the control of theattacker and remain unmarked throughout the path.This may result in mis-classifying a large portionof legitimate packets as attack ones. Finally, thisscheme cannot handle DDoS attacks originatedfrom the AS in which the victim resides, sincethe marking operation is suppressed on routers inthe AS.

New attacking technique

In this section, we propose a new attackingtechnique that can be used to circumvent hop-count-filtering approach. Specifically, we will il-lustrate using IP SOURCEROUTE option and ICMPecho-request/echo-reply messages to explore thelist of intermediate routers between two remotesystems. In this way, an attacker will obtain thehop-count information that is sufficient to dodgehop-count filtering.

We will first give a scenario for obtaining thehop-count information between two remote hosts.Later on in this section, a concrete example will bedemonstrated to show the feasibility of this sce-nario. Fig. 1 depicts a simple spoofed attackscenario that an attacker A attempts to sendspoofed IP packets to a victim V, with source IPaddress S. To dodge the hop-count filtering mech-anism installed at V, the attacker A must acquirethe number of intermediate routers between S andV. To achieve this objective, A must first obtain the



6/16

IP address of the default gateway of S, i.e. the IPaddress of R2. (Here, it is assumed that an Internethost has the same default gateway for both in-bound and outbound traffic. In other words, theingress and egress routers of an Internet host areidentical.) As shown in step (1) of the figure, A can

easily obtain the IP address of R2 by using tracer-oute to obtain the list of routers between A and S.Next, as shown in step (2), to acquire the numberof hops between S and V, A can issue anothertraceroute command to explore the list of routersbetween itself and V. By setting the IP SOURCE-ROUTE option on, traceroute packets are forced totraverse R2, and A can successfully obtain thenumber of intermediate routers and their IPaddresses between S and V.

To illustrate the feasibility of the scenariopresented above, an example of exploring the listof routers between two remote sites is demon-strated. The following example is conducted byusing the traceroute program in FreeBSD 5.0. Inthe following example, A stands for 140.113.209.21 and S stands for 140.112.2.100. Then,

V is 140.113.216.190. First, the attacker in140.113.209.21 explores the default gatewayof 140.112.2.100 by issuing the command trace-route 140.112.2.100. Fig. 2(a) shows the result ofthis command, and according to this figure, the IPaddress of the default gateway of S is 140.112.1.13. Afterwards, the attacker issues anothertraceroute command: traceroute -g 140.112.1.13 140.113.216.190, and the correspondent re-sult is shown in Fig. 2(b). By comparing the twotraceroute results, the attacker can easily findthat the number of hops between the two host is 9.Consequently, the attack can successfully dodge

the hop-count filtering mechanism by setting anappropriate initial TTL value in the IP packetheader.

The aforementioned example shows that hop-count filtering is vulnerable to sophisticated DDoSattacks that can explore the hop-count informa-tion between the victim and spoofed IP addresses.Thus, developing a new technique for defendingagainst sophisticated spoofed DDoS attacks isneeded.

A R1 Internet

(1) R2

S

(2)R3

V

Figure 1 A two-step scenario for remotely exploringthe number of hops between two end hosts.

(a) (b)

> traceroute -n -q 1 140.112.2.10

traceroute to 140.112.2.100

(140.112.2.100), 64 hops max, 44 byte

packets

1 140.113.209.254 0.327 ms

2 140.113.0.210 0.200 ms

3 140.113.0.166 0.228 ms

4 140.113.0.98 0.238 ms

5 192.83.196.111 1.581 ms

6 203.72.43.210 1.537 ms

7 203.72.43.252 1.712 ms

8 140.112.1.29 1.780 ms

9 140.112.1.13 1.669 ms

10 140.112.2.100 1.681 ms

> traceroute -n -q 1 -g 140.112.1.13

140.112.216.190

traceroute to 140.113.216.190

(140.113.216.190), 64 hops max, 52

byte packets

1 140.113.209.254 13.651 ms

2 140.113.0.210 4.727 ms

3 140.113.0.166 3.450 ms

4 140.113.0.98 2.490 ms

5 192.83.175.111 2.144 ms

6 203.72.43.210 2.553 ms

7 203.72.43.252 2.243 ms

8 140.112.1.29 2.385 ms

9 140.112.1.13 3.078 ms

10 140.112.1.14 2.490 ms

11 140.112.1.114 2.889 ms

12 203.72.43.254 3.179 ms

13 203.72.43.209 3.046 ms

14 192.83.196.113 2.898 ms

15 140.113.0.97 2.854 ms

16 140.113.0.165 3.786 ms

17 140.113.0.209 3.105 ms

18 140.113.216.190 3.453 ms

Figure 2 (a) An example of determining the default gateway of an IP address being spoofed, and (b) an example ofenumerating the list of routers between a spoofed source and the victim.



7/16

Proposed scheme

In this section, we propose a new spoofed packetfiltering anti-DDoS scheme, called ANTID. In thisscheme, each IP packet is embedded with a unique path fingerprint representing the route an IPpacket has traversed, and IP packets with incor-

rect path fingerprints is considered spoofed. Theproposed scheme eliminates some weaknesses ofconventional schemes, and is designed specificallyfor defending against spoofed DDoS attacks. Itintends to complement, rather than replace exist-ing schemes.

The basic of ANTID is the validation of an IPpacket via its source IP address and the pathfingerprint embedded in it. In this section, thecomputation of a path fingerprint is first described,and then the inspection algorithm for identifyingspoofed IP packets is presented. Next, an efficientapproach for constructing a table that contains themappings of IP addresses and their path finger-prints is proposed. Finally, the details of detectinga spoofed DDoS attack are shown, and subsequentpacket filtering operations are examined.

Path fingerprinting and spoofedpacket inspection

To generate a path fingerprint representing theroute an IP packet traversed, it is assumed thateach participating router assigns each of its net-

work interface a n-bit random number, and theserandom numbers are kept securely. These numbersshould not be disclosed. In ANTID, a path finger-print of an IP packet is composed of two fields, ad-bit distance field and a n-bit path identification(PID) field, where the former represents thenumber of intermediate routers traversed, andthe latter denotes an identifier derived from therandom numbers associated with the traversednetwork interfaces in the route. The path finger-print of an IP packet is stored in the IP packetheader, and thus it is delivered to the destinationhost along with the packet. Moreover, we alsoassume that a pf-flagbit in the IP packet header isavailable for indicating the start of path finger-printing. Later in this section, we will discuss theallocation of (1C dC n) bits in the IP packetheader fields.

The path fingerprinting procedure is presentedas follows. Whenever a participating router re-ceives an IP packet, it first examines the pf-flagfield. If it is unset, i.e. 0, the receiving router isthen aware that it is the first participating routerthe packet encountered in the path. In this case,

the receiving router sets the pf-flag bit to 1, setsthe distance field to 1 and sets the path identifi-cation field to the random number associated withthe incoming interface of the packet. On the otherhand, if the flag bit is already on, i.e. 1, thereceiving router increments the distance field byone, and updates the path identification field with

H(PID, Ni), where PID represents the current valueof path identification field in the packet, Nidenotes the random number of the incominginterface, and H is a one-way hash function withweak collision resistance. (Note that H is nota secret and each participating router can chooseits hash function.) Algorithm 1 shows the pseudo-code for computing path fingerprint on a partici-pating router, and Fig. 3 illustrates an example ofthe path fingerprinting scenario.

In the example depicted in Fig. 3, a packettraverses from the source S to the destination Dacross routers R1eR4. The first router in the path,

R1, sets both pf-flag and distance filed to 1 andsets the initial PID value to the random number ofthe incoming interface, i.e. N1. Afterwards, eachrouter increases the distance field and updates thePID field according to the previous PID value andthe random number of the current incoming in-terface. In this figure, H denotes a hash function.

To allocate space from the IP packet header forstoring a path fingerprint, the 16-bit Identificationfield in the IP header is chosen to be overloaded.Issues related to the overloading of this field hasbeen studied and reported (Savage et al., 2000). In

this paper, the 16-bit Identification field is dividedinto two sub-fields. The first sub-field is 5-bit longand is used to store the value of distance. It isbelieved that 5 bits are sufficient (Carter andCrovella, 1997; Theilmann and Rothermel, 2000)since most of Internet paths are shorter than 31

Algorithm 1 Computation of path fingerprints ona participating router

1: Let p denote an incoming IP packet.2: Let p.pf-flag, p. distance and p.pid denote the

pf-flag, distance and path identification fields inpacket p, respectively.

3: Let Ni denote the random number associated withthe incoming interface of p.

4: if p.pf-flagZ 0 then5: p.pf-flag) 16: p.distance) 17: p.pid)Ni8: else9: p.distance)p.distanceC 1;10: p.pid)H(p.pid,Ni);11: end if



8/16

hops. To deal with Internet paths with more than31 hops, a simple solution is to use more bits.However, this will reduce remaining bits for storingpath identification, and consequently increase thecollision rates. To avoid increasing hash collisions,in our scheme, we choose to stop increment thedistance field when its value reaches 31. Though inthis case, Internet paths that have more than 31routers supporting our scheme will have the samedistance values; the path identification field canstill help distinguish them if their path identifica-

tions are different. The remaining 11 bits of theIdentification field are used to store path identifi-cation. Finally, we propose to use the un-used bitof the FLAG field in IP header to store the value ofthe pf-flag bit.

In this way, filtering of spoofed IP packets willbe quite straightforward if the table that containsthe mappings of IP addresses and their pathfingerprints is present. In the following context ofthis paper, the table is referred to as S2PF(abbreviation of Source to Path Fingerprint) table.Here, we first assume that the S2PF table isavailable, and its construction will be discussed

later.Algorithm 2 shows the pseudo-code for identi-

fying spoofed IP packets. In this algorithm, thesource IP address and path fingerprint of an IPpacket are extracted from the IP packet headerfirst. Next, by using the extracted source IPaddress, the correspondent path fingerprint canbe retrieved from the S2PF table. If the pathfingerprint of the given IP address cannot be found

in the S2PF table, the algorithm returns UN-KNOWN. Otherwise, the algorithm compares thetwo path fingerprints. (One from the IP packet andthe other from the S2PF table.) If they areidentical, the algorithm returns LEGITIMATE, orelse, it returns SPOOFED.

Notice that the inspecting algorithm only de-termines whether a given IP packet is spoofed ornot. Weeding out spoofed packet is not performedby ANTID alone. This is because the inspectingalgorithm may mis-classify legitimate packets as

spoofed ones when an out-of-date S2PF table is inuse. (A S2PF table will become out-of-date whenthere are topological changes in the Internet, ora participating router re-assigns random numbersto its network interfaces.) To avoid errors causedby an obsolete S2PF table, spoofed packets willonly be discarded after a DDoS attack signal iscaught by ANTID.

The construction and update of theS2PF table

As mentioned previously, there are two executionmodes in the proposed scheme, namely monitormode and filter mode. In the monitor mode, theS2PF table is constructed, and its entries will beupdated if there are changes in the topology ofInternet or in the Internet paths due to dynamicrouting. Notice that, ANTID does not attempt tobuild a S2PF table containing all live IP addresses.Instead, the S2PF table should only have entriesfor IP addresses that ever connected to thedestination in the past communications. It isbelieved that S2PF constructed in this way issufficient enough because, according to the report(Jung et al., 2002), the source IP addresses ofa given site in normal conditions only take a smallset of values. Thus, in ANTID, a new S2PF tableentry will be added if the destination host receivesIP packets from a new IP address. This allowscontrolling the size of the S2PF table at a manage-able level, and, at the same time, reducing thetime for searching.

There are different ways to learn the mapping ofan IP address and its path fingerprints from com-munications. One naive approach is to learn the

0

S R1N1 N2

H H H

1 1 PID1 PID2 PID3 PID4 PID41 1 12 3 4 1 4

DN4

R4N3

R3R2

distance

pf-flagPID

Figure 3 An example of the proposed path fingerprinting scheme.

Algorithm 2 Spoofed packet inspection

1: Let src denote the source IP address and pfdenote the path fingerprint of a given IP packet.

2: Retrieve the path fingerprint, pfs2pf indexed bysrc in the S2PF table.

3: if No entry indexed by src found then4: Return UNKNOWN5: else if pfs2pfspf then6: Return SPOOFED7: else8: Return LEGITIMATE9: end if



9/16

mappings simply from received IP packets. When-ever an IP packet with a new source IP addressarrives, a new entry is inserted into the S2PF table.Similarly, the arrival of an IP packet that carriesa new path fingerprint different from the onealready stored in the S2PF table would result inan update on the correspondent S2PF entry. In this

way, constructing a S2PF table is quite straightfor-ward, however, it is clear that this naive approachwill not work for identifying spoofed packets sinceno validation process is involved. A more compli-cated method is to learn the mappings fromestablished TCP connections. Since it is verydifficult to spoof source IP addresses in TCP con-nections, the validity of mappings learned in thisway is ensured. However, this method is notappropriate for Internet servers that do not runTCP-based services. Herein, we suggest a simpleand generic method to obtain the mappings in anefficient and robust manner. That is, the path

fingerprint of a specific source IP address is explic-itly explored by the use of ICMP echo-requestmessages. Before an entry of a new source IPaddress can be inserted into the S2PF table or anupdate can be made, the destination host sends anICMP echo-request message to the source IP ad-dress. Then, the path fingerprint in the returnedICMP echo-reply message is treated as the most up-to-date path fingerprint of that source IP address. Itis worthy to note here that traceroute packetsmight be blocked for security reasons. Thus, analternative way is to use the ICMP port unreachable

message and the TCP RST message. Specifically, thedestination host can send a UDP packet to thatspecific source IP address and the source portnumber and destination port number can be setarbitrarily. In this case, it is very likely that noprocess is serving on that destination port, and thusan ICMP port unreachable message will be sentback to the server. In that ICMP packet, the victimserver can learn the path fingerprint between itselfand the specific host. Similarly, sending a TCPpacket with randomly created destination portnumber can be used to accomplish the sameobjective. The corresponding TCP RST packet willcarry the path fingerprint. No matter which ap-proach is taken, the S2PF table, constructed in thisway, will contain only correct mappings of legiti-mate clients.

There are two main reasons for invoking explo-ration of the path fingerprint of a specific IPaddress. The first refers to the arrival of an IPpacket with a new IP address. The second directsto the necessity of updating a S2PF table entry.Consider the first case when the packet from a newclient arrives. In this case, the spoofed packet

detection algorithm presented in Algorithm 2returns UNKNOWN, and an exploration process willbe invoked at probability q, where 0% q! 1. Inthis way, we can avoid overloading the Internetand can avoid building a S2PF table containinga large portion of infrequently contacted clients.As to the second case, although the majority of

Internet paths are expected to be stable andremain unchanged for a long period of time (Jinet al., 2003; Paxson, 1997), occasionally it is stillnecessary to update the S2PF table when therouting changes. This update function is importantto maintain an up-to-date S2PF table. In theproposed scheme, upon receipt of an IP packetthat traversed a new Internet path (assuming thatthe S2PF table has an entry for the IP address ofthis packet), the spoofed detection algorithm willclassify this packet as spoofed. Then, in this case,an exploration process will be invoked at proba-bility r, where 0% r! 1. Both q and r are used to

prevent our scheme from excessively exploringpath fingerprints by ICMP echo-request/echo-replymessages, and at the same time, we preserve theability to insert and update entries in the S2PFtable.

Since a S2PF table cannot accommodate themappings of all possible IP addresses (there can beat most 232 entries), replacing an old S2PF tableentry with a new one is also an important issuethat needs to be addressed. Whenever a replace-ment is needed, we currently recommend thatseveral cache replacement techniques, such as

Least Frequently Used (LFU), Least Recently Used(LRU) and Most Frequently Used (MFU), can beused. However, in this paper, we do not makedefinitive claim that which replacement techniqueis the best for the S2PF table entry replacement,and determining the best replacement policywarrants further research.

Finally, in ANTID, the number of spoofed pack-ets received is used as a criterion to determine theonset of a spoofed DDoS attack. Thus, in themonitor mode, whenever an exploration processis invoked owing to receipt of a new IP address, thereturned path fingerprint is compared with thepath fingerprint stored in the IP packet. If they arenot identical, a counter spoofing-cnt, which re-cords the number of spoofed packet received inone unit of time, will be increased by one.Similarly, whenever the inspecting algorithm re-turns SPOOFED, the spoofing-cnt is also incre-mented by one unless the exploration processreturns an path fingerprint identical to the one inthe IP packet. Algorithm 3 shows the pseudo-codefor the construction and update of the S2PF tablein the monitor mode.



10/16

State transitions and spoofed packetfiltering

As mentioned, the number of spoofed packetsreceived is used as a criterion for transitionbetween the monitor mode and the filter mode.In the proposed scheme, the time is divided intoa set of uniform time intervals. At the beginning ofeach time interval, the spoofing-cnt, which re-cords the number of spoofed packet in the pre-vious time interval, is examined. If the value ofthis counter exceeds a threshold T1, ANTIDswitches to the filter mode. In the filter mode,spoofed packets and packets with source IP ad-dresses absent in the S2PF table are discarded.The proposed scheme switches from the filtermode to monitor mode when IP spoofing ceases.This is achieved by examining the spoofing-cnt. Ifthe value of this counter is smaller than anotherthreshold T2, ANTID switches back to the monitormode. In this paper, we provide only a general

guideline commonly used in threshold schemes forsetting the two thresholds. The basic principle is tolet T1O T2. It is clear that this can prevent ANTIDfrom alternating between the two executionmodes. Another important concern is that T1should be set appropriately such that the victimserver will not falsely switch into the filter mode.

Switching to the filter mode too easily may lead toanother form of DoS attack because, in the filtermode, the victim server only serves previouslyvalidated clients.

As to the problem of setting the specific valuesof these parameters, such as q, r, T1 and T2, werecommend that they should be configurable byadministrators of the Internet servers. Theseparameters are highly application-dependent, thatis, it is largely relied on administrators to de-termine their own best trade-off between theperformance and security of the protected sites.Herein, we only briefly enumerate some factors

related to the setting of these parameters. First, qis related to definition of a frequent visitor, qcan be set to 1/10 if a user is considered a frequentuser when the user visits the protected site formore than 10 times. Second, r highly depends onthe dynamics of Internet topology. Though Inter-net paths were found to be persistent for days, theInternet topology is assumed to change dynami-cally. Further investigation on the dynamics of theInternet is needed to provide hints for setting rappropriately. As for T1 and T2, their values highlydepend on the number of spoofed packets the

protected site can tolerate in each time interval.For instance, consider an Internet server whoseaverage packet arrival rate is about 5000 packetsper second. Then, T1 can be set as 2500 (about the1/2 of the average number of packets), and T2 canbe set as 500 (about the 1/10 of the averagenumber of packets). Such settings would be usefulin detecting large scale of spoofed DDoS attacksthat attempt to flood the protected site withspoofed packets.

Algorithm 4 shows the pseudo-code of statetransition, and Algorithm 5 presents the pseudo-code of spoofed packet filtering in the filter mode.

Robustness against circumvention

In this section, we present possible approachesthat a DDoS attacker may take to circumvent theproposed DDoS defense mechanism and show thatour scheme is robust against these attacks. Thekey for an attacker to circumvent spoofed packetdetection is the ability to generate attack packetsin accordance to the constraint that they can

Algorithm 3 The construction and update of theS2PF table

1: Let p denote the incoming packet.2: Let p.src and p.pf denote the source IP address

and the path fingerprint stored in the packetheader of p.

3: Status) Spooflnspection(p).

4: if StatusZ UNKNOWN then5: Let x be a random number from [0,1).6: if x! q then7: Invoke the path fingerprint exploration process.8: Insert a new table entry of p.src into S2PF table.9: Let p.pfnew denote the newly acquired path

fingerprint of p.src10: if p.pfnewsp.pf then11: Classify packet p as spoofed12: spoofing-cnt) spoofing-cntC 113: end if14: end if15: else if StatusZ SPOOFED then16: Let x be a random number from [0, 1)

17: if x! r then18: Invoke the path fingerprint exploration

process.19: Update the entry of p.src with newly acquired

path fingerprint.20: Let p.pfnew denote the newly acquired path

fingerprint of p.src21: if p.pfnewsp.pf then22: spoofing-cnt) spoofing-cntC 123: end if24: else25: spoofing-cnt) spoofing-cntC 126: end if

27: end if



11/16

finally arrive at the victim along with path finger-prints consistent with the spoofed IP addresses.In the following, we examine two types ofapproaches to achieve this objective.

Simple attack: The simplest approach is to setrandom initial values in both the path finger-print field and the source IP address field.Notice that an attacker cannot seed thefingerprint field of attack packets in sucha way that the fingerprint of the attack packetswill arrive at the victim server along witha correct path fingerprint. This is because thevalue in the path fingerprint field will bechanged securely. Without knowing all therandom numbers associated with the traversedlinks, the attacker has no knowledge of thecorrect seed. In other words, since the randomnumbers associated with network links are keptsecurely, it is very difficult for an attacker tocontrol path fingerprint received by the victim.Thus, the best an attacker can do is to setrandom seed in the fingerprint field and thesource IP field. However, this approach isinfeasible since it is very unlikely that therandomly spoofed source IP address will exist inthe S2PF table at the destination host or thatthese attack packets can arrive at the desti-nation along with a correct path fingerprint.

The probability for a match is 1/2(dC n)

(in our

scheme, (dC n)Z 16). Next, consider a moresophisticated case where an attacker cancarefully select a spoofed IP address and canset an appropriate value in the distance field(setting an appropriate initial value in thedistance field can be achieved by using thetechnique presented in Section New attacking

technique). In this case, only very few attackpackets can pass the spoofed packet detection.It is because that the best an attacker can do isto fill the path identification field with a ran-dom value and only then the fraction 1/2n (inour scheme, nZ 11) of attack packets canarrive at the destination along with a correctpath identification value. In short, such a sim-ple attack is not useful to dodge the proposedscheme.

Detour attack: As we have shown in SectionNew attacking technique, an attacker candetermine the default gateway of a spoofed

IP address. Thus it is reasonable to assumethat an attacker can force attack packets totraverse the default gateway of the spoofed IPaddress by using IP SOURCEROUTE option. Inthis way, the postfix of the attack path will beidentical to the path from the spoofed sourceto the victim. This type of attack is referredto as detour attack. The success of a detourattack relies on the following mandatoryconditions: there must not exist any partici-pating router in the path from the attacker tothe spoofed IP address (including the default

gateway of the spoofed source). If thiscondition holds, an attacker can successfullyconduct a spoofed DDoS attack by using thedetour technique presented here. In this case,the victim cannot identify spoofed attackpackets since the path fingerprints of thesepackets are correct. Although this type ofattack allows an attacker to dodge pathfingerprint filtering, finding an appropriatespoofed source is very difficult if the partici-pating routers are widely distributed over theentire Internet. Moreover, the victim caneasily stop attack packets of a detour attackby filtering IP packets with IP SOURCEROUTEoption set.

According to the above analysis, we can findthat both the simple attack and the detour attackare ineffective. Furthermore, from a probabilitypoint of view, in the simple attack, attack packetscan bypass the spoofed packet detection at prob-ability of 1/211 (later on we will confirm this byexperiments). In summary, the proposed scheme isrobust against circumvention.

Algorithm 4 The transition between monitor andfilter modes

1: In the begin of each time interval2: if current execution modeZmonitor then3: if spoofing-cnt > T1 then4: switch to filter mode5: end if

6: else7: if spoofing-cnt!T2 then8: switch to monitor mode9: end if10: end if11 : spoofing-cnt) 0

Algorithm 5 Spoofed packet filtering

1: Let p denote an incoming IP packet.2: StatusZ SpoofedInspection(p)3: if StatusZ SPOOFED or UNKNOWN then4: Drop the packet p5: spoofing-cnt) spoofing-cntC 16: end if



12/16

Evaluation

In this section, we evaluate the accuracy of theproposed scheme in the identification and filter ofspoofed packets under DDoS attacks. We simulatethe aggregate of DDoS attack traffic at differentattack rates and then present the performance

metrics that we measure.

Internet data sets

To simulate the Internet topology, the Internetmap (Cheswick et al., 2000) is used as our Internettopological data. The Internet map contains Inter-net paths (each represented as a list of routers),from a specific host to most of nets on theInternet. In our experiments, the host whichoriginates these traceroute-style path probes isviewed as the victim of a DDoS attack, andattackers and legitimate clients are randomly

selected from those hosts at the end of eachtraceroute path.

Fig. 4(a) depicts the distribution of number ofintermediate routers on each completed Internetpaths. There are in total 24,772 Internet paths.(We exclude incomplete traceroute probes fromour experiments.) As the figure shows, only a fewInternet paths consist of more than 32 intermedi-ate routers, and the most popular path length is16. Fig. 4(b) shows the distribution of the pathidentifications of these Internet paths. Theoreti-cally, since the numbers associated with network

interfaces are randomly assigned, the path identi-fications of Internet paths should also be random,and Fig. 4(b) confirms this theoretical inference.

Experimental design and performancemetrics

In the experiments, 500 end hosts are randomlyselected from the Internet map to act as frequently

contacted clients of an Internet server. Then,a S2PF table which contains the source to pathfingerprint mappings of the 500 clients is con-structed. Moreover, we set q to 1/10, r to 1/100and T1 to 2500. Notice that, in our experiments,we do not attempt to find a best suite of values ofthese configurable parameters for a specific net-

work environment. (As indicated in Section Pro-posed scheme, the setting of these parametersheavily depends on both specific characteristics ofdeployed networks and the trade-off betweensecurity and performance. Thus, we do not focuson this issue in this paper.) Instead, other behav-iors, such as the growth rate of the S2PF table andthe false negative ratio at the monitor mode andthe filter mode, are explored under various attackrates.

First, we measure the false negative ratio of theproposed scheme before and after it switches frommonitor mode to filter mode. Herein, the false

negative ratio refers to the ratio of undetectedspoofed packets. In this experiment, we simulatethe aggregate of attack traffic that have 5000attack packets in each attack round. (Note thatthe growth of the number of attackers can onlyincrease the aggregation of attack traffic, butcannot increase the probability of passing theproposed filtering mechanism. Thus, we use theaggregation of attack traffic to test the proposedscheme.) A round of attack, in fact, stands fora period of time. In this paper, we do not imposerestrictions on setting the length of an attack

round. Instead, we are interested in the numberof rounds and the rate required to detect thepresence of a DDoS attack. Source IP addresses ofthese attack packets are randomly selected fromthe Internet map with a constraint that theseaddresses are disjoint with legitimate clients.Moreover, by the same technique presented inSection New attacking technique, we let theseattack packets carry appropriate distance values

Figure 4 The distribution of: (a) number of intermediate routers, and (b) the value of path identifications.



13/16

such that they can arrive at the victim along withconsistent distance values with the spoofed IPaddresses. As shown in Fig. 5, the false negativerate shows a tendency to decrease as the numberof rounds increases, and finally at round 3156, theproposed scheme switches to filter mode. Thus,after round 3156, the false negative ratio steeply

drops to around 1/2048. The decrease of falsenegative ratio at the monitor mode is caused bythe growth of the size of the S2PF table. Since thevictim will add a new S2PF table entry at proba-bility 1/100, about (1/100)! (number of spoofedIP addresses not in the S2PF table) new entries willbe added to the S2PF table after each attackround. At round 3156, there are in total 11,937entries (about the half of number of Internet pathsin Internet map) in the S2PF table.

As to false negatives, in our approach, legiti-mate packets will not be classified as spoofed onesin the monitor mode. They will be classified as

UNKNOWN packets, or their path fingerprints willbe inserted into the S2PF table after the finger-print exploration process. While in the filter mode,our scheme indeed will discard some legitimatepackets originated from infrequent clients whosepath fingerprints are not in the S2PF table. Thesepackets are still classified as UNKNOWN ratherthan SPOOFED. Possible cases of mis-classifyinglegitimate packets as spoofed ones are mostlycaused by changes in the Internet topology whenour scheme is in the filtering mode. In filteringmode, our scheme stops updating path fingerprints

for SPOOFED packets. Such false positives highlydepend on the dynamics of the Internet, andtherefore are not discussed in the context of thispaper.

According to the statistics on the measuredDDoS attacks, attack rates range from 500 to600,000 attack packets per second (Darmohray

and Oliver, 2000; Moore et al., 2001). In thefollowing, we will present experiments on howmany packets are needed for our scheme to detectthe presence of a DDoS attack, and please noticethat the sensitivity presented here highly dependson the settings of configuration variables. Fig. 6shows the number of rounds required to detect the

presence of a spoofed DDoS attack under threeattack rates: 50,000, 100,000 and 150,000 attackpackets per round. This figure shows that thenumber of rounds needed to detect a spoofedDDoS attack decreases as the attack rate in-creases. Next, we conduct the same experimentsat lower attack rates. In these experiments, wesend 5000, 10,000, 15,000, ., 50,000 attackpackets to the victim at each round. We observedthe growth of the S2PF table and the number ofrounds needed to detected attacks. The experi-mental result is shown in Table 1. According to thetable, we can find that the higher the attack rate

is, the fewer rounds and the fewer entries in theS2PF table are required to detect the presence ofan attack.

In summary, the experimental results showthat a higher attack rate will result in a smallernumber of rounds required to detect an ongoingspoofed DDoS attack. After the attack is de-tected, only a very small fraction (around 1/2048) of attack packets can pass the spoofedpacket detection mechanism. This shows that ourapproach can effectively detect the presence ofan attack and subsequently can weed out these

attack packets.

Conclusions and future work

In this paper, we presented an anti-DDoS scheme,ANTID, for defending against spoofed DDoS traffic.ANTID intends to complement, rather than replaceexisting schemes. For instance, the proposedscheme helps to discard spoofed packets beforeingress filters are installed on all edge routers.Furthermore, by weeding out a majority ofspoofed attack packets, our approach allows someresource management systems, that share re-source fair amount many participants, to workbetter.

In our approach, each IP packet is embeddedwith a unique path fingerprint that represents theInternet path it has traversed. By learning pathfingerprints from past traffic, the victim canefficiently establish the S2PF table which containsthe mappings of source IP addresses and corre-sponding path fingerprints of frequently contactedclients. A spoofed packet can be easily identified

Figure 5 The false negative ratio under the attackrate of 5000 packets per round.



14/16

by consulting the S2PF table since it is veryunlikely that a spoofed packet can have a pathfingerprint identical to that of the spoofed IPaddress. Thus, by identifying and filtering spoofed

packets, a spoofed DDoS attack can be identifiedand prevented. This makes the proposed schemean effective and efficient approach for defendingagainst spoofed DDoS attacks.

ANTID runs in two execution modes, the monitormode and the filter mode. We simulate DDoSattacks with variable attack rates to evaluate theperformance of our approach. Experimental re-sults showed that ANTID can provide protectionagainst spoofed DDoS attack. Only around 1/2048attack packets can pass the spoofed packet de-tection and filter mechanism when our scheme

stays in filter mode. The experimental results alsoshow that the time required to detect an attackdepends on the attack rate of aggregated attack

traffic. The higher the attack rate is, the short thetime for detecting will be. Finally, our approachpossesses several important properties, such asstrong incremental deployment and lightweight for

marking, decoding and filtering. No cooperationamong ISP networks is needed. More importantly,it is robust against sophisticated DDoS attacks, andit is resistant to the deception by nearby attack-ers. These properties make the proposed schemea general and robust approach that is feasible tobe deployed in the Internet. There are severalissues that require further investigations. For in-stance, a systematic way for configuring parame-ters, q, r, T 1 and T2, for a specific networkenvironment is required. And, an efficient ap-proach for maintaining the S2PF table is needed.

Finally, the best strategy for deploying participat-ing routers in the Internet needs to be designedand investigated.

Figure 6 The false negative ratio under the attack rates of 50,000, 100,000 and 150,000 attack packets per round.

Table 1 At different attack rates, the number of rounds and the number of table entries required to detect theattack

Attack rate 5000 10,000 15,000 20,000 25,000 30,000 35,000 40,000 45,000 50,000Table size 11,937 5928 3983 2990 2462 2037 1750 1517 1378 1243Number of rounds 3156 621 259 136 88 52 37 27 20 16



15/16

References

Belenky A, Ansari N. IP traceback with deterministic packetmarking. IEEE Communications Letters April 2003;7(2):162e4.

Bellovin S, Leech M, Taylor T. ICMP traceback messages [Online].Available from: http://www.ietf.org/internet-drafts/draft-ietf-itrace-04.txt; Feb. 2003.

Carter RL, Crovella ME. Server selection using dynamic pathcharacterization in wide-area networks. In: Proceedings ofthe IEEE INFOCOM; Apr. 1997. p. 1014e21.

CERT Coordination Center. CERTR incident note IN-99-07 distrib-uted denial of service tools [Online]. Available from: http://www.cert.org/incident_notes/IN-99-07.html ; Jan. 1999a.

CERT Coordination Center. Results of the distributed-systemsintruder tools workshop [Online]. Available from: http://www.cert.org/reports/dsit-workshop-final.html http://www.cert.org/reports/dsit-workshop.pdf; Nov. 1999.

CERT Coordination Center. CERTR advisory CA-1999-17 denial-of-service tools [Online]. Available from: http://www.cert.org/advisories/CA-1999-17.html; Dec. 1999.

CERT Coordination Center. CERTR advisory CA-2000-01 denia-l-of-service developments [Online]. Available from: http://

www.cert.org/advisories/CA-2000-01.html; Jan. 2000.Cheswick B, Burch H, Branigan S. Mapping and visualizing the

internet. In: Proceedings of USENIX annual technicalconference [Online]. Available from: http://www.usenix.org/publications/library/proceedings/usenix2000/general/cheswick.html; June 2000.

Darmohray T, Oliver R. Hot spares for DoS attacks;login[Online]. Available from: http://www.usenix.org/publications/login/2000-7/apropos.html; July 2000.

Dean D, Franklin M, Stubblefield, A. An algebraic approach toIP traceback. ACM Transactions on Information and SystemSecurity May 2002;5(2):119e37.

Dittrich D. The DoS projects trinoo distributed denial of serviceattack tool [Online]. Available from: http://staff.washington.edu/dittrich/misc/trinoo.analysis; Oct. 1999a.

Dittrich D. The tribe flood network distributed denial ofservice attack tool [Online]. Available from: http://staff.washington.edu/dittrich/misc/tfn.analysis; Oct. 1999b.

Ferguson P, Senie D. Network ingress filtering: defeating denialof service attacks which employ IP source address spoofing.Internet engineering task force, RFC 2827 [Online]. Avail-able from: http://www.rfc-editor.org/rfc/rfc2827.txt ; May2000.

Ioannidis J, Bellovin SM. Implementing pushback: router-baseddefense against DDoS attacks. In: Proceedings of network anddistributed system security conference. p. 79e86 [Online].Availablefrom: http://www.isoc.org/isoc/conferences/ndss/02/proceedings/papers/ioanni.pdf; Feb. 2002.

Jin C, Wang H, Shin KG. Hop-count filtering: an effectivedefense against spoofed ddos traffic. In: Proceedings of ACM

conference on computer and communications security; Oct.2003. p. 30e41.

Jung J, Krishnamurthy B, Rabinovich M. Flash crowds and denialof service attacks: characterization and implications forCDNs and web sites. In: Proceedings of IEEE internationalworld wide web conference; May 2002. p. 252e62.

Keromytis AD, Misra V, Rubenstein D. SOS: secure overlayservices. In: Proceedings of the 2002 ACM conference onapplications, technologies, architectures, and protocols forcomputer communications; Aug. 2002. p. 61e72.

Keromytis AD, Misra V, Rubenstein D. SOS: an architecture formitigating DDoS attacks. IEEE Journal on Selected Areas inCommunications Jan. 2004;22(1):176e88.

Kung HT, Bradner S, Tan K-S. An IP-layer anonymizing in-frastructure. In: Proceedings of MILCOM, vol. 1; Oct. 2002.p. 389e94.

Kung HT, Cheng C-M, Tan K-S, Bradner S. Design and analysis ofan IP-layer anonymizing infrastructure. In: Proceedings ofthe third DARPA information survivability conference andexposition, vol. 1; Apr. 2003. p. 62e75.

Li J, Mirkovic J, Wang M, Reiher P, Zhang L. Save: source addressvalidity enforcement protocol. In: Proceedings of IEEE

INFOCOM, vol. 3; June 2001. p. 1157e566.Mahajan R, Bellovin SM, Floyd S, Ioannidis J, Paxson V,

Shenker S. Controlling high bandwidth aggregates in thenetwork. ACM Computer Communications Review July 2002;32(3):62e73.

Mirkovic J, Prier G, Reiher P. Attacking DDoS at the source. In:Proceedings of international conference on network proto-cols; Nov. 2002. p. 312e21.

Moore D, Voelker G, Savage S. Inferring internet denial ofservice activity. In: Proceedings of USENIX security sympo-sium [Online]. Available from: http://www.usenix.org/events/sec01/moore.html ; Aug. 2001.

Paxson V. End-to-end routing behavior in the internet.IEEE/ACM Transactions on Networking Oct. 1997;5(5):601e15.

Peng T, Leckie C, Ramamohanarao K. Detecting distributeddenial of service attacks using source IP address monitor-ing. Australia: The University of Melboume; 2002. Tech. rep[Online]. Available from: http://www.ee.mu.oz.au/pgrad/taop/research/detection.pdf.

Peng T, Leckie C, Ramamohanarao K. Protection from distrib-uted denial of service attacks using history-based IPfiltering. In: Proceedings of IEEE international conferenceon communications, vol. 1; May 2003. p. 482e6.

Sanchez LA, Milliken WC, Snoeren AC, Tchakountio F, Jones CE,Kent ST, et al. Hardware support for a hash-based IPtraceback. In: Proceedings of the second DARPA informationsurvivability conference; June 2001. p. 146e52.

Savage S, Wetherall D, Karlin AR, Anderson T. Practical networksupport for IP traceback. In: Proceedings of SIGCOMM

conference; Aug. 2000. p. 295e306.Savage S, Wetherall D, Karlin AR, Anderson T. Network support

for IP traceback. IEEE/ACM Transactions on Networking June2001;3:226e37.

Snoeren AC, Partridge C, Sanchez LA, Jones CE, Tchakountio F,Kent ST, et al. Hash-based IP traceback. In: Proceedings ofthe ACM SIGCOMM conference; Aug. 2001. p. 3e14.

Snoeren AC, Partridge C, Sanchez LA, Jones CE, Tchakountio F,Schwartz B, et al. Single-packet IP traceback. IEEE/ACMTransactions on Networking 2002;10(6):721e34.

Song D, Perrig A. Advanced and authenticated marking schemesfor IP traceback. In: Proceedings of IEEE INFOCOM confer-ence; Apr. 2001. p. 878e86.

Sung M, Xu J. IP traceback-based intelligent packet filtering:a novel technique for defending against internet DDoSattacks. In: Proceedings of international conference onnetwork protocols; Nov. 2002. p. 302e11.

Sung M, Xu J. IP traceback-based intelligent packet filtering:a novel technique for defending against internet DDoSattacks. IEEE Transactions on Parallel and DistributedSystems Sep. 2003;14(9):861e72.

Theilmann W, Rothermel K. Dynamic distance maps of theinternet. In: Proceedings of the IEEE INFOCOM, vol. 1; Mar.2000. p. 275e84.

Yaar A, Perrig A, Song D. Pi: a path identification mechanism todefend against DDos attacks. In: Proceedings of theIEEE symposium on security and privacy; May 2003.p. 93e109.

http://www.ietf.org/internet-drafts/draft-ietf-itrace-04.txthttp://www.ietf.org/internet-drafts/draft-ietf-itrace-04.txthttp://www.cert.org/incident_notes/IN-99-07.htmlhttp://www.cert.org/incident_notes/IN-99-07.htmlhttp://www.cert.org/reports/dsit-workshop-final.htmlhttp://www.cert.org/reports/dsit-workshop-final.htmlhttp://www.cert.org/reports/dsit-workshop.pdfhttp://www.cert.org/reports/dsit-workshop.pdfhttp://www.cert.org/advisories/CA-1999-17.htmlhttp://www.cert.org/advisories/CA-1999-17.htmlhttp://www.cert.org/advisories/CA-2000-01.htmlhttp://www.cert.org/advisories/CA-2000-01.htmlhttp://www.usenix.org/publications/library/proceedings/usenix2000/general/cheswick.htmlhttp://www.usenix.org/publications/library/proceedings/usenix2000/general/cheswick.htmlhttp://www.usenix.org/publications/library/proceedings/usenix2000/general/cheswick.htmlhttp://www.usenix.org/publications/login/2000-7/apropos.htmlhttp://www.usenix.org/publications/login/2000-7/apropos.htmlhttp://staff.washington.edu/dittrich/misc/trinoo.analysishttp://staff.washington.edu/dittrich/misc/trinoo.analysishttp://staff.washington.edu/dittrich/misc/tfn.analysishttp://staff.washington.edu/dittrich/misc/tfn.analysishttp://www.rfc-editor.org/rfc/rfc2827.txthttp://www.isoc.org/isoc/conferences/ndss/02/proceedings/papers/ioanni.pdfhttp://www.isoc.org/isoc/conferences/ndss/02/proceedings/papers/ioanni.pdfhttp://www.usenix.org/events/sec01/moore.htmlhttp://www.usenix.org/events/sec01/moore.htmlhttp://www.ee.mu.oz.au/pgrad/taop/research/detection.pdfhttp://www.ee.mu.oz.au/pgrad/taop/research/detection.pdfhttp://www.ee.mu.oz.au/pgrad/taop/research/detection.pdfhttp://www.ee.mu.oz.au/pgrad/taop/research/detection.pdfhttp://www.usenix.org/events/sec01/moore.htmlhttp://www.usenix.org/events/sec01/moore.htmlhttp://www.isoc.org/isoc/conferences/ndss/02/proceedings/papers/ioanni.pdfhttp://www.isoc.org/isoc/conferences/ndss/02/proceedings/papers/ioanni.pdfhttp://www.rfc-editor.org/rfc/rfc2827.txthttp://staff.washington.edu/dittrich/misc/tfn.analysishttp://staff.washington.edu/dittrich/misc/tfn.analysishttp://staff.washington.edu/dittrich/misc/trinoo.analysishttp://staff.washington.edu/dittrich/misc/trinoo.analysishttp://www.usenix.org/publications/login/2000-7/apropos.htmlhttp://www.usenix.org/publications/login/2000-7/apropos.htmlhttp://www.usenix.org/publications/library/proceedings/usenix2000/general/cheswick.htmlhttp://www.usenix.org/publications/library/proceedings/usenix2000/general/cheswick.htmlhttp://www.usenix.org/publications/library/proceedings/usenix2000/general/cheswick.htmlhttp://www.cert.org/advisories/CA-2000-01.htmlhttp://www.cert.org/advisories/CA-2000-01.htmlhttp://www.cert.org/advisories/CA-1999-17.htmlhttp://www.cert.org/advisories/CA-1999-17.htmlhttp://www.cert.org/reports/dsit-workshop.pdfhttp://www.cert.org/reports/dsit-workshop.pdfhttp://www.cert.org/reports/dsit-workshop-final.htmlhttp://www.cert.org/reports/dsit-workshop-final.htmlhttp://www.cert.org/incident_notes/IN-99-07.htmlhttp://www.cert.org/incident_notes/IN-99-07.htmlhttp://www.ietf.org/internet-drafts/draft-ietf-itrace-04.txthttp://www.ietf.org/internet-drafts/draft-ietf-itrace-04.txt


16/16

Shiuhpyng Shieh is a Professor and former Chairman ofDepartment of Computer Science and Information Engineering ofNationalChiao TungUniversity. He is alsothe presidentof ChineseCryptology and Information SecurityAssociation (CCISA), which isthe largest and a highly respectable academic organization oninformation securityresearchin Taiwan.He hasworked as advisorto many institutes, such as National Security Bureau, GSN-CERT/CC, National Information and Communication Security TaskForce. Before joining NCTU, Dr. Shieh participated in the design

and implementation of theB2 Secure XENIXat IBM,FederalSectorDivision, Gaithersburg, Maryland. He also designed and de-veloped NetSphinx, a network security product, for FormosoftInc., whichis awarded 1999 network product of theyear, Taiwan.

Dr. Shieh received the M.S. and Ph.D. degrees in electrical andcomputer engineering from the University of Maryland, CollegePark. He is a senior member of IEEE, and an editor of ACMTransactions on Information and System Security, Journal of

Computer Security, and Journal of Information Science andEngineering. He was in the organizing committees of numerousconferences, such as ACM conference on Computer andCommunications Security, IACR Asiacrypt. Dr. Shieh publishedover a hundred academic articles, including papers, patents,and books. Recently he received the Outstanding ResearchAward from National Chiao Tung University for his academicachievement in research, and the Outstanding AchievementAward from State Department of Taiwan. His research interests

include internetworking, distributed operating systems, andnetwork security.

Fu-Yuan Lee received the BS degree in computer science fromNational Chiao Tung University in 1998. He is currently a Ph.D.student in the Department of Computer Science and Informa-tion Engineering at National Chiao Tung University. His researchinterests are in the areas of computer networks and networksecurity.


Documents

Defending Against Spoofed DDoS Attacks