ITJNS01

8/6/2019 ITJNS01

1/15

Controlling IP Spoofing throughInterdomain Packet Filters

Zhenhai Duan, Member, IEEE, Xin Yuan, Member, IEEE, and Jaideep Chandrashekar, Member, IEEE

AbstractThe Distributed Denial-of-Service (DDoS) attack is a serious threat to the legitimate use of the Internet. Prevention

mechanisms are thwarted by the ability of attackers to forge or spoof the source addresses in IP packets. By employing IP spoofing,

attackers can evade detection and put a substantial burden on the destination network for policing attack packets. In this paper, we

propose an interdomain packet filter (IDPF) architecture that can mitigate the level of IP spoofing on the Internet. A key feature of our

scheme is that it does not require global routing information. IDPFs are constructed from the information implicit in Border Gateway

Protocol(BGP) route updates andare deployedin network border routers. We establish theconditionsunder whichthe IDPF framework

correctly works in thatit doesnot discardpacketswith valid source addresses. Based on extensive simulation studies,we showthat, even

with partial deployment on the Internet, IDPFs can proactively limit the spoofing capability of attackers. In addition, they can help localize

the origin of an attack packet to a small number of candidate networks.

Index TermsIP spoofing, DDoS, BGP, network-level security and protection, routing protocols.

1 INTRODUCTION

DISTRIBUTED Denial-of-Service (DDoS) attacks pose anincreasingly grave threat to the Internet, as evident inrecent DDoS attacks mounted on both popular Internet sitesand the Internet infrastructure [1]. Alarmingly, DDoSattacks are observed on a daily basis on most of the largebackbone networks [2]. One of the factors that complicatethe mechanisms for policing such attacks is IP spoofing,which is the act of forging the source addresses in IPpackets. By masquerading as a different host, an attackercan hide its true identity and location, rendering source-based packet filtering less effective. It has been shown that a

large part of the Internet is vulnerable to IP spoofing [3].Recently, attackers have increasingly been staging

attacks via botnets [4]. In this case, since the attacks arecarried out through intermediaries, that is, the compro-mised bots, attackers may not utilize the technique of IPspoofing to hide their true identities. It is tempting to believe that the use of IP spoofing is less of a factor.However, recent studies [1], [5], [6] show that IP spoofing isstill a common phenomenon: it is used in many attacks,including the high-profile DDoS attacks on root DNSservers in early February 2006 [1]. In response to this event,the ICANN Security and Stability Advisory Committeemade three recommendations [1]. The first and long-termrecommendation is to adopt source IP address verification,

which confirms the importance of the IP spoofing problem.IP spoofing will remain popular for a number of reasons.

First, IP spoofing makes isolating attack traffic from

legitimate traffic harder: packets with spoofed sourceaddresses may appear to be from all around the Internet.Second, it presents the attacker with an easy way to insert alevel of indirection. As a consequence, substantial effort isrequired to localize the source of the attack traffic [7]. Finally,many popular attacks such as man-in-the-middle attacks [8],[9], reflector-based attacks [10], and TCP SYN flood attacks[11] use IP spoofing and require the ability to forge sourceaddresses.

Although attackers can insert arbitrary source addressesinto IP packets, they cannot control the actual paths that the

packets take to the destination. Based on this observation,Park and Lee [12] proposed the route-based packet filters as away of mitigating IP spoofing. The idea is that by assumingsingle-path routing, there is exactly one single path ps; dbetweenthe source node s and thedestination node d. Hence,any packet with the source address s and the destinationaddress dthatappearinarouterthatisnotinps; d shouldbediscarded. The challenge is that constructing such a route-based packet filter requires the knowledge of global routinginformation,which is hard to reconcile in thecurrent Internetrouting infrastructure [13].

The Internet consists of thousands of network domains orautonomous systems (ASs). Each AS communicates with itsneighbors by using the Border Gateway Protocol (BGP),which is the de facto interdomain routing protocol, toexchange information about its own networks and othersthat it can reach [13]. BGP is apolicy-based routing protocol inthat both theselection andthe propagation of thebestroutetoa destination at an AS are guided by some locally definedrouting policies. Given the insular nature of how policies areapplied at individual ASs, it is impossible foran AS to acquirethe complete knowledge of routing decisions made by allother ASs. Hence, constructing route-based packet filters, asproposed in [12], is an open challenge in the current Internetrouting regime.

Inspired by the route-based packet filters [12], we proposean interdomain packet filter (IDPF) architecture, a route-

based packet filter system that can be constructed solely

22 IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 5, NO. 1, JANUARY-MARCH 2008

. Z. Duan and X. Yuan are with the Department of Computer Science,Florida State University, Tallahassee, FL 32306.E-mail: {duan, xyuan}@cs.fsu.edu.

. J. Chandrashekar is with Intel Research/CTL, 2200 Mission College Blvd.,MS RNB6-61, Santa Clara, CA 95054.E-mail: [email protected].

Manuscript received 7 June 2006; revised 5 Feb. 2007; accepted 10 July 2007;published online 1 Aug. 2007.For information on obtaining reprints of this article, please send e-mail to:[email protected], and reference IEEECS Log Number TDSC-0071-0606.

Digital Object Identifier no. 10.1109/TDSC.2007.70224.1545-5971/08/$25.00 2008 IEEE Published by the IEEE Computer Society

8/6/2019 ITJNS01

2/15

based on the locally exchanged BGP updates, assuming thatall ASs employ a set of routing policies that are commonlyused today [14], [15], [16]. The keycontributions of this paperaregivenas follows: First,we describe howwe canpracticallyconstruct IDPFs at an AS by only using the information in thelocally exchanged BGP updates. Second, we establish theconditions under which the proposed IDPF framework

works correctly in that it does not discard packets with validsource addresses. Third, to evaluate the effectiveness of theproposed architecture, we conduct extensive simulationstudies based on AS topologies and AS paths extracted fromreal BGP data. The results show that, even with partialdeployment, the architecture can proactively limit an attack-ers ability to spoof packets. When a spoofed packet cannotbestopped, IDPFs can help localize the attacker to a smallnumber of candidate ASs, which can significantly improvethe IP traceback situation [7]. In addition, IDPF-enabled ASs(and their customers) provide better protection againstIP spoofing attacks than the ones that do not supportIDPFs. This should give network administrators incentivesto deploy IDPFs.

The rest of this paper is organized as follows: We discussrelated work in Section 2. We provide an abstract model ofBGP in Section 3. Section 4 presents the IDPF architecture.Section 5 discusses practical deployment issues. We reportour simulation study of IDPFs in Section 6. We concludethis paper in Section 7.

2 RELATED WORK

The ideaof IDPFis motivated bythe workcarried out byParkand Lee [12], who evaluated the relationship betweennetwork topology and the effectiveness of route-based packetfiltering. They showed that packet filters constructed basedon the global routing information can significantly limit IP

spoofing when deployed in just a small numberof ASs. In thiswork,we extendthe idea anddemonstratethat filters that arebuilt based on local BGP updates can also be effective.

Unicast reverse path forwarding (uRPF) [17] requires thata packet is forwarded only when the interface that the packetarrives on is exactly the same used by the router to reach thesource IP of the packet. If the interface does not match, thepacket is dropped. Although this is simple, the scheme islimited, given that Internet routing is inherently asymmetric;that is, the forward and reverse paths between a pair of hostsare often quite different. The uRPF loose mode [18] over-comes this limitation by removing the match requirement onthe specific incoming interface for the source IP address. Apacket is forwarded, as long as the source IP address is in the

forwarding table. However,the loose mode is less effective indetecting spoofed packets. In Hop-Count Filtering (HCF)[19], each end system maintains a mapping between IPaddress aggregates and valid hop counts from the origin totheend system. Packets that arrive with a differenthop countare suspicious and are therefore discarded or marked forfurther processing. In Path Identification [20], each packetalong a path is marked by a unique Path Identifier (Pi) of thepath.VictimnodescanfilterpacketsbasedonthePicarriedinthe packet header. StackPi [21] improved the incrementaldeployment property of Pi by proposing two new packetmarking schemes. In [22], Li et al. described SAVE, whichis anew protocol for networks to propagate valid networkprefixes along the same paths that data packets will follow.

Routers along the paths can thus construct the appropriate

filtersby using theprefix andpath information.Bremler-BarrandLevyproposedaspoofingpreventionmethod(SPM)[23],where packets that were exchanged between members of theSPM scheme carry an authentication key that is associatedwith thesource anddestinationAS domains. Packetsarrivingat a destination domain with an invalid authentication key(with respect to the source domain) are spoofed packets andare discarded. In the Packet Passport System [24], a packetthat originated in a participating domain carries a passportthat is computed based on secret keys shared by the sourcedomain and the transit domains from the source to thedestination. Packets carrying an invalid passport are dis-carded by the transit domains.

