BasepaperControlling IP Spoofing through Interdomain Packet Filters

Controlling IP Spoofing throughInterdomain Packet Filters

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

Abstract—The 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 and are deployed in network border routers. We establish the conditions under which the IDPF framework

correctly works in that it does not discard packets with valid source addresses. Based on extensive simulation studies, we show that, 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 Terms—IP 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 in

recent 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 alarge part of the Internet is vulnerable to IP spoofing [3].

Recently, attackers have increasingly been stagingattacks 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 tobelieve 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 thepackets 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 pðs; dÞbetween the source node s and the destination node d. Hence,any packet with the source address s and the destinationaddress d that appear in a router that is not in pðs; dÞ should bediscarded. The challenge is that constructing such a route-based packet filter requires the knowledge of global routinginformation, which is hard to reconcile in the current 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 a policy-based routing protocol inthat both the selection and the propagation of the best route toa 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 for an 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

based on the locally exchanged BGP updates, assuming thatall ASs employ a set of routing policies that are commonlyused today [14], [15], [16]. The key contributions of this paperare given as follows: First, we describe how we can practicallyconstruct IDPFs at an AS by only using the information in thelocally exchanged BGP updates. Second, we establish theconditions under which the proposed IDPF frameworkworks 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-er’s ability to spoof packets. When a spoofed packet cannot bestopped, 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 idea of IDPF is motivated by the work carried out by Parkand 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 IPspoofing when deployed in just a small number of ASs. In thiswork, we extend the idea and demonstrate that 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 theforwarding 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 tothe end system. Packets that arrive with a different hop 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. Victim nodes can filter packets based on the Pi carried inthe packet header. StackPi [21] improved the incrementaldeployment property of Pi by proposing two new packetmarking schemes. In [22], Li et al. described SAVE, which is 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

filters by using the prefix and path information. Bremler-Barrand Levy proposed a spoofing prevention method (SPM) [23],where packets that were exchanged between members of theSPM scheme carry an authentication key that is associatedwith the source and destination AS domains. Packets arrivingat 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 of bogon network prefixes that arenot 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, this mechanism cannot filter out attack packetscarrying routable but spoofed source addresses.

3 BORDER GATEWAY PROTOCOL AND

AS 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 eðu; vÞ 2 E represents a BGPsession 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 are the path vectorattribute as_path, which is the sequence of ASs that thisroute has been propagated over, and the local_pref

attribute 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 ¼ hvkvk�1 . . . v1v0i. The route was originated (firstannounced) by node v0, which owns the network prefixr.prefix. Before arriving at node vk, the route was carriedover nodes v1; v2; . . . ; vk�1 in that order. For i ¼ k, k� 1; . . . ; 1,we say that edge eðvi; vi�1Þ is on the AS path, that is,eðvi; vi�1Þ 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 d is alsoused to denote the network prefixes owned by the AS d. Asa consequence, a route r that can be used to reach the

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

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 byimportðv uÞ½frg� the possibly modified route that hasbeen transformed by the import policies. The transformedroutes are stored in v’s routing table. The set of all suchroutes is denoted as candidateRðv; dÞ:

candidateRðv; dÞ ¼ fr : importðv uÞ½frg� 6¼ fgr:prefix ¼ d; 8u 2 NðvÞg:

ð1Þ

Here, NðvÞ is the set of v’s neighbors.Among the set of candidate routes candidateRðv; dÞ, node

v selects a single best route to reach the destination based on awell-defined procedure (see [27]). To aid in description, weshall denote the outcome of the selection procedure at node v,that is, the best route, as bestRðv; dÞ, which reads the best routeto destination d at node v. Having selected bestRðv; dÞ fromcandidateRðv; 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, they modify the route attributes accordingto the policies (see Section 3.2). We denote by exportðv!uÞ½frg� 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 betweenneighbors, and we say that the routing system is in a stablestate. Formally,

Definition 1 (stable routing state). A routing system is in astable state if all the 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 customerAS 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 ASs providemutual transit service to each other. Each sibling AScan be regarded as the provider of the other AS.