In the Network Ingress Filtering proposal described in[25], traffic originating in a network is forwarded only if thesource IP in the packets belongs to the network. Ingressfiltering primarily prevents a specific network from beingused for attacking others. Thus, although there is a collectivesocial benefit when everyone deploys it, individuals do notreceive direct incentives. Finally, the Bogon Route ServerProject [26] maintains a list ofbogon network prefixes that are

not routable on the public Internet. Examples include privateRFC 1918 address blocks and unassigned address prefixes.Packets with source addresses in the bogon list are filteredout.However, thismechanismcannot filterout attack packetscarrying routable but spoofed source addresses.

3 BORDER GATEWAY PROTOCOL ANDAS INTERCONNECTIONS

In this section, we briefly describe a few key aspects of BGPthat are relevant to this paper (see [27] for a comprehensivedescription). We model the AS graph of the Internet as anundirected graph G V ; E. Each node v 2 V correspondsto an AS, and each edge eu; v 2 E represents a BGP

session between two neighboring ASs u, v 2 V. To ease theexposition, we assume that there is at most one edgebetween a pair of neighboring ASs.

Each node owns one or multiple network prefixes. Nodesexchange BGP route updates, which may be announcementsor withdrawals, to learn of changes in reachability todestination network prefixes. A route announcement con-tains a list of route attributes associated with the destinationnetwork prefix.Of particular interest to us arethe path vectorattribute as_path, which is the sequence of ASs that thisroute has been propagated over, and the local_prefattribute that describes the degree of local preference associatedwith the route. We will use r.as_path, r.local_pref,and r.prefix to denote the as_path, the local_pref,and the destination network prefix of r, respectively. Letr:as path hvkvk1 . . . v1v0i. The route was originated (firstannounced) by node v0, which owns the network prefixr.prefix. Before arriving at node vk, the route was carriedover nodesv1; v2; . . . ; vk1 in that order.For i k, k 1; . . . ; 1,we say that edge evi; vi1 is on the AS path, that is,evi; vi1 2 r:as path.

When there is no confusion, route r and its AS pathr:as path are interchangeably used. For convenience, wealso consider a specific destination AS d. All routeannouncements and withdrawals are specific to the net-work prefixes owned by d. For simplicity, notation dis alsoused to denote the network prefixes owned by the AS d. As

a consequence, a route r that can be used to reach the

DUAN ET AL.: CONTROLLING IP SPOOFING THROUGH INTERDOMAIN PACKET FILTERS 23

8/6/2019 ITJNS01

3/15

network prefixes owned by destination d may simply beexpressed as a route to reach destination d.

3.1 Policies and Route Selection

Each node only selects and propagates to neighbors a singlebest route to the destination, if any. Both the selection and thepropagation of best routes are governed by locally definedrouting policies. Two distinct sets of routing policies aretypically employed by a node: import policies and exportpolicies. Neighbor-specific import policies are applied uponroutes learned from neighbors, whereas neighbor-specificexport policies are imposed on locally selected best routesbefore they are propagated to the neighbors.

In general, import policies can affect the desirability ofroutes by modifying route attributes. Let r be a route (todestination d) received at v from node u. We denote byimportv ufrg the possibly modified route that hasbeen transformed by the import policies. The transformedroutes are stored in vs routing table. The set of all suchroutes is denoted as candidateRv; d:

candidateRv; d fr : importv ufrg 6 fg

r:prefix d; 8u 2 Nvg:1

Here, Nv is the set of vs neighbors.AmongthesetofcandidateroutescandidateRv; d,node

v selects a single best route to reach thedestination based on a

well-defined procedure (see [27]). To aid in description, weshall denotethe outcome of theselection procedureat node v,thatis,thebestroute,asbestRv; d,whichreadsthe bestrouteto destination d at node v. Having selected bestRv; d fromcandidateRv; d, v then exports the route to its neighborsafter applying neighbor-specific export policies. The exportpolicies determine if a route should be forwarded to theneighbor,and if so, theymodify theroute attributes accordingto the policies (see Section 3.2). We denote by exportv !ufrg the route sent to neighbor u by node v after node vapplies the export policies on route r.

BGP is an incremental protocol: updates are generatedonly in response to network events. In the absence of anyevent, no route updates are triggered or exchanged between

neighbors, and we say that the routing system is in a stablestate. Formally,

Definition 1 (stable routing state). A routing system is in astablestate if allthe nodes have selected a best route to reach othernodes and no route updates are generated (or propagated).

3.2 AS Relationships and Routing Policies

The specific routing policies that an AS internally employsis largely determined by economics: connections betweenASs follow a few commercial relations. A pair of ASs canenter into one of the following arrangements [14], [16]:

. Provider to customer. In this arrangement, a customer

AS pays the provider AS to carry its traffic. It is most

common when the provider is much larger in sizethan the customer.

. Peer to peer. In a mutual peering agreement, the ASsdecide to carry traffic from each other (and theircustomers). Mutual peers do not carry transit trafficfor each other.

. Sibling to sibling. In this arrangement,two ASsprovidemutual transit service to each other. Each sibling AScan be regarded as the provider of the other AS.

An ASs relationship with a neighbor largely determinesthe neighbor-specific import and export routing policies. Inthis paper, we assume that each AS sets its import routingpolicies and export routing policies according to the rulesspecified in Tables 1 [15] and 2 [14], [16], respectively. Theserules are commonly used by ASs on the current Internet. InTable 1, r1 and r2 denote the routes (to destination d)received by node v from neighbors u1 and u2, respectively.customerv, peerv, providerv, and siblingv denote theset of customers, peers, providers, and siblings of node v,respectively. The import routing policies in Table 1 statethat an AS will prefer the routes learned from customers orsiblings over the routes learned from peers or providers.

In Table 2, the columns marked with r1-r4 specify the

export policies employed by an AS to announce routes toproviders, customers, peers, and siblings, respectively. Forinstance, export rule r1 instructs that an AS will announceroutes to its own networks, and routes learned fromcustomers and siblings to a provider, but it will notannounce routes learned from other providers and peersto the provider. The net effect of these rules is that they limitthe possible paths between each pair of ASs. Combinedtogether, the import and export policies also ensure thepropagation of valid routes on the Internet. For example,combining the import and export policies, we can guaranteethat a provider will propagate a route to a customer to otherASs (customers, providers, peers, and siblings). If an ASdoes not follow the import policies, for example, it may

prefer an indirect route via a peer instead of a direct route toa customer. In this case, based on export rule r3, the AS willnot propagate the route (via a peer) to a customer to a peer,since the best route (to the customer) is learned from a peer.This property is critical to the construction and correctnessof IDPFs (see Sections 4.2 and 4.3). The routing policies inTables 1 and 2 are incomplete. In some cases, ASs mayapply less restrictive policies. For the moment, we assumethat all ASs follow the import and export routing policiesspecified in Tables 1 and 2 and that each AS acceptslegitimate routes exported by neighbors. More general caseswill be discussed at the end of the next section.

If AS b is a provider of AS a and AS c is a provider of AS b,

then we call c an indirect provider of a, and a an indirect


TABLE 1Import Routing Policies at an AS

TABLE 2Export Routing Policies at an AS

8/6/2019 ITJNS01

4/15

customer of c. Indirect siblings are defined in a similarfashion. The import and export routing policies in Tables 1and 2 imply that an AS will distribute the routes to direct orindirect customers/siblings to its peers and providers. Ifeu; v 2 bestRs; d:as path, we say that u is the bestupstream neighbor of node v for traffic from node s todestination d, and we denote u as u bestUs;d;v. For ease

of exposition, we augment the AS graph with the relation-ships between neighboring ASs. We refer to an edge from aprovider to a customer AS as a provider-to-customer edge, anedge from a customer to provider as a customer-to-provideredge, andan edge connecting sibling (peering)ASs as sibling-to-sibling(peer-to-peer)edge. A downhill pathisasequenceofedges that are either provider-to-customer or sibling-to-sibling edges,and an uphill path isa sequence of edges thatareeither customer-to-provider or sibling-to-sibling edges. Gao[14] established the following about the candidate routes in aBGP routing table:

Theorem 1 (see [14]). If all ASs set their export policiesaccording to r1-r4, a candidate route in a BGP routing tablecan be any of the following:

1. an uphill path,2. a downhill path,3. an uphill path followed by a downhill path,4. an uphill path followed by a peer-to-peer edge,5. a peer-to-peer edge followed by a downhill path, or6. an uphill path followed by a peer-to-peer edge, which is