An AS’s 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.customerðvÞ, peerðvÞ, providerðvÞ, and siblingðvÞ 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 theexport 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 mayprefer 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

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. Ifeðu; vÞ 2 bestRðs; 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 ¼ bestUðs; d; vÞ. For easeof 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, and an edge connecting sibling (peering) ASs as sibling-to-sibling (peer-to-peer) edge. A downhill path is a sequence ofedges that are either provider-to-customer or sibling-to-sibling edges, and an uphill path is a sequence of edges that areeither 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 BGProute 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 Mðs; 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 acceptspacket Mðs; dÞ that is forwarded from node u if and only ifeðu; vÞ 2 bestRðs; 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 bestRðs; dÞ. Computing route-based packetfilters requires the knowledge of bestRðs; 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 the two nodes. Topological routes are implied by thenetwork connectivity. A topological route is a feasible routeunder BGP if and only if the construction of the route does notviolate the routing policies imposed by the commercialrelationship between ASs (Tables 1 and 2). Formally, letfeasibleRðs; dÞ denote the set of feasible routes from s to d.Then, feasibleRðs; dÞ can recursively be defined as follows:

feasibleRðs; dÞ ¼fhs� [ feasibleRðu; dÞig;

u :

importðs uÞ½frg� 6¼ fg;r:prefix ¼ d; u 2 NðsÞ

where � is the concatenation operation, for example, fs�fhabi; huvigg ¼ fhsabi; hsuvig. Notice that feasibleRðs; dÞcontains all the routes between the pair that does notviolate the import and export routing policies specified inTables 1 and 2. Obviously, bestRðs; dÞ 2 candidateRðs; dÞ �feasibleRðs; dÞ. Eachof the feasibleroutes canpotentially be acandidate route in a BGP routing table. Theorem 1 also appliesto feasible routes.

Definition 4 (feasible upstream neighbor). Consider afeasible route r 2 feasibleRðs; dÞ. If an edge eðu; vÞ is onthe feasible route, that is, eðu; vÞ 2 r:as path, we say thatnode u is a feasible upstream neighbor of node v for packetMðs; dÞ. The set of all such feasible upstream neighbors of v(for Mðs; dÞ) is denoted as feasibleUðs; d; vÞ.The intuition behind the IDPF framework is the following:

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 bestRðs; dÞ 2 candidateRðs; dÞ �feasibleRðs; dÞ, a node can only allow Mðs; 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 of feasibleRðs; dÞ. Consider the example inFig. 1. Figs. 2a and 2b present the topological routes impliedby the network connectivity and feasible routes constrainedby 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 that are supported by routing policies. Of moreimportance to IDPF is that although the network topologymay imply that all neighbors can forward a packet allegedlyfrom a source to a node, feasible routes constrained by routingpolicies help limit the set of such neighbors. As an example,


let us consider the situation 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 onfeasibleRðs; dÞ instead of bestRðs; dÞ. However, feasibleUðs; d; vÞ can be inferred from local BGP updates, whereasbestUðs; d; vÞ cannot.

4.2 Constructing IDPFs

The following lemma summarizes the technique foridentifying the feasible upstream neighbors of node v forpacket Mðs; dÞ:Lemma 1. Consider a feasible route r between source s and

destination d. Let v 2 r:as path and let u be the feasibleupstream neighbor of node v along r. When the routing systemis stable, exportðu! vÞ½fbestRðu; sÞg� 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 Mðs; 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 indirectcustomers/siblings, we know that u will propagate to(provider) node v the reachability information of s.

Case 2. eðu; 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 eðx; 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 informationof s 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 Mðs; dÞ and conduct IDPF asfollows:

Definition 5 (IDPF). Node v will accept packet Mðs; dÞ that isforwarded by a neighbor node u if and only if exportðu! vÞ½fbestRðu; sÞg� 6¼ fg. Otherwise, the source address of thepacket 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 bestRðs; dÞ:as path suchthat v deploys an IDPF. To prove the theorem, we need toestablish that v will not discard packet Mðs; dÞ forwardedby the best upstream neighbor u along bestRðs; dÞ.

S ince bestRðs; dÞ 2 candidateRðs; dÞ � feasibleRðs; dÞ, u is also a feasible upstream neighbor of node v forpacket Mðs; dÞ. From Lemma 1, u must have exported tonode v its best route to source s. That is, exportðu! vÞ½fbestRðu; sÞg� 6¼ fg. From Definition 5, packet Mðs; dÞ,which is forwarded by node u, will not be discarded by v.tuNotice that the destination address d in a packet Mðs; dÞ

does not play a role in an IDPF node’s 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 OðN2Þ to OðNÞ, where N ¼ jV jis 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 ispropagated 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 feasibleRðs; dÞ, which is afunction of the (relatively static) AS relationships. Hence,how the BGP updates are propagated 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 theexport 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.

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 andb 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 r2

learned 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 and a backup provider 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 2or 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 Mðs; 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, launchinga 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 thegeneration 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 are static, which is true in most cases. Hence, forthe first type of routing dynamics (network failure), there is


Fig. 3. Automatic backup route.

Fig. 4. Conditional route advertisement.

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 ¼ bestUðs; d; vÞ andU ¼ feasibleUðs; d; vÞ. A link or router failure between u ands can have three outcomes: 1) ASu can still reach AS s, andu isstill chosen to be the best upstream neighbor for packetMðs; dÞ, that is, u ¼ bestUðs; d; vÞ. In this situation, althoughu may explore and announce multiple routes to v during thepath exploration process [30], the filtering function of v isunaffected. 2) ASu is no longer the best upstream neighbor forpacket Mðs; dÞ, and another feasible upstream neighbor u0 2U can reach AS s and is instead chosen to be the new bestupstream neighbor (for Mðs; 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) packetMðs; 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 packetMðs; 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 the IDPF and the originator of the prefix andindependent of the number of alternate paths between thetwo. Previous work has established this bound to be OðLÞ,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 to allow a neighbor to 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, not discarding spoofed packets for this 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 the IDPF architecture, all ASs along the path from s to d canspoof the source address of s and reach d without beingfiltered out. The route-based packet filtering has a similar