followed by a downhill path.

4 INTERDOMAIN PACKET FILTERS

In this section, we discuss the intuition behind the IDPFarchitecture, describe how IDPFs are constructed using BGP

route updates, and establish the correctness of IDPFs. Afterthat, we discuss the case where ASs have routing policiesthat are less restrictive than the ones in Tables 1 and 2. Weshall assume that the routing system is in the stable routingstate in this section. We will discuss how IDPFs fare withnetwork routing dynamics in the next section.

Let Ms; d denote a packet whose source address is s (ormore generally, the address belongs to AS s) and whosedestination address is d. A packet filtering scheme decideswhether a packet should be forwarded or dropped based oncertain criteria. One example is the route-based packetfiltering [12]:

Definition 2 (route-based packet filtering). Node v accepts

packet Ms; d that is forwarded from node u if and only ifeu; v 2 bestRs; d. Otherwise, the source address of thepacket is spoofed, and the packet is discarded by v.

In the context of preventing IP spoofing, an ideal packetfilter should discard spoofed packets while allowing legit-imate packets to reach the destinations. Since, even with theperfect routing information, the route-based packet filterscannot identify all spoofed packets [12], a valid packet filtershould focus on not dropping any legitimate packets whileproviding the ability to limit spoofed packets. Accordingly,we define the correctness of a packet filter as follows:

Definition 3 (correctness of packet filtering). A packet filteris correct if it does not discard packets with valid sourceaddresses when the routing system is stable.

Clearly, the route-based packet filtering is correct, becausevalid packets from source s to destination dwill only traversethe edges on bestRs; d. Computing route-based packetfilters requires the knowledge ofbestRs; d on every node,which is impossible in BGP. IDPF overcomes this problem.

4.1 IDPF Overview

The following concepts will be used in this section. Atopological route between nodes s and d is a loop-free pathbetween thetwo nodes.Topological routesare implied by thenetwork connectivity. A topological route is a feasible routeunder BGP if and only ifthe constructionof the route doesnotviolate the routing policies imposed by the commercialrelationship between ASs (Tables 1 and 2). Formally, letfeasibleRs; d denote the set of feasible routes from s to d.Then, feasibleRs; d can recursively be defined as follows:

feasibleRs; d

fhs [ feasibleRu; dig;

u :

imports ufrg 6 fg;

r:prefix d; u 2 Ns

where is the concatenation operation, for example, fs fhabi; huvigg fhsabi; hsuvig. Notice that feasibleRs; dcontains all the routes between the pair that does notviolate the import and export routing policies specified inTables1and2.Obviously,bestRs; d 2 candidateRs; d feasibleRs; d.Eachofthefeasibleroutescanpotentiallybeacandidateroute ina BGProutingtable.Theorem1 also appliesto feasible routes.

Definition 4 (feasible upstream neighbor). Consider afeasible route r 2 feasibleRs; d. If an edge eu; v is onthe feasible route, that is, eu; v 2 r:as path, we say that

node u is a feasible upstream neighbor of node v for packetMs; d. The set of all such feasible upstream neighbors of v(for Ms; d) is denoted as feasibleUs;d;v.

The intuition behind the IDPF framework is thefollowing:First, it is possible for a node v to infer its feasible upstreamneighbors by using BGP route updates. The techniquefor inferring feasible upstream neighbors is described inthe next section. Since bestRs; d 2 candidateRs; d feasibleRs; d, a node can only allow Ms; d from itsfeasible upstream neighbors to pass and discard all otherpackets. Such a filtering will not discard packets with validsource addresses. Second, although network connectivity(topology) may imply a large number of topological routesbetween a source and a destination, the commercial relation-ship between ASs and routing policies employed by ASs actto restrict the size offeasibleRs; d. Consider theexample inFig. 1. Figs. 2a and 2b present the topological routes impliedby the network connectivity and feasible routes constrained by routing policies between source s and destination d,respectively. In Fig. 2b, we assume that nodes a, b, c, and dhave mutual peering relationship, and that a and b areproviders to s. We see that although there are 10 topologicalroutes between source s and destination d, we only have twofeasible routes thatare supportedby routing policies. Of moreimportance to IDPF is that although the network topologymay imply that all neighbors can forward a packet allegedlyfrom a sourceto a node,feasibleroutes constrainedby routing

policies help limit the set of such neighbors. As an example,


8/6/2019 ITJNS01

5/15

letus consider thesituation at node d. Given that only nodes aand b (but not c) are on the feasible routes from s to d, node dcan infer that all packets forwarded by node c and allegedlyfrom source s are spoofed and should be discarded.

It is clear that IDPF is less powerful than route-basedpacket filters [12], since the IDPFs are computed based onfeasibleRs; d instead ofbestRs; d. However, feasibleUs;d;v can be inferred from local BGP updates, whereasbestUs;d;v cannot.

4.2 Constructing IDPFsThe following lemma summarizes the technique foridentifying the feasible upstream neighbors of node v forpacket Ms; d:

Lemma 1. Consider a feasible route r between source s anddestination d. Let v 2 r:as path and let u be the feasibleupstream neighbor of node v along r. When the routing systemis stable, exportu ! vfbestRu; sg 6 fg, assumingthat all ASs follow the import and export routing policies inTables 1 and 2 and that each AS accepts legitimate routesexported by neighbors.

Lemma 1 states that if node u is a feasible upstreamneighbor of node v for packet Ms; d, node u must haveexported to node v its best route to reach the source s.

Proof. Since Theorem 1 applies to feasible routes, a feasibleroute can be one of the six types of paths in Theorem 1. Inthe following, we assume that the feasible route r is oftype 6, that is, an uphill path followed by a peer-to-peeredge, which is followed by a downhill path. Cases wherer is of types 1-5 can similarly be proved. To prove thelemma, we consider the possible positions of nodes uand v in the feasible route:

Case 1. Nodes u and v belong to the uphill path. Then,node s must be an (indirect) customer or sibling of nodeu. From the import routing policies in Table 1 and theexport routing policy r1 and the definition of indirect

customers/siblings, we know that u will propagate to(provider) node v the reachability information of s.

Case 2. eu; v is the peer-to-peer edge. This case cansimilarly be proved as case 1 (based on the import routingpolicies in Table 1 and the export routing policy r3).

Case 3. Nodes u and v belong to the downhill path.Let ex; y be the peer-to-peer edge along the feasibleroute r and note that u is an (indirect) customer of y.From the proof of case 2, we know that node y learns thereachability information of s from x. From the exportrouting policy r2 and the definition of indirect custo-mers, node y will propagate the reachability informationofs to node u, which will further export the reachabilityinformation of s to (customer) node v. tu

Based on Lemma 1, a node can identify the feasibleupstream neighbors for packet Ms; d and conduct IDPF asfollows:

Definition 5 (IDPF). Node v will accept packet Ms; d that isforwarded by a neighbor node u if and only ifexportu ! v

fbestRu; sg 6 fg. Otherwise, the source address of the packet must have been spoofed, and the packet should bediscarded by node v.

4.3 Correctness of IDPF

Theorem 2. An IDPF, as defined in Definition 5, is correct.

Proof. Without loss of generality, consider source s,destination d, and a node v 2 bestRs; d:as path suchthat v deploys an IDPF. To prove the theorem, we need toestablish that v will not discard packet Ms; d forwardedby the best upstream neighbor u along bestRs; d.

S i n c e bestRs; d 2 candidateRs; d feasibleRs; d, u is also a feasible upstream neighbor of node v for

packet Ms; d. From Lemma 1, u must have exported tonode v its best route to source s. That is, exportu ! vfbestRu; sg 6 fg. From Definition 5, packet Ms; d,which is forwardedby node u, will not bediscarded by v.tu

Notice that the destination address d in a packet Ms; ddoes not play a role in an IDPF nodes filtering decision(Definition 5). By constructing filtering tables based on thesource address alone (rather than both source and destina-tion addresses), the per-neighbor space complexity for anIDPF node is reduced from ON2 to ON, where N jVjis the number of nodes in the graph (the route-basedscheme can achieve the same complexity bound [12]).

It is worth noting that IDPFs filter packets based onwhether the reachability information of a network prefix is

propagated by a neighbor and not on how the BGP updatesare propagated. As long as ASs propagate network reach-ability information according to the rules in Tables 1 and 2,IDPFs work correctly. Moreover,the effectiveness of IDPFs isdetermined largely by the size of feasibleRs; d, which is afunction of the (relatively static) AS relationships. Hence,howthe BGP updates arepropagated does not affect both thecorrectness and the performance of IDPFs. For example, themultiple-path advertisement supported by MIRO [28] willnot affect IDPFs correctness and effectiveness.

4.4 Routing Policy Complications

As discussed earlier, the import routing policies and the

export routing policies specified in Tables 1 and 2 are not


Fig. 1. An example network topology.

Fig. 2. Routes between source s and destination d. (a) Topological

routes implied by connectivity. (b) Feasible routes constrained by routing

policies.

8/6/2019 ITJNS01

6/15

complete. In particular, multihomed ASs may employ lessrestrictive routing policies for traffic engineering or otherpurposes [29]. In this section, we first present two trafficengineering examples that do not follow the import andexport routing policies specified in Tables 1 and 2. Then, wediscuss how ASs that employ these special traffic engineer-ing practices should control the forwarding of their traffic toensure the delivery of their traffic in the IDPF framework.

In the first example (see Fig. 3), based on [27], ASs a and

b are providers of AS s, and s has two prefixes 138.39/16and 204.70/16. The link between a and s is used as theprimary and backup links for 138.39/16 and 204.70/16,respectively, whereas the link between b and s is used in areverse manner. To achieve this traffic engineering goal, sinforms a to assign the direct customer route r1 between aand s a lower local preference over the peering route r2learned from b to reach the network prefix 204.70/16.That is, r1:local pref < r2:local pref. This local prefer-ence assignment at node a does not follow the importrouting policies defined in Table 1, which requires that anAS should prefer a direct route over an indirect route(through a peer) to reach a customer.

Now, consider the example in Fig. 4. Customer s has aprimary provider a anda backupprovider b. AS s realizes thisgoal by using a technique called conditional route advertise-ment. Prefix 138.39/16 is announced to the backupprovider b only if the link to the primary provider a fails.This asymmetric advertisement does not follow the exportrouting policy r1 defined in Table 2, which states that acustomer will always export to its providers the routes to itsown prefixes.

In the examples, the customer s controls the routepropagation either by manipulating the local preference ofthe routes in providers (see Fig. 3) or by conditional routeadvertisement (see Fig. 4). As long as the customer AS doesnot forward packets through the backup route while theprimary route is still available, the IDPF architecture willnot discard any valid packets. This requirement is not hardto meet, since the customer controls both the routepropagation and traffic delivery. The same observationapplies to other cases when the routing policies specified inTables 1 and 2 are not followed. We have the followingrestricted traffic forwarding policy for the ASs that do notfollow the routing policies specified in Tables 1 and 2.

Restricted traffic forwarding policy. If an AS does notfollow the import and export routing policies in Tables 1and 2, as long as the primary route is available, the ASshould not forward traffic along other (backup) routes.

If each AS on the Internet follows the import routingpolicies in Table 1 and the export routing policies in Table 2

or the restricted traffic forwarding policy, we can establish

the correctness of IDPFs, as defined in Definition 5, on theInternet. The proof is similar to that of Lemma 1 andTheorem 2, and we omit it here.

5 PRACTICAL DEPLOYMENT ISSUES OF IDPFS

5.1 Incremental Deployment

IDPFs can independently be deployed in each AS. IDPFs aredeployed at the border routers so that IP packets can beinspected before they enter the network. By deployingIDPFs, an AS constrains the set of packets that a neighborcan forward to the AS: a neighbor can only successfullyforward a packet Ms; d to the AS after it announces thereachability information of s. All other packets areidentified to carry spoofed source addresses and arediscarded at the border router of the AS. In the worst case,even if only a single AS deploys IDPF and spoofed IPpackets can get routed all the way to the AS in question,using an IDPF perimeter makes it likely that spoofedpackets will be identified and, hence, blocked at theperimeter. Clearly, if the AS is well connected, launching

a DDoS attack upon the perimeter itself takes a lot moreeffort than targeting individual hosts and services withinthe AS. In contrast, ASs that do not deploy IDPF offerrelatively little protection to the internal hosts and services.Therefore, an AS has direct benefits of deploying IDPFs. Ingeneral, by deploying IDPFs, an AS can also protect otherASs to which the AS transports traffic, in particular thecustomer ASs. It can similarly be understood that an IDPFnode limits the set of packets forwarded by a neighbor anddestined for a customer of the AS.

5.2 Handling Routing Dynamics

So far, we have assumed that the AS graph is a staticstructure. In reality, the graph changes, triggering the

generation of BGP updates and altering the paths that ASsuse in reaching each other. In this section, we examine howrouting dynamics affects the operation of IDPFs. Weconsider two different types of routing dynamics: 1) thosecaused by network failures and 2) those caused by thecreation of a new network (or recovery from a fail-downnetwork event). Routing dynamics caused by routing policychanges can similarly be addressed, and we omit them here.

IDPFs are completely oblivious to the specifics of theannounced routes. Following a network failure, the set offeasible upstream neighbors will not admit more membersduring the period of routing convergence, assuming that ASrelationships arestatic, which is true in most cases.Hence, for

the first type of routing dynamics (network failure), there is


Fig. 3. Automatic backup route.

Fig. 4. Conditional route advertisement.

8/6/2019 ITJNS01

7/15

no possibility that the filters will block a valid packet. Weillustrate this as follows: Consider an IDPF-enabled AS v thatis on the best route from s to d. Let u bestUs;d;v andU feasibleUs;d;v. A link or router failure between u ands canhave three outcomes:1) AS u canstill reach AS s,and u isstill chosen to be the best upstream neighbor for packetMs; d, that is, u bestUs;d;v. In this situation, although

u may explore and announce multiple routes to v during thepath exploration process [30], the filtering function of v isunaffected.2) AS u isnolongerthebestupstreamneighborforpacket Ms; d, and another feasible upstream neighbor u0 2U can reach AS s and is instead chosen to be the new bestupstream neighbor (for Ms; d). Now, both u and u0 mayexplore multiple routes; however, since u0 has alreadyannounced a route (about s) to v, the IDPF at v can correctlyfilter(that is, accept) packet Ms; d, which is forwarded fromu0. 3) No feasible upstream neighbors can reach s. Conse-quently, AS v will also not be able to reach s, and v will nolonger be on the best route between s and d. No new packetMs; d should be sent through v.

The other concern of routing dynamics relates to how anewly connected network (or a network recovered from afail-down event) will be affected. In general, a network maystart sending data immediately following the announcementof a (new) prefix, even before the route has had time topropagate to the rest of the Internet. During the time that theroute should be propagated, packets from this prefix may bediscarded by some IDPFs if the reachability information hasnot propagated to them. However, the mitigating factor hereis that in contrast to the long convergence delay that followsfailure, reachability for the new prefix will be distributed farmore speedily. In general, the time taken for such new prefixinformation to reach an IDPF is proportional to the shortestAS path between theIDPF andthe originator of theprefix and

independent of the number of alternate paths between thetwo. Previous work has established this bound to be OL,with L being the diameter of the AS graph [30]. We believethat in this short timescale, it is acceptable for IDPFs topotentially incorrectly behave (discarding valid packets). Itmust be noted that during BGP route convergence periods,without IDPF, BGP can also drop packets. One alternativesolution is toallowa neighborto continue forwarding packetsfrom a source within a grace period, after the correspondingnetwork prefix has been withdrawn by the neighbor. In thiscase, during this short period, IDPFs may fail to discardspoofed attack packets. However, given that most DDoSattacks require a persistent train of packets to be directed at avictim, notdiscarding spoofed packets forthis short period oftime should be acceptable. We plan to further investigate therelated issues in the future.

In short, IDPFs can handle the routing dynamics causedby network failures, which may cause long route conver-gence times. IDPFs may, however, drop packets in thenetwork recovery events. We argue that this is not a bigproblem, since 1) the network recovery events typicallyhave a short convergence time and 2) such events can alsocause service disruptions in the original BGP without IDPF.

5.3 Overlapping Prefixes

In theIDPF architecture, all ASsalong thepath from s to dcanspoof the source address of s and reach d without being

filtered out. The route-based packet filtering has a similar

behavior. Due to this property, IDPF is most effective whendifferentASsownnonoverlappingprefixes.Forexample,let sbe 1.2/16. Then, all ASs along the path from s to dcan spoofthis prefix. Now, if there is a more specific address s0 1:2:3=24 somewhereinthenetwork,alltheseASscannowalsospoof s0, since a more specific prefix also matches a moregeneral prefix. This situation does not happen when prefixes

arenotoverlapped.Hence,statistically,IDPFismoreeffectivewhen prefixes are not overlapped. However, due to theubiquitous use of classless addressing, that is, CIDR [31], theprefixes owned by different ASs may overlap. The effect ofoverlapping prefixes will be studied in the next section.

6 PERFORMANCE STUDIES