behavior. Due to this property, IDPF is most effective whendifferent ASs own nonoverlapping prefixes. For example, letsbe 1.2/16. Then, all ASs along the path from s to d can spoofthis prefix. Now, if there is a more specific address s0 ¼1:2:3=24 somewhere in the network, all these ASs can now alsospoof s0, since a more specific prefix also matches a moregeneral prefix. This situation does not happen when prefixesare not overlapped. Hence, statistically, IDPF is more effectivewhen 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 Metrics

We 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 ofincentive, that is, how an individual AS will benefit fromdeploying IDPF on its routers.

We use the performance metrics introduced in [12] in ourstudy. Given any pair of ASs, say, a and t, Sa;t is the set of ASsfrom which an attacker in AS a can forge addresses to 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 victim’s perspective. This quantifiesthe size of the set of ASs that can forge an address belongingto s in sending packets to t without being discarded alongthe 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 � �gjjV j :

V ictimFractionð�Þ, which is redefined from [12], denotesthe proportion of ASs that satisfy the following propertythat if an arbitrary attacker intends to generate spoofedpackets, it can successfully use the IP addresses of at most �


ASs (note that this includes the attacker’s 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 ictimFractionð1Þ, 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 attacker’s perspective.

Given G ¼ ðV ;EÞ, AttackFractionð�Þ, as defined in [12],

describes the fraction of ASs from which an attacker can

forge addresses belonging to at most � ASs (including the

attacker’s own) in attacking any other ASs in the graph:

AttackFractionð�Þ ¼ jfa : 8t 2 V ; jSa;tj � �gjjV j :

Intuitively, AttackFractionð�Þ is the strength of IDPFs in

limiting the spoofing capability of an arbitrary attacker. For

instance, AttackFractionð1Þ quantifies the fraction of ASs

from which an attacker cannot spoof any address other than

its own.

6.1.2 Reactive IP Traceback Metrics

To evaluate the effectiveness of IDPFs in reducing the IP

traceback effort, that is, the act of determining the true origin

of spoofed packets, V ictimTraceFractionð�Þ is defined in

[12], which is the proportion of ASs being attacked that can

localize the true origin of an attack packet to be within � ASs:

V ictimTraceFractionð�Þ ¼ jft : 8s 2 V ; jCs;tj � �gjjV j :

For instance, V ictimTraceFractionð1Þ is simply the fraction

of ASs, which, when attacked, can correctly identify the

(single) source AS from which the spoofed packet was

originated.

6.1.3 Incentives to Deploy IDPF

To formally study the gains that ASs might accrue

by deploying IDPFs on their border routers, we

introduce a related set of metrics: V ictimFractionIDPF ð�Þ,AttackFractionIDPF ð�Þ, and V ictimTraceFractionIDPF ð�Þ.Let T denote the set of ASs that support IDPFs:

V ictimFractionIDPF ð�Þ ¼jft 2 T : 8a 2 V ; jSa;tj � �gj

jT j ;

AttackFractionIDPF ð�Þ ¼jfa 2 V : 8t 2 T; jSa;tj � �gj

jV j ;

V ictimTraceFractionIDPF ð�Þ ¼jft 2 T : 8s 2 V ; jCs;tj � �gj

jT j :

Note that these are similar to the metrics defined

earlier, that is, V ictimFractionð�Þ, AttackFractionð�Þ, andV ictimTraceFractionð�Þ, respectively. However, we re-

strict the destinations to the set of IDPF-enabled ASs

rather than the entire population of ASs.Note also that V ictimFractionð�Þ, AttackFractionð�Þ,

and V ictimTraceFractionð�Þ correspond to �1ð�Þ, �2ð�Þ,and 1ð�Þ in [32], respectively. We rename them to facilitate

easier understanding.

6.2 Data Sets

In order to evaluate the effectiveness of IDPFs, we constructfour AS graphs from the BGP data archived by the RouteViews Project [33]. The first three graphs, denotedG2003,G2004,andG2005, are constructed from single routing table snapshots(taken from the first day of each of the years). Although theseprovide an indication of the evolutionary trends in the growthof 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 G2004c

by combiningG2003 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 during this period of time. This had the side effect ofexposing 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 graphcorresponding 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; vk�1; . . . ; v0i associatedwith prefix P , we take this as an indication that vi announcedthe route for P to viþ1, that is, vi 2 feasibleUðP; viþ1Þ,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, inorder to compute the described performance metrics, we require the


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 arequite stable and, thus, the number is likely to be very small.

TABLE 3Graphs Used in the Performance Studies

exact routes that will be taken between any pairs of nodes.Unfortunately, there is simply no easy way to accurately getthis knowledge. In this paper, as a heuristic, we simply use theshortest path on G. When there are multiple candidates, wearbitrarily select one of them. As a consequence, in addition toAS paths, we also include the selected shortest path as afeasible route if it has not been described in the routingupdates observed. Note that this knowledge, that is, the bestpath from an AS to another, is only required in the simulationstudies to determine the IDPFs thata packet mayencounter onthe way from the source to the destination. It is not required inthe construction of the IDPFs. Note also that due to the way thatfeasible neighbors are computed, the effectiveness of IDPFsmay artificially be inflated, since the set of feasible neighborsof a node in our simulations is a subset of feasible neighbors ofthe 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 Top, 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 asRnd, werandomly (uniformly) choose the nodes from V until adesirable proportion of nodes are chosen. We will use thenotionsRndX and TopX to denote the selection ofX percentof all nodes for deploying IDPFs using the Rnd and Topmethods, respectively. For example, Rnd30 representsselecting 30 percent of nodes to be IDPF nodes using theRnd method. Note that ASs with high degrees are normallyInternet service providers. In particular, tier-1 serviceproviders normally have higher degrees than others. There-fore, the Topmethod will likely select tier-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 detecting spoofed traffic. On the other hand,the Rnd method may represent a more realistic IDPFdeployment scenario, where ASs decide whether to deployIDPF independently.

6.3 Results of Performance Studies

The studies are performed with the Distributed Packet Filtering(dpf) simulation tool [12]. We extended dpf to support our ownfilter construction based on BGP updates and to deal withoverlapping prefixes. We evaluated the performance of IDPFsby using the three performance metrics (V ictimFractionð�Þ,AttackFractionð�Þ, and V ictimTraceFractionð�Þ) 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 can significantly limit the spoofing capability ofan attacker. For example, with the V C IDPF coverageon the 2004c data set, an attacker in more than80 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 be within28 ASs, thus greatly reducing the effort of IP traceback.In this summary, unless specified otherwise, allexample data are based on the VC IDPF coverage onthe 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 BGPupdates 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 workreasonably well with overlapping prefixes announcedon the Internet. For example, in this case, an attacker inabout 50 percent of the ASs cannot launch anyspoofing-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 of V ictimFractionð�Þ for threedifferent ways of selecting the IDPF node on the G2004c

graph: 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 IPaddresses of at most � nodes. As discussed earlier, IDPFs


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 controllingspoofing-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 C coverage. 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 in

limiting the spoofing capability of attackers. In particular,AttackFractionð1Þ is the proportion of nodes from which anattacker cannot launch any spoofing-based attacks againstany other nodes. Fig. 5b shows that IDPFs are very effectivein this regard. For G2004c, AttackFractionð1Þ ¼ 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 ictimTraceFractionð�Þ 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; seeFig. 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, thetrend 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 Top 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 Topmethod is significantly more effective than the Rnd scheme,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 significantly limit the spoofing capability ofthe attackers and increase the traceback accuracy. Moreover,the performance of IDPFs with 5 percent of all the nodesselected by the Top 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 away 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ð�Þ.

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 informationbetween any pair of source and destination only slightlyimproves the AttackFractionð�Þ of IDPFs in comparison tothe case where BGP update information is used. For example,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 bewithin 28 ASs compared to 7 if precise global routinginformation is available.

Figs. 10 and 11 show the results when the IDPF nodes areselected with theTopandRndmethods, respectively. For bothIDPF node selection schemes, the precise routing information(versus BGP updates) has little impact onAttackFraction andhas significant impact onV 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 Top and Rnd deployment 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 Top method with different percentages of IDPF nodes. (a) V ictimFractionð�Þ. (b) AttackFractionð�Þ. (c) V ictimTraceFractionð�Þ.

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

Fig. 10. The Top 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 ictimTraceFractionð�Þ.

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 significantlyaffect 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 ; P ðjCs;tj � �Þ ¼ 99%gjjV j :

V ictimTraceFraction99ð�Þ can be interpreted as follows:For an attack packet with an arbitrary IP source address, witha 99 percent probability, we can pinpoint the true origin of the

packet to be within � ASs. Fig. 12c presents the values ofV ictimTraceFraction99ð�Þ. In this figure, we see that for morethan 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 Top and Rnd methods, respectively.For the Top method, overlapping prefixes slightlyaffect AttackFractionð�Þ but may significantly changeV ictimTraceFractionð�Þ. For example,

V ictimTraceFractionð1000Þ

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 ictimTraceFraction is significant. These results are inline with the results for the VC coverage, which indicates thatthe 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 ictimTraceFraction99ð�Þ.

Fig. 13. The Top method with different percentages of IDPF nodes. (a) AttackFractionð�Þ. (b) V ictimTraceFractionð�Þ.(c) V ictimTraceFraction99ð�Þ.

Fig. 14. The Rnd method with different percentages of IDPF nodes. (a) AttackFractionð�Þ. (b) V ictimTraceFractionð�Þ.(c) V ictimTraceFraction99ð�Þ.

6.3.4 Deployment Incentives

This section studies the incentives for an AS to deploy IDPFs.The deployment incentive is the key factor that is responsiblefor the slow deployment of network ingress filtering. Figs. 15and 16 show the incentive for an AS to deploy IDPFs: the ASsthat deploy IDPFs are better protected than those that do notdeploy IDPFs. Fig. 15 shows the results when only 5 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 the Internet cannot 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, thedifference between the two enlarges. Similarly, although onlyabout 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 notonly 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.In Fig.17,wecanseethat ingresspacket filtering indeedhas

an 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 have also performed simulations

with 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 ictimFractionIDPF ð�Þ versus V ictimFractionð�Þ. (b) V ictimTraceFractionIDPF ð�Þ versus

V ictimTraceFractionð�Þ. (c) AttackFractionIDPF ð�Þ versus AttackFractionð�Þ.

Fig. 16. Deployment incentives (G2004c, Rnd30). (a) V ictimFractionIDPF ð�Þ versus V ictimFractionð�Þ. (b) V ictimTraceFractionIDPF ð�Þ versus

V ictimTraceFractionð�Þ. (c) AttackFractionIDPF ð�Þ versus AttackFractionð�Þ.

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

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 packet forwarded by a neighbor. We showed thatIDPFs can easily be deployed on the current BGP-basedInternet routing architecture. We studied the conditionsunder which the IDPF framework can correctly work withoutdiscarding any valid packets. Our simulation results showedthat, even with partial deployment on the Internet, IDPFs cansignificantly 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. ACMInternet 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 Poisoning—The 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, June1995.

[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, “LimitingPath 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 Int’l 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).

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 Minnesota in 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 the10th IEEE 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 (M’98) 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 computer security.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.


Documents

BasepaperControlling IP Spoofing through Interdomain Packet Filters