In this section, we first discuss the objectives of ourperformance studies and the corresponding performancemetrics. We then describe the data sets and specific settingsused in the simulation studies. Finally, detailed resultsobtained from simulations are presented.

6.1 Objectives and MetricsWe evaluate the effectiveness of IDPFs in controlling IPspoofing-based DDoS attacks from two complementaryperspectives [12]. First, we wish to understand how effectivethe IDPFs are in proactively limiting the capability of anattacker to spoof addresses of ASs other than its own. IDPFsdo not provide complete protection, and spoofed packetsmay still be transmitted. Thus, the complementary reactiveview is also important. We study how the deployed IDPFscan improve IP traceback effectiveness by localizing theactual source of spoofed packets. Since the (incremental)deployment of IDPFs directly affects the effectiveness,various deployment scenarios are considered. The lastdimension of our simulation studies concerns the issue of

incentive, that is, how an individual AS will benefit fromdeploying IDPF on its routers.We use the performance metrics introduced in [12] in our

study. Given any pair of ASs, say, a and t, Sa;t isthesetof ASsfrom which an attacker in AS a canforge addressesto attack t.For any pair of ASs, s and t, Cs;t is the set of ASs from whichattackers can attack t by using addresses that belong to s,without such packets being filtered before they reach t.

To establish a contrast, consider that Sa;t quantifies thepool of IP addresses that may be forged by an attacker in a tosend packets to t without being stopped. On the other hand,Cs;t is defined from the victims perspective. This quantifiesthe size of the set of ASs that can forge an address belongingto s in sending packets to t without being discarded along

the way. Thus, the latter is a measure of the effort required atAS t to trace the packets to the actual source (there are jCs;tjlocations from which the packet could have originated).

6.1.1 Proactive Prevention Metrics

Given the AS graph G V ; E, we define the preventionmetric from the point of view of the victim as follows:

V ictimFraction jft : 8a 2 V ; jSa;tj gj

jVj:

V ictimFraction, which is redefined from [12], denotesthe proportion of ASs that satisfy the following propertythat if an arbitrary attacker intends to generate spoofed

packets, it can successfully use the IP addresses of at most


8/6/2019 ITJNS01

8/15

ASs (note that this includes the attackers own AS). Thus,

V ictimFraction represents the effectiveness of IDPFs in

protecting ASs against spoofing-based DDoS attacks, that is,the fraction of ASs that can be attacked by attackers whocan spoof addresses of at most networks. For instance,

V ictimFraction1, which should be read as the fraction of ASs that can be attacked with packets from at most one AS,

describes the immunity to all spoofing-based attacks.Next, we define a metric from the attackers perspective.

Given G V ; E, AttackFraction, as defined in [12],describes the fraction of ASs from which an attacker canforge addresses belonging to at most ASs (including theattackers own) in attacking any other ASs in the graph:

AttackFraction jfa : 8t 2 V ; jSa;tj gj

jVj:

Intuitively, AttackFraction is the strength of IDPFs in

limiting the spoofing capability of an arbitrary attacker. Forinstance, AttackFraction1 quantifies the fraction of ASsfrom which an attacker cannot spoof any address other thanits own.

6.1.2 Reactive IP Traceback Metrics

To evaluate the effectiveness of IDPFs in reducing the IPtraceback effort, that is, the act of determining the true originof spoofed packets, V ictimTraceFraction is defined in

[12], which is the proportion of ASs being attacked that canlocalize the true origin of an attack packet to be within ASs:

V ictimTraceFraction jft : 8s 2 V ; jCs;tj gj

jVj:

For instance, V ictimTraceFraction1 is simply the fraction

of ASs, which, when attacked, can correctly identify the(single) source AS from which the spoofed packet wasoriginated.

6.1.3 Incentives to Deploy IDPF

To formally study the gains that ASs might accrue

b y deploy ing IDPF s on t he ir b or de r r oute rs, w e

introduce a related set of metrics: V ictimFractionIDPF,

AttackFractionIDPF, and V ictimTraceF ractionIDPF.

Let T denote the set of ASs that support IDPFs:

V ictimFractionIDPF jft 2 T : 8a 2 V ; jSa;tj gj

jTj;

AttackFraction IDPF jfa 2 V : 8t 2 T ; jSa;tj gjjVj

;

V ictimTraceF ractionIDPF jft 2 T : 8s 2 V ; jCs;tj gj

jTj:

Note that these are similar to the metrics definedearlier, that is, V ictimFraction, AttackFraction, andV ictimTraceF raction, respectively. However, we re-strict the destinations to the set of IDPF-enabled ASsrather than the entire population of ASs.

Note also that V ictimFraction, AttackFraction,and V ictimTraceF raction correspond to 1, 2,and 1 in [32], respectively. We rename them to facilitateeasier understanding.

6.2 Data Sets

In order to evaluate the effectiveness of IDPFs, we constructfour AS graphs from the BGP data archived by the RouteViewsProject[33]. The firstthree graphs, denoted G2003, G2004,and G2005, areconstructed fromsingle routing tablesnapshots(taken from the first day of each of the years). Although theseprovideanindicationoftheevolutionarytrendsinthegrowthof the Internet AS graph, they offer only a partial view of theexisting connectivity [14]. In order to obtain a morecomprehensive picture, similar to [34], we construct G2004cby combining G2003 and an entire year of BGP updates betweenG2003 and G2004. Note that the Slammer worm attack [35],which caused great churn of the Internet routing system,occurred duringthis periodof time. This hadthe side effectofexposing more edges and paths than would normally bevisible.1 It is worth pointing out that, even with this effort, theAS graphs that we constructed still may only represent apartial view of the Internet AS-level topology and may notcapture all the feasible routes between a pair of source anddestination. Thus, we may overestimate the performance ofIDPFs, especially for G2003, G2004, and G2005.

Table 3 summarizes the properties of the four graphs. Inthis table, we enumerate the number of nodes, edges, andAS paths that we could extract from the data sets. We alsoinclude the size of the vertex cover (VC) for the graph

corresponding to individual data sets (the construction willbe described later). In Table 3, we see that G2004c has about22,000 more edges or a 65.9 percent increase compared toG2004. In addition, the number of observed AS paths inG2004c is an order of magnitude more than the observedpaths in the G2004 data.

6.2.1 Inferring Feasible Upstream Neighbors

In order for each AS to determine the feasible upstreamneighbors for packets from source to destination, we alsoaugment each graph with the corresponding AS paths usedfor constructing the graph [33]. We infer the set of feasibleupstream neighbors for a packet at an AS as follows: Ingeneral, if we observe an AS path hvk; vk1; . . . ; v0i associated

with prefix P, we take this as an indication that vi announcedthe route for P to vi1, that is, vi 2 feasibleUP ; vi1,i 0; 1; . . . ; k 1.

6.2.2 Determining Routes between Two Nodes

Given an AS graph G V ; E and a subset of nodes T Vthat deploy the IDPFs, the route that a packet takes fromsource node s to destination node t will determine the IDPFsthat the packet will encounter on the way. Consequently, inordertocomputethedescribedperformancemetrics ,werequirethe


1. Given the lengthy period over which we applied the updates, it islikely that our AS graph includes stale edges, that is, edges that no longerexist. We ignore this effect in our study, noting that AS relationships are

quite stable and, thus, the number is likely to be very small.

TABLE 3Graphs Used in the Performance Studies

8/6/2019 ITJNS01

9/15

exact routes that will be taken between any pairs of nodes.Unfortunately, there is simply no easy way to accurately getthisknowledge.Inthispaper,asaheuristic,wesimplyusetheshortest path on G. When there are multiple candidates, wearbitrarilyselectoneofthem.Asaconsequence,inadditiontoAS paths, we also include the selected shortest path as afeasible route if it has not been described in the routing

updates observed. Note that this knowledge, that is, the bestpathfroman AS to another, is only required in the simulationstudiestodeterminetheIDPFsthatapacketmayencounteronthe way from the source to the destination. It is not required inthe construction of the IDPFs. Note also that due tothe way thatfeasible neighbors are computed, the effectiveness of IDPFsmay artificially be inflated, since the set of feasible neighborsof a node in oursimulations is a subsetof feasible neighborsofthe node in reality (with the complete Internet topology).

6.2.3 Selecting IDPF Nodes

Given a graph G V ; E, the effectiveness of IDPF heavilydepends on the filter set, that is, nodes in V for supportingIDPF. We consider two methods for selecting IDPF nodes,

which represents two ways that IDPFs can incrementally bedeployed. In the first method, denoted as T op, we aggres-sively select the nodes with the highest degree to deployIDPF. A special case of this method, denoted as V C, isselecting the IDPF nodes until a V C of G is formed. Thenumber of nodes for forming the V C for each data set isshown in Table 3. In the second method, denoted as Rnd, werandomly (uniformly) choose the nodes from V until adesirable proportion of nodes are chosen. We will use thenotions RndXand TopXto denote the selection ofXpercentof all nodes for deploying IDPFs using the Rnd and T opmethods, respectively. For example, Rnd30 representsselecting 30 percent of nodes to be IDPF nodes using theRndmethod. Note that ASs with high degrees are normally

Internet service providers. In particular, tier-1 serviceproviders normally have higher degrees than others. There-fore, the T op methodwill likely selecttier-1 nodes first.Giventhat the majority of AS paths traverse tier-1 providers, filtersdeployed at tier-1 providers (or ASs with higher degrees) aremore effective in detectingspoofed traffic. On theotherhand,the Rnd method may represent a more realistic IDPFdeployment scenario, where ASs decide whether to deployIDPF independently.

6.3 Results of Performance Studies

Thestudies areperformed with theDistributedPacket Filtering(dpf) simulationtool[12].We extendeddpfto support ourownfilter construction based on BGP updates and to deal with

overlappingprefixes.WeevaluatedtheperformanceofIDPFsby using the three performance metrics (V ictimFraction,AttackFraction, and V ictimTraceF raction) under dif-ferent situations. In addition, we also studied the impact ofusing BGP updates instead of precise routing information toconstruct packet filters, investigated the effect of overlappingprefixes in the Internet, and considered IDPFs with andwithout network ingress filtering. Before we describe thesimulation results in detail, we briefly summarize the salientfindings:

. IDPFs cansignificantly limit thespoofingcapability ofan attacker. For example, with the V CIDPF coverageon the 2004c data set, an attacker in more than

80 percent of ASs cannot successfully launch any

spoofing-based attack on the Internet (assuming thatno overlapping prefixes are announced). Moreover,with the same configuration, the AS under attack canlocalize the true origin of an attack packet to bewithin28 ASs, thus greatly reducing theeffort of IP traceback.In this summary, unless specified otherwise, allexample data are based on the VC IDPF coverage on

the 2004c data set, with the assumptions that IDPFnodes are also capable of ingress filtering and thatthere are no overlapping prefixes.

. The placement of IDPFs plays a key role in theeffectiveness of IDPFs in controlling spoofing-basedattacks. It is much more effective in deploying IDPFson ASs with high connectivity (such as tier-1 ISPs)than deploying IDPFs on random ASs. For example,deploying IDPFs on 5 percent of ASs selected by theTop method is more effective than deploying IDPFson 30 percent of ASs selected by the Rnd method inall of the three performance metrics.

. In comparison to constructing filters with preciserouting information, constructing filters with BGP

updates does not significantly degrade the IDPFperformance in limiting spoofed packets. However,the IDPF traceback capability is substantially af-fected. For example, the number of nodes thatcannot launch any spoofing-based attacks dropsfrom 84 percent to 80 percent (a slight decrease),whereas the number of ASs that an AS can pinpointas the potential true origin of an attack packetincreases from 7 to 28 (a fairly large increase).

. Overlapping prefixes have a detrimental effect on theperformance of IDPFs. However, IDPFs still workreasonablywell withoverlappingprefixesannouncedon theInternet. Forexample,in this case,an attacker inabout 50 percent of the ASs cannot launch any

spoofing-based attacks, and for the majority of attackpackets, the AS under attack can pinpoint the trueorigin to be within 79 ASs.

. Network ingress filtering [25] helps improve theperformance of IDPFs. However, even without net-work ingress filtering, IDPF is still effective. Forexample, an attacker still cannot launch any spoof-ing-based attacks from within more than 60 percent ofASs. Moreover, the AS under attack can localize thetrue origin of an attack packet to be within 87 ASs.

Next, we will present the experimental results. In allexperiments, except for the ones in Section 6.3.5, we assumethat ASs that deploy IDPFs, being security conscious andnetwork savvy,also implement network ingress filtering [25].

6.3.1 IDPFs with BGP Updates and Nonoverlapping

Prefixes

To begin with, we study the performance of IDPFs withBGP updates and nonoverlapping prefixes. Fig. 5 shows theresults on G2004c with different IDPF node coverages,whereas Fig. 6 shows the results of the IDPF VC coverageon different data sets.

Fig. 5a presents the values ofV ictimFraction for threedifferent ways of selecting the IDPF node on the G2004cgraph: V C and random covers (Rnd50 and Rnd30). Notethat V ictimFraction indicates the proportion of nodesthat may be attacked by an attacker that can spoof the IP

addresses of at most nodes. As discussed earlier, IDPFs


8/6/2019 ITJNS01

10/15

cannot completely protect ASs from spoofing-based attacks.Hence, we focus on its ability to limit the spoofing capabilityof attackers. Fig. 5a shows that IDPF is effective incontrolling V ictimFraction, especially with the IDPFVC coverage. The figure shows that the placement of IDPFsplays a key role in the effectiveness of IDPFs in controlling

spoofing-based attacks. For example, with only 17.8 percentof nodes supporting IDPFs, V C outperforms both Rnd30and Rnd50, although they recruit a larger number of nodesthat support IDPFs. In general, it is more preferable fornodes with large degrees (such as big ISPs) to deploy IDPFs.Fig. 6a shows V ictimFraction for the graphs from 2003to 2005 (including G2004c) with the V Ccoverage. We see thatoverall, similar trends hold for all the years examined.However, it is worth noting that G2004c performs worse thanG2004. This is because G2004c contains more edges and moreAS paths by incorporating one-year BGP updates.

AttackFraction illustrates how effective IDPFs are inlimiting the spoofing capability of attackers. In particular,AttackFraction1 is the proportion of nodes from which an

attacker cannot launch any spoofing-based attacks againstany other nodes. Fig. 5b shows that IDPFs are very effectivein this regard. For G2004c, AttackF raction1 80:8 percent,59.2 percent, and 36.2 percent for V C, Rnd50, and Rnd30,respectively. Similar trends hold for all the years examined(see Fig. 6b). This indicates that IDPFs are very effective inlimiting the spoofing capability.

Recall that V ictimTraceF raction indicates the propor-tion of nodes that, under attack by packets with a source IPaddress, can pinpoint the true origin of the packets to bewithin at most nodes. Fig. 5c shows that all nodes canlocalize the true origin of an arbitrary attack packet to bewithin a small number of candidate nodes (28 nodes; see

Fig. 6c) for the V C coverage. For the other two, that is,

Rnd30 and Rnd50, the ability of nodes to pinpoint the trueorigin is greatly reduced. In Fig. 6c, we also see that G2003,G2004, and G2005 can all pinpoint the true origin of attackpackets to be within 10 nodes. However, it is important tonote that such graphs are less complete representations ofthe Internet topology compared to G2004c. Nonetheless, the

trend in the results for G2003, G2004, and G2005 is quite similarto that in the results for G2004c. In the rest of this section, wewill mostly show results for G2004c, since this data set ismore complete than others.

Figs. 7 and 8 show the performance as functions of thepercentages of IDPF nodes selected with the T op and Rndmethods, respectively. As expected, in both cases, theeffectiveness of IDPF increases as a larger number of nodesdeploy IDPF. However, these two figures show that the T opmethod is significantly more effective than the Rndscheme,which strongly argues for the deployment of IDPFs in largeISPs with more connectivity. As shown in the figures, evenwith being deployed only on 1 percent of the most connectednodes,IDPFs can significantlylimit thespoofing capability of

the attackers and increase the traceback accuracy. Moreover,the performance of IDPFs with 5 percent of all the nodesselected by the T op method is never worse than that with30 percent of all the nodes selected by the Rnd method interms of all of the three performance metrics. When the IDPFnodes are randomly selected, they can still significantly limitthe spoofing capability (see Fig. 8b).

6.3.2 Impacts of Precise Routing Information

In this section, we study the impact of the precise globalrouting information on the performance of IDPFs. The goal isto determine the performance difference between IDPFs andthe ideal route-based packet filters [12] with precise globalrouting information. Notice that in a sense, SAVE [22] is a

way to realize route-based packet filtering on the Internet. Its


Fig. 6. Results for G2003, G2004, G2004c, and G2005 with the VC coverage. (a) V ictimFraction. (b) AttackFraction. (c) V ictimTraceFraction.

Fig. 5. Results for G2004c with different IDPF node coverages. (a) V ictimFraction. (b) AttackFraction. (c) V ictimTraceFraction.

8/6/2019 ITJNS01

11/15

packet filtering performance should be close to route-basedpacket filtering with precise global routing information. Asdiscussed in Section 6.2.2, we use the shortest path on the ASgraph for a given pair of source and destination toapproximate the precise route between the pair. As shownin Fig. 9, the availability of the precise routing information

between any pair of source and destination only slightlyimproves the AttackF raction of IDPFs in comparison tothecase where BGP updateinformation is used. Forexample,although about 84 percent of nodes cannot be used byattackers to launch any spoofing-based attacks by relying on

the precise routing information, there are still about80 percent of ASs where an attacker cannot launch any suchattacks by solely relying on the BGP update information.However, the traceback ability is more significantly affected.By only relying on the BGP update information, an arbitraryAS can still pinpoint the true origin of an attack packet to be

within 28 ASs compared to 7 if precise global routinginformation is available.Figs. 10 and 11 show the results when the IDPF nodes are

selectedwiththe T op and Rndmethods,respectively.ForbothIDPF node selection schemes, the precise routing information(versus BGPupdates)has littleimpact on AttackFraction andhassignificantimpact on V ictimTraceFraction. These resultsindicate that using local BGP updates does not significantlyaffect the IDPFs ability to limit the spoofing capability ofattackers but may affect the traceback accuracy. This conclu-sion applies to both T op and Rnddeployment scenarios.

6.3.3 Impacts of Overlapping Prefixes

Fig. 12 shows the impact of overlapping prefixes. In Fig. 12a,

we see that overlapping prefixes only have a relatively


Fig. 8. The Rnd method with different percentages of IDPF nodes. (a) V ictimFraction. (b) AttackFraction. (c) V ictimTraceFraction.

Fig. 7. The T op method with different percentages of IDPF nodes. (a) V ictimF raction. (b) AttackFraction . (c) V ictimTraceFraction.

Fig. 9. Precise routing information versus BGP update information(G2004c, VC).

Fig. 10. The T op method with different percentages of IDPF nodes.

(a)AttackFraction

. (b)V ictimTraceFraction

.

Fig. 11. The Rnd method with different percentages of IDPF nodes.

(a)AttackFraction

. (b)V ictimT raceFraction

.

8/6/2019 ITJNS01

12/15

moderate impact on limiting the spoofing capability ofattackers. For example, an attacker of about 50 percent nodescannot spoof IP addresses of any other nodes. Fig. 12bdemonstrates that overlapping prefixes may significantly

affect the ability of nodes to pinpoint the true origin of anattack packet. However, we speculate that this is caused byISPs that announce less specific prefixes that contain morespecific prefixes announced by other ASs. To verify this, weintroduce another metric V ictimTraceFraction99, whichis defined with respect to 99 percent of jCs;tj. Formally,

V ictimTraceFraction99

jft : 8s 2 V ; PjCs;tj 99%gj

jVj:

V ictimTraceF raction99 can be interpreted as follows:Foran attack packet with an arbitraryIP source address, with

a 99 percent probability, we canpinpoint thetrue origin of the

packet to be within ASs. Fig. 12c presents the values ofV ictimTraceF raction99.Inthisfigure,weseethatformorethan 99 percent of IP addresses of attack packets, a node canpinpoint the true origin to be within 79 nodes.

Figs. 13 and 14 show the results when the IDPF nodesare selected with the T op and Rnd methods, respectively.For the T op method, overlapping prefixes slightlyaffect AttackFraction but may significantly changeV ictimTraceF raction. For example,

V ictimTraceF raction1000

changes from 100 percent with nonoverlapping prefixes to0 percent with overlapping prefixes for all the percentagesplotted in Fig. 13.For theRndmethod, as shown in Fig. 14,theimpact on AttackFraction is negligible, whereas the impacton V ictimTraceF raction is significant. These results are inline with theresults for theVC coverage,which indicatesthat

the conclusion applies to both IDPF node selection schemes.


Fig. 12. Impact of overlapping prefixes (G2004c,VC; note that scales are different). (a) AttackFraction. (b) V ictimTraceFraction.

(c) V ictimT raceFraction99.

Fig . 1 3. The T op method with dif ferent percentages of IDPF nodes. (a) AttackFraction. (b) V ictimTraceFraction.

(c) V ictimTraceFraction99.

Fig . 1 4. The Rnd method with dif ferent percentages of IDPF nodes. (a) AttackFraction. (b) V ictimTraceFraction.

(c) V ictimTraceFraction99.

8/6/2019 ITJNS01

13/15

6.3.4 Deployment Incentives

This section studies the incentives for an AS to deploy IDPFs.The deployment incentive is the keyfactor that is responsiblefor the slow deployment of network ingress filtering. Figs. 15

and 16 show the incentive for an AS to deploy IDPFs: the ASsthat deploy IDPFs are better protected than those that do notdeployIDPFs. Fig. 15 shows theresultswhenonly5 percent ofall nodes (randomly selected) deploy IDPFs, whereas Fig. 16shows the results when 30 percent of all nodes are IDPFnodes. We show the values of V ictimFractionIDPF (thecurve marked with IDPF Nodes) and V ictimFraction(marked with All Nodes). In Figs. 15 and 16, we see that inthe Rnd30 (Fig. 16) case although only about 5 percent of allnodes on theInternetcannot be attacked by attackers that canspoof IP addresses of more than 6,000 nodes, this percentageincreases to higher than 11 percent among the nodes thatsupport IDPFs. Moreover, as the value of increases, thedifferencebetweenthe twoenlarges.Similarly, although only

about 18 percent of all nodes on the Internet can pinpoint thetrue origin of an attack packet to be within 5,000 nodes, morethan 33 percent of nodes that support IDPFs can do so(Fig. 16b). Comparing Figs. 15 and 16, we can see that therelative benefit for deploying IDPF is larger when a smallernumber of nodes deploy IDPFs: there is more incentive todeploy IDPFs when a smaller number of ASs in the Internetare IDPF nodes.

Figs. 15c and 16c compare the spoofing capability ofattackers in attacking a general node on the Internet andthat support IDPFs. We see that networks supporting IDPFsonly gain slightly in this perspective. This can be under-stood by noting that by deploying IDPFs, an AS protects not

only itself but also those to whom the AS transports traffic.

6.3.5 IDPFs with and without Network Ingress Filtering

So far, we have assumed that networks supporting IDPFs

also employ network ingress packet filtering [25]. In this

section, we examine the implications of this assumption.

InFig.17,we canseethatingresspacketfiltering indeed hasan impact on the effectiveness of IDPFs in limiting the

spoofing capability of attackers. However, without network

ingress filtering, we still have more than 60 percent of nodes

from which an attacker cannot launch any spoofing-based

attacks, as compared to 80 percent when ingress filtering is

enabled at nodes supporting IDPFs. As shown in Fig. 18, the

impact of network ingress filtering on the effectiveness of

IDPFs in terms of reactive IP traceback is not very large.

Without ingress filtering, an arbitrary node can pinpoint the

true origin of an attack packet to be within 87 nodes, as

compared to 28 when networks supporting IDPFs also

employ ingress filtering.We havealso performedsimulationswith different IDPF node selection schemes, and the trend in

the results is similar to those displayed in Figs. 17 and 18.


Fig. 15. Deployment incentives (G2004c, Rnd5). (a) V ictimF ractionIDPF versus V ictimFraction. (b) V ictimTraceFractionIDPF versus

V ictimT raceFraction. (c) AttackFractionIDPF versus AttackFraction.

Fig. 16. Deployment incentives (G2004c, Rnd30). (a) V ictimFractionIDPF versus V ictimFraction. (b) V ictimT raceFractionIDPF versus

V ictimT raceFraction. (c) AttackFractionIDPF versus AttackFraction.

Fig. 17. IDPF with and without ingress filtering (G2004c

, VC).

8/6/2019 ITJNS01

14/15

7 CONCLUSION

In this paper, we have proposed and studied an IDPFarchitecture as an effective countermeasure to the IP spoof-ing-based DDoS attacks. IDPFs rely on BGP update messagesexchanged on the Internet to infer the validity of sourceaddress of a packetforwarded by a neighbor.We showed thatIDPFs can easily be deployed on the current BGP-basedInternet routing architecture. We studied the conditionsunder which theIDPF frameworkcan correctlywork withoutdiscarding any valid packets. Our simulation results showedthat, even with partial deployment on the Internet, IDPFs can

significantly limit the spoofing capability of attackers. More-over, they also help pinpoint the true origin of an attackpacket to be within a small number of candidate networks,thus simplifying the reactive IP traceback process.

ACKNOWLEDGMENTS

The authors would like to thank Kihong Park, Heejo Lee,and Ali Selcuk for providing the dpf simulation tool. Theyalso thank the Oregon Route Views Project for making BGProuting tables and updates publicly available. Z. Duan wassupported in part by the US National Science Foundation(NSF) Grant CCF-0541096. Y. Xin was supported in part byNSF Grants ANI-0106706, CCR-0208892, CCF-0342540, andCCF-0541096. J. Chandrashekar was supported in part byNSF Grants ITR-0085824 and CNS-0435444, and a CiscoURP Grant. Any opinions, findings, and conclusions orrecommendations expressed in this paper are those of theauthors and do not necessarily reflect the views of US NSFor Cisco Systems. A preliminary version of this paperappeared in the Proceedings of the IEEE INFOCOM 2006 withthe title Constructing Inter-Domain Packet Filters toControl IP Spoofing Based on BGP Updates.

REFERENCES[1] ICANN SSAC Advisory SAC008 DNS Distributed Denial of Service

(DDoS) Attacks, Mar. 2006.[2] C. Labovitz, D. McPherson, and F. Jahanian, InfrastructureAttack Detection and Mitigation, Tutorial, Proc. ACM SIGCOMM,Aug. 2005.

[3] R. Beverly and S. Bauer, The Spoofer Project: Inferring the Extentof Internet Source Address Filtering on the Internet, Proc. FirstUsenix Steps to Reducing Unwanted Traffic on the Internet Workshop,

July 2005.[4] S. Kandula, D. Katabi, M. Jacob, and A. Berger, Botz-4-Sale:

Surviving Organized DDoS Attacks that Mimic Flash Crowds,Proc. Second Symp. Networked Systems Design and Implementation,2005.

[5] D. Moore, C. Shannon, D. Brown, G. Voelker, and S. Savage,Inferring Internet Denial-of-Service Activity, ACM Trans.Computer Systems, vol. 24, no. 2, May 2006.

[6] R. Pang, V. Yegneswaran, P. Barford, V. Paxson, and L. Peterson,Characteristics of Internet Background Radiation, Proc. ACM

Internet Measurement Conf., Oct. 2004.

[7] S. Savage, D. Wetherall, A. Karlin, and T. Anderson, PracticalNetwork Support for IP Traceback, Proc. ACM SIGCOMMComputer Comm. Rev., vol. 30, no. 4, Oct. 2000.

[8] P. Watson, Slipping in the Window: TCP Reset Attacks, Proc.Fifth CanSecWest/core04 Conf., 2004.

[9] J. Stewart, DNS Cache PoisoningThe Next Generation,technical report, LURHQ, Jan. 2003.

[10] V. Paxson, An Analysis of Using Reflectors for DistributedDenial-of-Service Attacks, ACM Computer Comm. Rev., vol. 31,

no. 3, July 2001.[11] CERT Advisory ca-1996-21 TCP SYN Flooding and IP SpoofingAttacks,CERT, http://www.cert.org/advisories/CA-1996-21.html, 1996.

[12] K. Park and H. Lee, On the Effectiveness of Route-Based PacketFiltering for Distributed DoS Attack Prevention in Power-LawInternets, Proc. ACM SIGCOMM, Aug. 2001.

[13] Y. Rekhter and T. Li, A Border Gateway Protocol 4 (BGP-4), RFC1771, Mar. 1995.

[14] L. Gao, On Inferring Autonomous System Relationships in theInternet, IEEE/ACM Trans. Networking, vol. 9, no. 6, Dec. 2001.

[15] L. Gao and J. Rexford, Stable Internet Routing without GlobalCoordination, IEEE/ACM Trans. Networking, vol. 9, no. 6, Dec.2001.

[16] G. Huston, Interconnection, Peering and Settlements: Part I, TheInternet Protocol J., Mar. 1999.

[17] F. Baker, Requirements for IP Version 4 Routers, RFC 1812, June

1995.[18] Unicast Reverse Path Forwarding Loose Mode,Cisco Systems,http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newf%t/122t/122t13/ft_urpf.pdf, 2007.

[19] C. Jin, H. Wang, and K. Shin, Hop-Count Filtering: An EffectiveDefense against Spoofed DDoS Traffic, Proc. 10th ACM Conf.Computer and Comm. Security, Oct. 2003.

[20] A. Yaar, A. Perrig, and D. Song, Pi: A Path IdentificationMechanism to Defend against DDoS Attacks, Proc. IEEE Symp.Security and Privacy, May 2003.

[21] A. Yaar, A. Perrig, and D. Song, StackPi: New Packet Markingand Filtering Mechanisms for DDoS and IP Spoofing Defense,IEEE J. Selected Areas in Comm., vol. 24, no. 10, Oct. 2006.

[22] J. Li, J. Mirkovic, M. Wang, P. Reiher, and L. Zhang, Save: SourceAddress Validity Enforcement Protocol, Proc. IEEE INFOCOM,

June 2002.[23] A. Bremler-Barr and H. Levy, Spoofing Prevention Method,

Proc. IEEE INFOCOM, Mar. 2005.[24] X. Liu, X. Yang, D. Wetherall, and T. Anderson, Efficient andSecure Source Authentication with Packet Passport, Proc. SecondUsenix Workshop Steps to Reducing Unwanted Traffic on the Internet(SRUTI 06), July 2006.

[25] P. Ferguson and D. Senie, Network Ingress Filtering: Defeating Denialof Service Attacks Which Employ IP Source Address Spoofing, RFC2267, Jan. 1998.

[26] The Team Cymru Bogon Route Server Project,Team Cymru,http://www.cymru.com/BGP/bogon-rs.html, 2007.

[27] J. Stewart, BGP4: Inter-Domain Routing in the Internet. Addison-Wesley, 1999.

[28] W. Xu and J. Rexford, Miro: Multi-Path Interdomain Routing,SIGCOMM Computer Comm. Rev., vol. 36, no. 4, Oct. 2006.

[29] L. Gao, T. Griffin, and J. Rexford, Inherently Safe Backup Routingwith BGP, Proc. IEEE INFOCOM, 2001.

[30] J. Chandrashekar, Z. Duan, Z.-L. Zhang, and J. Krasky, Limiting

Path Exploration in BGP, Proc. IEEE INFOCOM, Mar. 2005.[31] V. Fuller, T. Li, J. Yu, and K. Varadhan, Classless Inter-DomainRouting (CIDR): An Address Assignment and AggregationStrategy, RFC 1519, Sept. 1993.

[32] Z. Duan, X. Yuan, and J. Chandrashekar, Constructing Inter-Domain Packet Filters to Control IP Spoofing Based on BGPUpdates, Proc. IEEE INFOCOM, Apr. 2006.

[33] Route Views Project, Univ. of Oregon, http://www.routeviews.org/, 2007.

[34] X. Dimitropoulos, D. Krioukov, and G. Riley, Revisiting InternetAs-Level Topology Discovery, Proc. Sixth Intl Workshop Passiveand Active Measurement, Mar. 2005.

[35] D. Moore, V. Paxson, S. Savage, C. Shannon, S. Staniford, and N.Weaver, Inside the Slammer Worm, Proc. IEEE Symp. Securityand Privacy, 2003.


Fig. 18. IDPF with and without ingress filtering ( G2004c, VC).

8/6/2019 ITJNS01

15/15

Zhenhai Duan (S 97-M 03) received the BSdegree in computer science from ShandongUniversity, China, in 1994, the MS degree incomputer science from Beijing University, Beij-ing, in 1997, and the PhD degree in computerscience from the University of Minnesotain 2003.He is currently an assistant professor in theDepartment of Computer Science, Florida StateUniversity. His research interests include com-

puter networks and multimedia communications,especially scalable network resource control and management in theInternet, Internet routing protocols and service architectures, andnetworking security. He is a corecipient of the Best Paper Awards in the10thIEEE International Conference on Network Protocols (ICNP 02) andthe 15th IEEE International Conference on Computer Communicationsand Networks (ICCCN 06). He is a member of the IEEE and the ACM.

Xin Yuan (M98) received the BS and MSdegrees in computer science from ShanghaiJiaotong University in 1989 and 1992, respec-tively, and the PhD degree in computer sciencefrom the University of Pittsburgh in 1998. He iscurrently an associate professor in the Depart-ment of Computer Science, Florida State Uni-versity. His research interests include paralleland distributed systems, compilers, and network-

ing. He is a member of the IEEE and the ACM.

Jaideep Chandrashekar received the BE de-gree from Bangalore University, India, in 1997and the PhD degree from the University ofMinnesota in December 2005. He is currentlywith Intel Research, Santa Clara, California. Hisresearch interests include computer networksand distributed systems, especially Internet tech-nologies, network routing,and computersecurity.He is a member of the IEEE and the ACM.

. For more information on this or any other computing topic,please visit our Digital Library at www.computer.org/publications/dlib.


ITJNS01

Documents