436 IEEE TRANSACTIONS ON INFORMATION FORENSICS AND …netarchlab.tsinghua.edu.cn/~junbi/TIFS-2014.pdf · 2014-08-21 · 436 IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY,

436 IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY, VOL. 9, NO. 3, MARCH 2014

Toward Incentivizing Anti-Spoofing DeploymentBingyang Liu, Jun Bi, Member, IEEE, and Athanasios V. Vasilakos, Senior Member, IEEE

Abstract— IP spoofing-based flooding attacks are a serious andopen security problem on the current Internet. The best currentantispoofing practices have long been implemented in modernrouters. However, they are not sufficiently applied due to thelack of deployment incentives, i.e., an autonomous system (AS)can hardly gain additional protection by deploying them. Inthis paper, we propose mutual egress filtering (MEF), a novelantispoofing method, which provides continuous deploymentincentives. The MEF is implemented on the AS border routersusing access control lists (ACLs). It drops an outbound packetwhose source address does not belong to the local AS if the packetis related to a spoofing attack against other MEF-enabled ASes.By this means, only the deployers of the MEF can gain protection,whereas nondeployers cannot free ride. As more ASes deployMEF, deployment incentives become higher. We present the sys-tem design of MEF, and propose an optimal prefix compressionalgorithm to compact the ACL into the routers’ limited hardwareresource. With theoretical analysis and simulations with realInternet data, our evaluation results show that MEF is theonly method that achieves monotonically increasing deploymentincentives for all types of spoofing attacks, and the system designis lightweight and practical. The prefix compression algorithmadvances the state-of-the-art by generalizing the functionalitiesand reducing the overhead in both time and space.

Index Terms— IP spoofing, spoofing prevention, DoS defense,deployment incentive.

I. INTRODUCTION

A. Background

Due to the destination based packet forwarding schemeof the current Internet, routers deliver IP packets withoutchecking the validity of the packets’ source addresses. Thisvulnerability allows end users to send IP packets with fakesource addresses, i.e., the addresses that are not assigned tothem, which is known as IP spoofing.

IP spoofing is prevalently used in denial of service (DoS)attacks, especially distributed flooding attacks, making them

Manuscript received September 7, 2013; revised December 11, 2013 andDecember 14, 2013; accepted December 16, 2013. Date of publicationJanuary 2, 2014; date of current version February 12, 2014. This work wassupported in part by the National High-Tech Research and DevelopmentProgram (“863” Program) of China under Grant 2013AA010605, in partby the National Science Foundation of China under Grant 61073172, andin part by the National Science and Technology Pillar Program of Chinaunder Grant 2012BAH01B01. The associate editor coordinating the reviewof this manuscript and approving it for publication was Prof. Wanlei Zhou.(Corresponding author: J. Bi.)

B. Liu and J. Bi are with the Institute for Network Sciences andCyberspace, and Department of Computer Science, Tsinghua University,Beijing 100084, China, and also with the Tsinghua National Laboratoryfor Information Science and Technology, Beijing 100084, China (e-mail:[email protected]; [email protected]).

A. V. Vasilakos is with the University of Western Macedonia, Macedonia15410, Greece (e-mail: [email protected]).

Color versions of one or more of the figures in this paper are availableonline at http://ieeexplore.ieee.org.

Digital Object Identifier 10.1109/TIFS.2013.2296437

harder to detect and prevent. These attacks can be classi-fied into two categories, d-DoS and s-DoS, correspondingto the victim being the destination addresses and the sourceaddresses of the spoofed packets, respectively. In d-DoS,attackers directly send packets to the victim with arbitrarysource addresses for anonymity. In s-DoS, IP spoofing isused for reflection. Attackers use the victim’s source addressesto send requests to innocent destination hosts, whose repliesthen flood the victim. The size of a reply is typically muchlarger than a request, which results in volume amplification,e.g., in a domain name system (DNS) amplification attack,a 60-byte DNS request can trigger a 4000-byte reply, yieldingan amplification factor of 73 [1].

The best current practices for anti-spoofing are BCP38 [2]and BCP84 [3]. Routers implementing the BCPs identifyspoofed packets by associating source address prefixes witha set of valid incoming interfaces of the packets. The func-tionalities of the BCPs are supported by most modern routers.If every network on the Internet applies them, spoofingactivities can be highly restricted. However, according to along-term measurement by Spoofer Project [4], around 38.5%autonomous systems (ASes) on the Internet are still spoofable,and the deployment ratio has not been improved for fouryears [5]. Recent spoofing based attacks [6], [7], including thehighest-speed flooding attack ever observed [8], also indicatethat the deployment is still insufficient.

B. Motivation

This paper is intended to facilitate the anti-spoofing deploy-ment to mitigate spoofing based flooding attacks on theInternet. In this subsection, we motivate our work by analyzingthe anti-spoofing BCPs’ technical flaws which hinder theiruniversal deployment. For clarity, we treat an AS as a unit ofdeployment since an AS is the unit of shared fate and policy.An AS becomes a deployer once it deploys AS-granularitysource address validation, which is enforced on AS borderrouters (ASBRs) and prevents inter-AS spoofing; otherwise itis a non-deployer.

The anti-spoofing BCPs consist of three techniques: ingressfiltering, egress filtering and unicast reverse path forwarding(uRPF).1 Both ingress filtering and egress filtering are imple-mented using access control lists (ACLs), and are collectivelydenoted by ingress/egress filtering (IEF). An ACL containsa list of rules, i.e., access control entries (ACEs), each ofwhich consists of a match and an associated action (permitor deny). Network operators can configure an ACL and apply

1The three techniques are also collectively known as ingress filtering. Weabandon this expression to avoid ambiguity.

1556-6013 © 2014 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

LIU et al.: TOWARD INCENTIVIZING ANTI-SPOOFING DEPLOYMENT 437

Fig. 1. Three techniques of the anti-spoofing BCPs. (a) Ingress filtering.(b) Egress filtering. (c) uRPF.

it on one or multiple interfaces of a router to process incomingor outgoing packets. uRPF uses the router’s forwarding table toidentify spoofed packets. Both ACLs and uRPF are commonfunctions on modern routers. The working principle of thethree techniques is shown in Fig. 1.

Ingress filtering is applied on the interfaces connectingneighbor ASes to verify inbound packets. If a neighbor ASis a stub, an ACL can be set to permit only the sourceaddresses belonging to that stub. When the stub’s addressspace changes, operators must learn the change and update theACL in time; otherwise genuine packets from that stub maybe dropped, causing false positives. If there are many stubneighbors, the operational cost and risk are significant. Fornon-stub neighbors, ingress filtering can only safely drop theinbound packets whose source addresses belong to the localaddress space, which is typically a very small fraction of theglobal routable address space, making it very ineffective.

Egress filtering is enforced on outbound packets, and onlythe packets whose source addresses belong to the local AS arepermitted. Compared with ingress filtering, egress filtering ismore effective since all the outbound spoofed packets exceptthose spoofing the addresses of the local AS can be filteredout. It incurs less operational cost since only a single ACLis maintained for the entire AS (the ACLs on all ASBRsare identical). The correctness of the ACL only depends onlocal information since it merely needs to match the addressesof the local AS. Thus, false positives can be avoided sincenetwork operators are able to learn the changes of the localaddress space in advance and update the ACL accordingly.The drawback of egress filtering is that it lacks deploymentincentives. By deploying egress filtering, an AS can onlyprevent sending out spoofed traffic, rather than protecting itselffrom receiving spoofed traffic [5].

uRPF reversely uses the forwarding table for spoofing iden-tification. It looks up the outgoing interface toward the sourceaddress of an incoming packet. The packet is identified asspoofed if the outgoing interface is different from the packet’sincoming interface. uRPF works correctly if forwarding pathsare symmetric. However under route asymmetry, which is veryprevalent on the current Internet, uRPF may drop genuinepackets, causing false positives.

To summarize, ingress filtering requires significant opera-tional cost to work correctly; otherwise it may cause falsepositives or be very ineffective. uRPF can only be appliedwhere operators can ensure path symmetry; otherwise it may

cause false positives. Egress filtering has good properties foreffectiveness, operational cost and false positives. However,the drawback is that it lacks deployment incentives. Thismotivates us to improve the incentives of egress filtering toprompt broader anti-spoofing deployment.

C. Overview

In this paper, we propose mutual egress filtering (MEF),an egress filtering based anti-spoofing method. As its nameimplies, MEF requires the filtering to be mutual. AnAS i filters the outbound spoofed traffic attacking ASj if and only if j also filters for i . i and j are called a pair ofMEF peers. Instead of filtering all the spoofed traffic identifiedby egress filtering, a MEF deployer only filters for its peers.Using selective filtering, MEF enlarges the difference betweenthe protection gained by deployers and non-deployers, and thusprovides ASes with high deployment incentives.

MEF can also work in on-demand filtering mode. In thismode, MEF precisely protects the subnetworks or prefixesunder attack, instead of filtering for all peers’ prefixes all thetime. Once a deployer detects a spoofing attack, it requestsits peers to set up filters for the victim prefixes. On-demandfiltering mode has two advantages. First, it reduces the rulesinstalled in routers. Second, it thoroughly prevents non-deployers from gaining free protection, and thus maximizesdeployment incentives (as we will explain in Section III-Dand III-E).

Up to this point we can conceptually analyze the coreidea of MEF: it trades a selected part of effectiveness fordeployment incentives. Specifically, the effectiveness (i.e., thefiltered spoofed traffic) for non-deployers is minimized, whilethe effectiveness for a deployer remains the same as egressfiltering if it peers with all the other deployers. We claim thatthe trade-off is rational for two reasons. First, MEF does notreduce deployers’ protection; it only prevents non-deployersfrom free riding. Second, full effectiveness of egress filteringcan only be realized when it is universally deployed [5],and improving deployment incentives is the only means toachieve universal deployment on the distributedly administeredInternet [9]. We will also show in Section VI-A that theeffectiveness of MEF grows monotonically with deploymentratio, and becomes equivalent to egress filtering when all ASesbecome MEF peers.

As with egress filtering, MEF is also implemented usingACLs, so it does not incur extra investment on router upgrade.Since the spoofed traffic filtered by MEF is a subset of egressfiltering, the false positives will not be higher than egressfiltering.

Although the core concept of MEF is simple, there aretwo challenges. First, while egress filtering is independentlydeployed by ASes, MEF requires inter-AS collaboration.A deployer needs to discover other deployers, peer with themand inform them of the victim prefixes in the on-demandfiltering mode. We design a lightweight control system toimplement these functions.

The system overview is shown in Fig. 2. There are threemain components: a registry for the whole Internet, a network


Fig. 2. System overview. The registry maintains the peer list of all MEFdeployers. Each deployer installs a MEF management module (M3) on itsnetwork management system (NMS). M3 gets the peer list from the registry,generates the ACL, and installs the ACL on ASBRs.

Fig. 3. The ACL rule segments of egress filtering and MEF. Syntax: actionsrc-prefix dst-prefix. (a) Egress filtering. (b) MEF.

management system (NMS) with a MEF management module(M3) for each deployer, and some ASBRs for each AS. Theregistry is the venue where ASes register as deployers andbecome peers. It can be hosted by authoritative organiza-tions, such as Internet assigned number authority (IANA)and regional Internet registries (RIRs). NMS and ASBRs arethe existing entities on the current Internet. M3 provides aninterface for configuration, an interface for communicatingwith the registry, and an interface for installing ACLs onASBRs. We will present the detailed design and analyze theoverall performance.

Second, MEF’s selective filtering demands more ACL rulesthan egress filtering (even in the on-demand filtering mode), asshown in Fig. 3. In the first rule segment, both egress filteringand MEF permit the packets whose source addresses belong tothe local AS. If a packet does not match any rule in Segment 1,it must be a spoofed packet. In the rest rules, egress filteringdenies all the spoofed packets while MEF merely denies aselected portion of them. Segment 2 of MEF’s ACL denies thespoofed packets whose source addresses belong to peers, soas to protect peers from s-DoS. Segment 3 denies the spoofedpackets whose destination addresses belong to peers or thelocal AS, so as to protect them from d-DoS. Thus, all theidentified spoofed packets attacking peers or the local AS aredropped. All the rest spoofed packets, which may attack non-peers or non-deployers, are permitted by Segment 4.

Due to the scarcity of the routers’ hardware resource forimplementing ACLs, it may not be possible to install all therules in hardware without any change. We must compressthe rules under the resource constraint. On one hand, we donot want to compromise the protection for deployers, i.e.,the spoofed packets attacking deployers must be completely

denied. On the other hand, we want that the free protectiongained by non-deployers is as little as possible. We formulatethis problem in Section III-F and design an optimal andefficient prefix compression algorithm to solve it in Section IV.

D. Contributions

Our key contributions are three-fold:First, we propose MEF toward incentivizing the anti-

spoofing deployment on the Internet. MEF uses egress filteringto identify spoofed packets, but only selectively drops thoseattacking MEF peers. In the on-demand filtering mode, MEFonly protects the peers’ prefixes which are under attack, soas to reduce ACL rule usage and thoroughly prevent non-deployers from free riding. By peer-based selective filteringand on-demand filtering, MEF maximizes deployment incen-tives. We quantitatively evaluate the deployment incentivesof MEF in both theory and simulations. The results showthat MEF is the only anti-spoofing method whose deploymentincentives monotonically increase with deployment ratio forboth d-DoS and s-DoS.

Second, we present a detailed system design to implementthe concept of MEF. A global registry is introduced to maintainthe registration information, peering relationship and policiesof the deployers. We propose a distributed design for the log-ically centralized registry for load balance and fault tolerance.An AS only needs to deploy a MEF management module (M3)to communicate with the registry for collaborating with peersand performing on-demand filtering. The M3 generates ACLrules and installs them on ASBRs. We evaluate the overallperformance of the system. The results show that the registry isscalable, and M3 consumes moderate computation and storageresource, so that an AS may install it as an extension of NMSon existing servers.

Third, as the ACL size may exceed the routers’ hardwarecapacity, we need to compress the prefixes of the rules.The goal is to minimize the free protection gained by non-deployers without compromising deployers’ protection. Weformulate it as an optimization problem and design an optimalalgorithm to solve it. Our algorithm advances the state-of-the-art by generalizing the functionalities and reducing the over-head in both time and space, making it practical in real use.

The rest of the paper is organized as follows. Section IIsummarizes related work. Section III details the system design.Section IV introduces the prefix compression algorithm.Section V evaluates the core concept, the system design andthe prefix compression algorithm. Section VI discusses therelationship between individual interest and global welfare, aswell as the accounting issue of MEF. Section VII concludesthe paper.

II. RELATED WORK

According to the source address validation architecture(SAVA) [10], the scopes of spoofing defenses include threelevels, i.e., inter-AS, intra-AS and access-network levels,which enforce AS-granularity, prefix-granularity and address-granularity source address validity, respectively. There are twotypes of spoofed packets that cannot be filtered by inter-AS


spoofing defenses but can possibly be filtered by intra-AS oraccess-network spoofing defenses, i.e., the packets that spoofthe source addresses of the same AS and the packets that donot cross AS borders. However, inter-AS spoofing defenseshave two unique advantages. First, they are deployed andmaintained on a relatively small number of ASBRs instead ofa vast number of intra-AS and access-network devices, whichlowers deployment and operational cost. Second, despite beingcoarse-grained, they can be very effective in filtering spoofedtraffic and locating the attacker within one or a small numberof ASes [11]–[13]. Thus, we focus this work on the inter-ASlevel.

Besides the anti-spoofing BCPs in the industry, many inter-AS anti-spoofing methods have been proposed in academia.However, most of them require routers to be upgraded toimplement new functionalities, and none of them gets widelydeployed in the real world. Distributed packet filtering (DPF)[12], inter-domain packet filters (IDPF) [14] and sourceaddress validation enforcement (SAVE) [15] require routers torun new algorithms or new protocols to build filtering tables.Path identification (PiIP) [16] and Passport [17] define newpath identifiers, and spoofing prevention method (SPM) [13]and deployable inter-AS anti-spoofing (DIA) [9] define newend-to-end identifiers, which are generated and verified byrouters. Hop-count filtering (HCF) requires routers to monitortraffic to infer the valid hop count for each address cluster.On the contrary, MEF does not require routers to be upgradedor execute additional functions, which lowers deployment costand computation cost.

The problem of promoting the deployment of the existinganti-spoofing functions, especially the anti-spoofing BCPs, haslong been studied. In 2006, the regional Internet registry ofEurope established the anti-spoofing task force, seeking waysto provide operators with incentives in deploying the BCPs[18]. Operators of north American network operators’ group(NANOG) discussed using legislative and economic methodsto incentivize the deployment [19], [20]. Internet engineeringtask force (IETF) source address validation improvement workgroup also has drafts discussing the incentive issues [21].However, none of these organizations come up with efficientand practical solutions.

The work on high-incentive deployment scheme of the anti-spoofing BCPs is most related to MEF. A. Bremler-Barr et al.propose the idea of ingress/egress club (IEC), where ASes ina club only filter for club members [13]. Both MEF and IECuse selective filtering to increase deployment incentives. Themain differences are: 1) MEF discards ingress filtering andonly employs egress filtering, so that the operational cost maybe reduced; 2) MEF has an on-demand filtering mode, whichnot only reduces resource consumption, but also prevents freeriding to further increase deployment incentives; 3) We presentthe comprehensive system design and the prefix compressionalgorithm to make MEF practical, while IEC merely staysat the idea level. Filtering as a service (FaaS) makes IEFa tradable service [22]. In FaaS, deployers of IEF can earnmoney by filtering spoofed traffic for other ASes. MEF differsfrom FaaS in two aspects: 1) ASes who benefit from MEFmust also filter for others, which incentivizes more ASes to

deploy MEF; 2) MEF is more practical since it does not requirenew economic schemes.

III. SYSTEM DESIGN

This section presents the system design of MEF. We firstdescribe the functionalities and detailed design of the systemcomponents. We then introduce how the system works as awhole by following the main procedures, including registra-tion, policy update, spoofing filtering in the normal mode andthe on-demand mode, ACL construction, and ACL installation.

A. System Components

This subsection introduces the design of the registryand M3. We omit ASBRs since they are unchanged existingrouters on the Internet.

1) Registry: Before introducing the functionalities of theregistry, let us first imagine what the system would look likewithout the registry: A deployer has to collaborate with itspeers in a 1-to-N manner. For authenticity and confidentiality,it needs to enforce cryptography on its communications withall the peers. As the number of peers increases (up to tensof thousands), the security maintenance complexity and com-putation cost will be significant, which may deter ASes fromdeploying MEF.

The registry is designed as an information center to sim-plify M3 and offload its overhead. With the registry, M3 onlyneeds to send requests to the registry, who then forwardsthe requests to other deployers if necessary. All the requestsare authenticated by the registry. M3 can trust the receivedinformation as long as it verifies the information is sent bythe registry. This design makes M3 lightweight and lowersthe deployment barrier.

The registry maintains three types of information for eachdeployer:

• Registration information: the deployer’s AS number andthe domain name (or IP address) of its M3.

• Peering policy: a list of ASes that it does not want topeer with (e.g., due to conflict of interest).

• Protection policy: the subset of the deployer’s addressspace that it wants to protect (it may want to reservethe rest addresses for other use, e.g., background trafficmonitoring).

To update the information, the deployer’s M3 submits arequest to the registry. The registry authenticates the requestand updates the database. Upon receipt of a peering policyor protection policy update, the registry may also inform therequester’ peers to update the prefixes they should protect.Besides, in the on-demand filtering mode, upon receipt of anon-demand filtering request, the registry authenticates it andinforms the requester’s peers to protect the prefixes specifiedin it.

The registry relies on the steadily deployed resource pub-lic key infrastructure (RPKI) [23], by which one can attestthe holdership of AS numbers and IP addresses, to set upthe initial trust to a deployer (detailed in Section III-B).Once the initial trust is established, the registry and


the M3 can negotiate new credentials to secure sub-sequent communications. RPKI can also be used toverify the holdership of IP addresses. The registrycan build a local cache of the end-entity certificates,which validate route origination authorizations, to mapIP addresses to AS numbers. Upon receipt of protection policyupdate or on-demand filtering requests, the registry can usethe mapping to validate whether the requester AS owns theclaimed IP addresses.

For load balance and fault tolerance, the registry is com-prised of multiple physically distributed servers, namelyregional registries (RRs), each of which serves the deployersin a region. Only a small number of RRs are needed as wewill evaluate in Section V-C1. For example, we suggest fiveRRs, of which the region partition can conform with that ofthe RIRs [24].

When the M3 of a deployer initiates a communication withthe registry, it queries the IP address for the registry’s domainname. The name server will return a list of IP addresses, eachof which corresponds to an RR. The order of the addresseschanges in a round-robin manner to achieve load balance. TheM3 then communicates with the first address, which does nothave to be the RR in its region. Once failures are detected onone or multiple RRs, their addresses are removed from the listuntil they recover, so that the M3 can always find an activeRR unless all RRs are down. The communication from theregistry to the M3 is initiated by the RR in the M3’s region.Once this RR incurs a failure, other RRs will take over thedeployers in that region until it recovers.

The registry mainly has two types of tasks, processingdeployers’ requests (DRs) and sending protected prefix updates(PPUs). DRs often write the crucial information on theregistry, such as the registration information, policies, andprotected prefixes for each deployer, so we fully replicatethem and keep them strongly consistent on all RRs. Denotedby drk

i the kth DR from deployer i , drki must be received

before drk′v on all RRs ∀k < k ′. Note that the data about i

can only by written by i , but i can send a DR to any RR dueto the DNS based load balance. Since it is a typical causalordering constraint in update ordering [25], we can use VectorTimestamp protocol [26] to implement it. Since the registra-tion and policy information is relatively stable and the on-demand filtering requests are not frequent (see Section V-B1),the performance of the protocol will not be a bottleneck.

Since a single drki may cause the updates of the protected

prefixes for all i ’s peers, PPU jobs are much heavier. Forfast response to attacks, we use lightweight adaptive taskcheckpointing for fault tolerance [27]. If an RR incurs afailure, another RR can run the last checkpoint for the PPUjobs. Although due to checkpointing intervals some PPUsmay be sent multiple times, it does not matter since the M3

can just ignore the duplicated ones. Since PPUs are generatedfrom consistent DRs, we can guarantee eventual consistencyfor PPUs.

2) M3: The structure of M3 is shown in Fig. 4. M3 providesan interface for operators to configure local information,including the registration information, peering policy, andprotection policy. Once the information is changed, M3 will

Fig. 4. The structure of MEF management module (M3).

submit the update to the registry. The local information alsoincludes the information about local ASBRs’ egress interfacesand hardware constraints, which serves as the input of ACLconstruction and installation. Once the local AS is under aspoofing attack, either operators or an intrusion detection sys-tem (IDS) can initiate an on-demand filtering request, whichis submitted to the registry by M3. M3 also receives peers’protected prefixes from the registry. M3 constructs ACLs forthese prefixes under the ASBRs’ hardware constraints, andinstalls them on ASBRs.

M3 handles most tasks automatically. Only in three casesshould manual configuration be involved, i.e., registration,local information update, and requesting on-demand filter-ing (can be omitted if an IDS triggers on-demand filteringautomatically).

B. Registration

An AS submits its AS number and the corresponding RPKIcertificate to the registry and signs the request.2 By verifyingthe signature using the public key in the certificate, the registrycan verify whether the requester owns AS number. If verified,the AS can submit registration information and negotiate newsecure credentials.

C. Policy Update

When the registry receives a peering policy or protectionpolicy update request, it does not directly forward it to therequester’s peers. Instead, it computes the update of theprotected prefixes for the requester and sends the prefix updateto the requesters’ peers. For example, if i updates its peeringpolicy by avoiding AS j , which is i ’s peer, the registry willtell i and j to remove j ’s and i ’s prefixes from the protectedprefixes, respectively. If i adds a prefix in its protection policy,the registry will asks i ’s peers to add that prefix. Hence,M3 does not need to maintain the peer list or the peers’protection policies. It only needs to maintain all the protectedprefixes as illustrated in Fig. 4.

2If the deployer does not hold the private key, its provider (ISP) can signthe request on its behalf.


D. Filtering in Normal Mode

In the normal mode, a deployer needs to protect all theprefixes in the peers’ protection policies from both d-DoS ands-DoS. Since the policies are relatively stable, the protectedprefixes are relatively stable, too. However, the normal modehas two disadvantages. First, as the number of peers increases,the number of prefixes becomes very large. Second, it doesnot completely prevent non-deployers from free riding. Asillustrated in Fig. 3(b), Segment 2 drops the spoofed packetsdestined for non-deployers whose source addresses belong topeers. This allows non-deployers to gain some free protectionfrom d-DoS. Similarly, Segment 3 allows free protectionagainst s-DoS. These problems are solved by on-demandfiltering.

E. On-demand Filtering

In the on-demand filtering mode, the rules in Segment 2and 3 are set on demand. When a deployer is under a spoofingattack, it submits an on-demand filtering request, specifyingthe type of attack (d-DoS or s-DoS), the victim prefixes, andthe time duration for the filtering. Accordingly, each entry inthe peers’ protected prefixes is associated with an attack typeand duration. When the duration expires, the entry is removed.The victim deployer can extend the duration before it expires.Since the prefixes under spoofing attack should be a smallportion of the total prefixes at any point of time, the numberof rules can be highly reduced. By specifying the attack type,on-demand filtering completely avoids free riding in concept(although free riding may exist in practice due to hardwareresource constraint, as explained below).

F. ACL Construction

As shown in Fig. 3(b), a MEF ACL can be easily generatedgiven the protected prefixes. However, ASBRs may not havesufficient resource to store all the rules. We assume thatASBRs have sufficient resource to store the first ACL segment,which permits local source addresses, since it is the same asthe first ACL segment of egress filtering. We also assume thatthe last segment with a single “permit-any” rule can be stored.Therefore, our focus is on Segment 2 and 3.

Both Segment 2 and 3 deny some protected prefixes in onedimension (source or destination), so we formalize them as asame prefix compression problem.

Let i p denote an address, and p denote a prefix, whichis a set of addresses. We say p1 and p2 are non-overlappedwhen p1 ∩ p2 = φ. Let B L denote the set of non-overlappedprotected prefixes (if two different protected prefixes overlap,we can safely remove the covered one without changingthe address space of B L). We slightly abuse the expressioni p ∈ B L to denote ∃p ∈ B L, s.t. i p ∈ p. Let W Ldenote the set of non-overlapped unprotected prefixes. Theaddress space covered by W L is complementary to B L, i.e.,∀i p, i p ∈ W L ⇔ i p /∈ B L. W L contains peers’ unprotectedprefixes, non-peers’ or non-deployers’ prefixes, and unroutableprefixes. Let L denote the set of non-overlapped prefixesoutput by the prefix compression algorithm. The decisionvariable x p ∈ {1, 0} is 1 if p ∈ L; or 0 otherwise. Let Fmax

Fig. 5. Example of prefix aggregation and compression. (a) Original.(b) Aggregated. (c) Compressed.

denote the maximum number of ACEs that can be assignedto a segment. The hardware constraint can be expressed as∑

p x p ≤ Fmax .Each address i p is assigned with a non-negative weight

wip , which indicates how “bad” it is if this address getsfree protection. In this paper, we use normalized weights,i.e.,

∑ip wip = 1, so wip also expresses the ratio of i p’s

weight to the overall free protection weight. By definition,∀i p ∈ B L, wip = 0. Besides, if i p is a peer’s unprotectedaddress or an unroutable address, wip = 0, too. Otherwise,when i p belongs to non-peers or non-deployers, wip > 0. Theweight of a prefix p is defined as gp =∑

ip∈p wip . Definingthe free riding rate (FRR) as the ratio of the weight of theprefixes in W L that get free protection to the total weight,the FRR caused by L is thus

∑p gpx p, which should be

minimized.Toward reducing the number of prefixes, an intuitive

idea is prefix aggregation. In the simplified example shownin Fig. 5(a), B L = {10.0.0.0/24, 10.0.1.0/24, 10.0.2.0/24},W L = {10.0.3.0/24, 10.0.4.0/24}. When Fmax ≥ 3, we canlet L = B L. If Fmax = 2, we can aggregate the first twoprefixes into a single 10.0.0.0/23 (Fig. 5(b)). The aggregatedprefixes cover the same address space as the original ones.

However, if Fmax = 1, it is impossible to use a sin-gle prefix to cover the same address space as the originalprefixes. We have to do lossy compression. In Fig. 5(c),we let L = {10.0.0.0/22} to cover the entire address spaceof B L, but the prefix 10.0.3.0/24 in W L is also covered.There are two principles for the compression. First, eachprotected address must be covered by L exactly once, i.e.,∀i p ∈ B L,

∑p:ip∈p x p = 1. Second, FRR should be mini-

mized. Thus, the compression problem can be formulated asEquation 1. We will present an optimal algorithm to solve thisproblem in Section IV.

minimize∑

p gpx p

subject to∑

p x p ≤ Fmax∑p:ip∈p x p = 1 ∀i p ∈ B L

(1)

G. ACL Installation

Once a new ACL is constructed, M3 will install it onASBRs and applies it on their egress interfaces. A straight-forward method, which is supported by all types of routers,for installing a new ACL is to remove the old one and applythe new one. However, in many cases, the new ACL onlyhas a small difference from the old one. Taking Fig. 5(b)


as an example, if 10.0.0.1/24 is deleted from the protectionpolicy by a peer, the new L would contain 10.0.0.0/24 and10.0.2.0/24, which only has one prefix different from theold L. In this case, a better way is to incrementally applythe updates on ASBRs. The methods for incremental updatesare device-dependent. For example, Cisco IOS v8.3 or laterallows deleting and adding a rule at a specified position in anACL [28]. Thus, all updates can be done using combinationsof deletions and additions.

IV. PREFIX COMPRESSION ALGORITHM

Equation 1 is equivalent to the BLOCK-ALL problem stud-ied in [29]. A dynamic programming algorithm is proposed in[29] to solve the problem, and proved to be optimal. However,we cannot directly apply the algorithm to our problem for tworeasons. First, in BLOCK-ALL B L only contains IP addresses,while in our problem B L contains IP prefixes with variousprefix lengths. If we mince all prefixes into addresses, the datasize will be too large to be tractable. Thus, we must modifythe original data structures and the tree traversal method tosupport prefixes. Second, we expect that M3 is lightweightso that it can be installed as an extension to NMS andshare the existing computation resource. However, the originalalgorithm incurs heavy overhead in both CPU and memory. Sowe need to optimize the algorithm. In this section, we extendthe original algorithm to support prefixes with various lengths,and improve its time and space complexity to make it practicalin our application scenario.

The total procedure of the algorithm is shown in Algo-rithm I. This algorithm takes B L, W L, w and Fmax as input,and prints out the optimal prefixes in L. For clarity, weintroduce the algorithm with a simplified example, in whichuniversal address space is 10.0.0.0/20, B L = {10.0.0.0/23,10.0.6.0/23, 10.0.9.0/24, 10.0.12.0/23, 10.0.14.0/23}, andW L’s address space is complementary to B L. Four pre-fixes in W L belong to non-peers or non-deployers, i.e,10.0.2.0/24, 10.0.3.0/24, 10.0.4.0/23, and 10.0.8.0/24, whoseintegral weights are 0.2, 0.3, 0.3, and 0.2, respectively. Otherprefixes in W L are peers’ unprotected prefixes or unroutableprefixes, whose integral weights are 0. Fmax = 3.

Algorithm 1 Total Procedure of Prefix Compression1: procedure PREFIXCOMPRESSION(B L, W L, w, Fmax )2: root ← BuildELCPTree(B L, W L)3: g← CalcG(root, w)4: OptimizeELCPTree(root)5: nr ← an empty two-dimensional array6: Compress(root, g, Fmax, nr)7: Output(root, Fmax, nr)8: end procedure

The first step of the procedure is building an extendedlongest common prefix (ELCP) tree based on B L and W L. Inthe ELCP tree, every leaf represents a prefix in B L or W L, anda non-leaf node represents the longest common prefix of theprefixes represented by its two children. Fig. 6(a) presents theELCP tree of the example. A black node represents a prefix in

B L, a white node represents a prefix in W L, and a node witha cross in it is an intermediate node. Note that the white nodeswhose weights are 0 are omitted in the tree. The key differencebetween the ELCP tree and the LCP tree defined in [29] isthat all leaves in the LCP tree represent addresses and appearat the same level in the tree, while in the ELCP tree the leavesrepresent prefixes with various lengths and can appear at anylevels. Besides, we also reduce the space overhead of the treebuilding process. Reference [29] builds the tree by removingnodes from a complete binary tree, while we expand the treefrom a single node by incrementally inserting the prefixes. Thedetailed algorithm is shown in Appendix A.

The second step is calculating the g value for each node inthe tree. For a leaf, its g value equals to its integral weight.For a non-leaf node, its g value is the sum of the g values ofits children [Fig. 6(b)].

The third step optimizes the ELCP tree by removing uselessnodes, so that it reserves only the nodes that are useful forthe Compress algorithm. The black leaves are useful becausetheir prefixes may be put into L. Since g has already beencalculated, all the other nodes can be safely removed exceptthe intermediate nodes which link the black leaves into atree. By minimizing the number of nodes, we can signifi-cantly reduce the overhead of Compress. As shown in Algo-rithm 2, this procedure has four sub-steps (corresponding toFig. 6 (c)∼(f)). In the first three sub-steps, we remove uselessnodes until all leaves are black. Then we (losslessly) aggregatethe black leaves. See Appendix A for algorithm details.

Algorithm 2 Optimize ELCP Tree1: procedure OPTIMIZEELCPTREE(root)2: RemoveWhiteLeaves(root)3: RemoveBranchesWithoutBlackLeaves(root)4: RemoveNodesWithSingleChild(root)5: Aggregate(root)6: end procedure

In the rest steps, we solve the prefix compression problembased on the optimal ELCP tree. We first declare an emptytwo-dimensional array nr , then solve the optimization problemby running the algorithm Compress, which stores intermediateresults in nr , and finally use the Output procedure to print thecompressed prefixes.

Compress is presented in Algorithm 3. Denoted by(node, F) the prefix compression problem “using at most Fprefixes to optimally cover the descendant leaves of node”,the original problem in Equation 1 can be expressed as(root, Fmax). Each node is associated with an array z withthe length of len, where z[F] is the minimum FRR of theoptimal solution to the sub-problem (node, F). Denoted byN the number of descendant leaves of node, we can letlen = min(N, Fmax ), because for all N < F ≤ Fmax , wecan simply select all the leaves, and the resulted z[F] is 0.Each non-leaf node is also associated with the array nr [node],whose length is also len. nr [node][F] is the number ofprefixes used to cover the right subtree in the optimal solution.Apparently the number for the left subtree is F−nr [node][F].


Fig. 6. An example of prefix compression procedure. (a) ELCP tree. (b) g value calculated. (c) White leaves removed. (d) Branches without black leavesremoved. (e) Single-branch nodes removed. (f) Aggregated (optimal ELCP tree). (g) Prefixes in L (nodes in circle).

Algorithm 3 Compress Prefixes1: procedure COMPRESS(node, g, Fmax , nr )2: if node.le f t = null and node.right = null then3: return {0}4: end if5: zl ← Compress(node.le f t, g, Fmax , nr)6: zr ← Compress(node.right, g, Fmax, nr)7: len← Min(Len(zl) + Len(zr ), Fmax )8: z[1] ← g[node]9: for F ← 2 to len do

10: n′ ← arg minMax(1,F−Len(zl ))≤n≤Max(F−1,Len(zr ))

(zl[F−n]+zr [n])

11: z[F] ← zl [F − n′] + zr [n′]12: nr [node][F] ← n′13: end for14: return z15: end procedure

If F = 1, we have to use a single prefix (i.e., the prefixassociated with node) to cover the entire subtree, and thusz[1] = g[node]. For each sub-problem (node, F), where 2 ≤F ≤ len, we try to assign n prefixes to the right subtree, andF − n to the left subtree. The FRR is thus zl [F − n] + zr [n],where zl and zr are the optimal FRRs of node’s left and rightchild, respectively. We find n′ which achieves the minimumFRR. Hence z[F] = zl[F−n′]+zr [n′], and nr [node][F] = n′by definition. We recursively solve the problems from root tothe leaves. At a leaf, we only need to solve the sub-problem(lea f, 1) since a leaf has no child. Thus, len = 1, and z[1] = 0since g[lea f ] = 0.

At last, based on nr , we print out the final prefixes in L.As shown in Algorithm 4, we traverse the ELCP tree in thedepth-first way. If the assigned F of node is 1, we directlyprint out node’s prefix; otherwise, we divide F to the twochildren according to nr , and visit them recursively. The initialcall is Output(root, Fmax, nr).

This algorithm extends the solution to BLOCK-ALL, whosecorrectness is proved in [29]. There are mainly three perfor-mance improvements. First, the original algorithm solves thetree level-by-level from bottom up, so all the z arrays of thecurrent level must be stored before going to the next level.In our algorithm, the z array of a node is solved only whenit is required by the parent, and freed immediately after itis used, which reduces memory usage. Second, the original

Algorithm 4 Output Compressed Prefixes1: procedure OUTPUT(node, F, nr )2: if F = 1 then3: print(node.pf x)4: else5: Output(node.lef t, F − nr [node][F], nr)6: Output(node.right, nr [node][F], nr)7: end if8: end procedure

algorithm computes and saves the optimal prefixes for everynode in the tree. In our algorithm, we only track the optimaln′ for each (node, F) pair, and generate the prefixes onlyonce for L, which saves both time and space. Third, theoriginal algorithm solves the problem (node, F) for all theF’s where 1 ≤ F ≤ Fmax , while our algorithm only solvesfor the useful F’s, i.e., 1 ≤ F ≤ len, which saves bothtime and space. The detailed overhead analysis is presentedin Section V-B1.

V. EVALUATION

In this section, we evaluate the three contributions of thispaper separately. Section V-A evaluates how MEF’s core con-cept performs toward incentivizing anti-spoofing deployment.Next, Section V-B evaluates the overhead and effectivenessof the prefix compression algorithm. Finally, Section V-Cevaluates the overhead of the entire system.

A. Deployment Incentives

Denoted by D the set of deployers, v /∈ D is a non-deployer.For an anti-spoofing method, deployment incentive is definedas the expected ratio of the additionally reduced spoofed trafficattacking v when v becomes a deployer to the total spoofedtraffic attacking v [17].

Let (a, i, v) denote a spoofing flow sent by the attacker ASa, attacking the victim AS v, and taking AS i as the innocent.In d-DoS, v is the destination AS of the flow and i is thespoofed source AS. In s-DoS, v is the intended source ASand i is the innocent destination AS (reflector).

The integral filter function F(D, (a, i, v)) describes whetherthe deployers in D can filter out a spoofing flow (a, i, v):

F(D, (a, i, v)) ={

1, if D can filter (a, i, v)0, otherwise

(2)


When v becomes a deployer, the integral filter becomesF(D ∪ {v}, (a, i, v)). Define �(D, (a, i, v)) as the “delta”between the two filters regarding the spoofing flow (a, i, v):

�(D, (a, i, v)) = F(D ∪ {v}, (a, i, v)) − F(D, (a, i, v)) (3)

Let δ = �(D, (a, i, v)). δ = 1 indicates that v improves itsprotection by becoming a deployer, since the flow that cannotbe filtered by D can now be filtered by D ∪ {v}. δ = −1indicates that becoming a deployer declines v’s protection.δ = 0 indicates that the two filters are equivalent regardingthis flow, i.e., both can filter the flow or neither can filter it.

Let pAj , pI

j , and pVj denote the independent probabilities

of the AS j being the attacker, innocent, and victim of aspoofing flow, respectively, where ∀ j, 0 ≤ pA

j , pIj , pV

j ≤ 1,and

∑j pA

j =∑

j pIj =

∑j pV

j = 1. Hence, v’s deploymentincentive can be calculated by summing up the weighteddeltas:

inc(D, v) =∑

a,i

pAa pI

i �(D, (a, i, v)). (4)

1) Deployment Incentives in Theory: We formalize andtheoretically analyze the deployment incentive of MEF. Forsimplicity, we assume that all deployers peer with each otherand FRR is 0.

Normal Mode:In the normal mode, deployers always filter the identi-

fied spoofed packets whose source or destination addressesbelong to peers. Under a d-DoS attack against a non-deployer v, the spoofed packets from any deployer whosesource addresses belong to other deployers are dropped. Thus,we have F(D, (a, i, v)) = 1 ⇔ a ∈ D, i ∈ D, i = a,and F(D ∪ {v}, (a, i, v)) = 1 ⇔ a ∈ D, i = a. Hence,�(D, (a, i, v)) = 1⇔ a ∈ D, i /∈ D. So we have

inc(D, v) =∑

a∈D,i /∈D

pAa pI

i = pAD pI

N . (5)

where pAD =

∑a∈D pA

a and pIN =

∑i /∈D pI

i .We can derive the incentive against s-DoS similarly, and

the result is the same as Equation 5. We omit the derivationto save space.

On-demand Filtering Mode:In on-demand filtering mode, spoofed traffic is filtered only

when it attacks a peer. A non-deployer v cannot get anyprotection, i.e., F(D, (a, i, v)) = 0. Thus, �(D, (a, i, v)) =F(D ∪ {v}, (a, i, v)). A deployer can get the same protectionas the normal mode, i.e., F(D ∪ {v}, (a, i, v)) = 1⇔ a ∈ D,i = a. So we have

inc(D, v) =∑

a∈D,i =a

pAa pI

i =∑

a∈D

pAa (1− pI

a) (6)

Apparently, on-demand filtering mode has higher deploy-ment incentives than the normal mode. Besides, the deploy-ment incentives monotonically increase with incrementaldeployment, i.e., ∀D ⊂ D′, inc(D, v) ≤ inc(D′, v).Proof: letting � = D′ − D, inc(D′, v) = inc(D, v) +∑

a∈� pAa (1− pI

a) ≥ inc(D, v). � That is to say, as MEFis incrementally deployed, the incentives for non-deployersmonotonically (weakly) increase.

Fig. 7. Deployment incentive of MEF (two modes and the optimaldeployment strategy).

2) Deployment Incentives in Simulation: Next we quanti-tatively illustrate how MEF’s deployment incentives changewith the deployment process by simulation.

In the simulation, we set D = φ initially. In each round, werandomly choose a non-deployer and put it into D, until allASes are in D. For each D, we calculate the average deploy-ment incentive, which is defined as the weighted averagedeployment incentives of the non-deployers, i.e., inc(D) =∑

v /∈D pVv inc(D, v)/

∑v /∈D pV

v .We assume that every routable IP address has the same

probability to be the attacker, innocent and victim of a spoofedflow, i.e., pA

j = pIj = pV

j = r j , where r j is the ratio of theroutable address space size of AS j to the global routableaddress space size. This assumption is widely applied in thisresearch area [11], [13], [22]. The address space size of eachAS is calculated using the prefix-to-AS mapping data obtainedfrom [30] on Oct 11, 2012.

We run the simulation for 50 times and plot the averagedresults in Fig. 7. The incentive curve of the normal mode(MEF-n) is concave. The peak incentive is 0.25 and approxi-mately appears at 50% deployment ratio. This conforms withthe analytical peak value of Equation 5. The incentive of theon-demand filtering mode (MEF-o) monotonically increaseswith the deployment ratio, which also conforms with thetheoretical analysis.

MEF-o-opt in Fig. 7 is the incentive curve of the on-demandfiltering mode under the optimal deployment strategy, i.e., ineach round of the simulation, we select the non-deployer withthe biggest address space size as the next deployer. Proof:∀a /∈ D, letting D′ = D ∪ {a}, inc(D′, v) = inc(D, v) +pA

a (1− pIa). Since pA

a = pIa = ra , inc(D′, v) = inc(D, v) +

ra(1 − ra). Since on the current Internet, ∀a, ra < 0.5, thebiggest ra maximizes inc(D′, v). � Due to the power-lawdistribution of ASes’ address space sizes on the Internet [13],a small set of deployers can cover a large portion of the globalroutable address space and produce high incentives for otherASes. This can be a hint for MEF’s deployment strategy inpractice.

3) Comparison With Other Methods: Next we compare thedeployment incentive of MEF (on-demand filtering mode)with other anti-spoofing methods. We use the same simulationsetting as Section V-A2, except that we put more than onenon-deployers into D in each round to reduce simulation time,because some methods are very time-consuming in simulation.We also collect the Internet AS-level topology annotated withAS relationship from [31] and use C-BGP [32] to generateinter-AS routing, since some methods (e.g., uRPF) require


Fig. 8. Deployment incentive comparison of anti-spoofing methods. (a) d-DoS. (b) s-DoS.

Fig. 9. Two ACL structures for the on-demand ingress filtering of IEC.

routing information to identify spoofed packets. We run thesimulations for d-DoS and s-DoS separately, since a methodother than MEF typically has different deployment incentivesfor the two types of spoofing attacks.

Since MEF does not require router upgrade, we highlightthe comparison with IEF, IEC, and uRPF, and briefly comparewith the other methods that require router upgrade. FaaS isexcluded from the comparison, because it relies on economicinteractions between deployers and non-deployers, which arehard to simulate in this comparison setting. We also use thesimulation results of SPM to represent Passport and DIA, sincethey have equivalent deployment incentives [9], [11].

Note that since IEC stays at the idea level without a concretedesign, we assume that it has a similar inter-AS collaborationsystem as MEF. We evaluate its on-demand filtering mode tocompare with the on-demand filtering mode of MEF. Thus,the only difference is that IEC enforces both ingress filtering3

and egress filtering while MEF focuses on egress filteringonly. Fig. 9 illustrates the two ACL structures for the on-demand ingress filtering of IEC. Clearly, the first structureis not scalable because it has a two-dimension segment, sowe resort to the second structure. Let nl , n f , and n p denotethe number of local prefixes, non-local (foreign) prefixes, andprotected prefixes, respectively. The number of rules requiredby on-demand ingress filtering and on-demand egress filtering(i.e., MEF) are nl + n p + 1 and n f + n p + 1, respectively.Since typically, n f > nl , the number of required rules of IECis more than twice of MEF. Hence, we are interested in thegained deployment incentives by IEC at such cost.

The simulation results are shown in Fig. 8. The incentivecurves of IEF are close to the x-axis for both d-DoS and s-DoS.

3For a fair comparison, we assume that IEC keeps similar operational costas MEF, i.e., its ingress filtering part merely denies the inbound packets whosesource addresses belong to the local AS, instead of maintaining an ACL foreach stub neighbor AS separately.

These results confirm our analysis in Section I, i.e., an AScan hardly gain additional protection by deploying IEF. Thecurve of IEC is only a little higher than MEF for d-DoS, andtheir curves almost coincide for s-DoS. Hence, MEF realizessimilar deployment incentives as IEC with only half the cost.uRPF has high initial deployment incentive for d-DoS, sinceit is efficient in identifying spoofed packets based on theirincoming directions. However, as the number of deployersincreases, more and more spoofed traffic is filtered out byexisting deployers, and the additional protection that a non-deployer can gain by deploying uRPF becomes less, so thedeployment incentive becomes lower. The incentive of uRPFagainst s-DoS is almost 0. In s-DoS, spoofed traffic is deliveredfrom the attacker to the innocents, which may not pass thevictim. Thus, the victim even has no chance to filter it.

Some of the methods that require router upgrade providehigher deployment incentives than MEF for either d-Dos ors-DoS, but not both. HCF’s deployment incentive for d-DoS ishigh and consistent, because every AS independently protectsitself against d-DoS, and hop-count based filtering is effectiveworking at destination. PiIP and SPM have higher curves thanMEF for d-DoS, because they introduce new identifiers toprovide more anti-spoofing information. The more deployers,the more information an AS can gain by deploying themethods. However, their curves for s-DoS are lower than MEF.In contrast, SAVE has higher incentive than MEF for s-DoS,because only if an AS deploys SAVE can other deployers learnhow to filter for its addresses; but its incentive for d-DoS islow. The deployment incentives of DPF and IDPF are lowerthan MEF for both d-DoS and s-DoS.

B. Performance of Prefix Compression

This subsection evaluates the overhead and effectiveness(FRR) of the prefix compression algorithm.

1) Overhead Analysis: To keep brevity, here we mainlyanalyze the overhead of the Compress algorithm, and leavethe overhead analysis of other steps in Appendix A.

Space complexity:Compress introduces two main data structures, i.e., z and

nr , both with the same length len for a node. z is freedimmediately after it is used, but nr persists until Output. Thus,the main space overhead is on nr . For the nodes on the same


Fig. 10. Two sample trees for complexity analysis. (a) A balanced tree.(b) An unbalanced tree.

level in the optimal ELCP tree, since their prefixes have thesame length, no node is the descendant of another node. Thus,a leaf is the descendant of at most one of them. Since len =min(N, Fmax ) ≤ N , the sum of the len’s of all nodes at thislevel will not exceed the total number of leaves. That is tosay, the space cost of a level will not exceed |B L ′|, whereB L ′ is the set of leaves of the ELCP tree. The total costwill be O(|B L ′|H ), where H is the height of the optimalELCP tree. In practice, the maximal value of H is a constant(32 for IPv4 and 128 for IPv6). Hence, the space complexityis O(|B L ′|), where |B L ′| < |B L|.

Time complexity:The overhead to calculate n′ is F . Hence the overhead

for a node is∑

1≤F≤len F = O(len2). In the balancedtree shown in Fig. 10 (a), for a node at level h, N =2H−h . Denoted by h′ the minimum h, s.t. N ≤ Fmax ,h′ = H − log2 Fmax . For the subtree rooted at level h′ inthe dashed circle, the maximal computation overhead of theroot is F2

max . The overhead of its child on level h′ + 1 is(2−1 Fmax)

2. There are two children, so the overhead on thislevel is 2−1 F2

max . We can calculate the overhead of this subtreeby summing up all levels, and the sum is 2F2

max . There are2h′ = 2H−log2 Fmax = |B L ′|/Fmax such subtrees. So the totaloverhead is 2F2

max |B L ′|/Fmax = O(|B L ′|Fmax). There are2h′ − 1 < |B L ′|/Fmax nodes whose levels are lower than h′.The overhead for such a node is F2

max . So the overhead forall these nodes is also O(|B L ′|Fmax). Putting the two partstogether, the total overhead is O(|B L ′|Fmax).

Balanced trees have the minimal overhead. In the worstcase, the structure of the tree is nearly a linear list(Fig. 10 (b)). The number of nodes with N > Fmax is|B L ′|−Fmax , and their total overhead is O(|B L ′|F2

max), whichequals the overhead of the algorithm in [29]. However, sincethe height of the tree cannot exceed the constant H . With tensof thousands of nodes, the structure of the tree is closer toa balanced tree rather than a linear list. Thus, we believe theoverhead is close to O(|B L ′|Fmax) in practice.

Overhead in Practice:For quick prototyping, we implement the PrefixCompres-

sion algorithm in C# and run it with real Internet data. We areconcerned with the peak memory usage and the computationtime in practice.

Appendix A shows that the overall space complexityis O(|B L| + |W L|). Hence, we vary the combinations ofB L and W L to test the peak memory usage. The peakmemory usage appears in a setting where |B L| ≈ |W L| and

TABLE I

PERFORMANCE MEASUREMENT OF COMPRESS

|B L| + |W L| = 527k, which is larger than the global routingtable size (473k) because we de-overlap ASes’ overlappedprefixes into longer ones using longest prefix match. The peakmemory usage is 75.9MB, which appears after the ELCPprefix tree is built. The memory usage then drops significantlybecause many nodes are removed by the OptimizeELCPTreeprocedure. The final optimal ELCP tree contains only 107kleaves (214k nodes). Additional space is allocated for zand nr in Compress. Even with Fmax = 10000 and 50000,the peak memory usage during Compress is 70.2MB and71.1MB, respectively, which indicates that Fmax only affectsthe constant factor of space overhead.

The time complexity of Compress is O(|B L ′|Fmax), whichdominants the overall time overhead. We run the algorithmwith a single thread on a laptop CPU (Intel i5 M540 @2.53GHz) to test the performance in practice. We are con-cerned with the computation time in two scenarios. The firstone is the normal mode, where all peers’ prefixes shouldbe protected, and routers need to allocate more hardwareresource, so both |B L| and Fmax are big. In the afore-mentioned intense setting where |B L ′| = 107k, we run thealgorithm for 50 times for Fmax = 10000 ∼ 50000, andillustrate the average results in Table I. We can see thatthe time grows linearly with Fmax . The maximal time usedis 5 minutes and 18 seconds. Since prefixes are relativelystable in the normal mode, we can let M3 update the ACLevery few hours or even longer, so 5 minutes will still bepractical.

The second scenario is the on-demand filtering mode.A measurement work shows that about 1085 ∼ 1281 prefixesare under spoofing attacks per week [33]. We randomly selectabout 1281 prefixes in B L and run the algorithm for 50 timesfor Fmax = 200 ∼ 1000. The average results are shown inTable I. In this typical on-demand filtering scenario, Compressfinishes within tens of milliseconds.

2) Free Riding Rate (FRR): Table I presents the FRRs ofdifferent settings. In the typical on-demand filtering setting,FRR becomes lower than 0.1 when Fmax = 600, which is lessthan half of the number of required prefixes (1281). That is tosay, we can compress the protected prefixes into much fewerones without letting more than 10% non-deployers gain freeprotection. FRR = 0.01 when Fmax = 1000.

Table I also shows the FRRs of an intense normalmode setting, e.g., FRR = 0.112 when |B L ′| = 107k andFmax = 10000. However, we are also interested in the resultsfor lower Fmax ’s and other values of |B L ′|. Specially, we wantto evaluate the FRRs of various Fmax ’s through the deploymentprocess of MEF.


Fig. 11. FRR curves through the deployment process.

We conduct the evaluation using the simulations with realInternet data. For each deployment ratio in {0.1, 0.3, 0.5, 0.7,0.9}, we randomly select ASes to be deployers, whose prefixesare put into B L, and the prefixes of other ASes are put intoW L. Next we choose Fmax from {1, 10, 100, 1000, 10000,50000} and run our algorithm. Fig. 11 shows the averageresults of 50 runs. When Fmax = 1, we can only use one prefix0.0.0.0/0 to cover all addresses, so FRR=1. FRR decreaseswith the increment of Fmax . When Fmax = 1000, the FRRs formost deployment ratios are below 0.5. When Fmax = 10000,all FRRs are below 0.12. When Fmax = 50000, all FRRsare close or equal to 0. Interestingly, with the growth of thedeployment ratio, FRR firstly increases and then decreases.This is because in the first stage, |B L ′| increases with thenumber of prefixes of deployers while the in the secondstage, there are so many deployers that their prefixes can beaggregated to reduce |B L ′|.

Apparently, with the same Fmax , the on-demand filteringmode achieves much lower FRR than the normal mode, e.g.,when Fmax = 1000, the FRRs for the two modes are 0.01and 0.5. In other words, achieving the same FRR, the on-demand filtering mode requires much smaller Fmax . Thisverifies our previous statement that the on-demand mode helpsminimize hardware resource consumption and prevent freeriding.

C. System Overhead

This subsection evaluates the overhead of the entire MEFsystem. Specifically, we analyze the overhead on the newelements introduced by MEF, i.e., the registry and M3. Weuse real Internet data (e.g., there are about 45k ASes and 473kprefixes in the routing system [34]) for quantitative evaluation.We assume that all ASes deploy MEF and peer with each otherto evaluate the maximal overhead.

1) Registry: For each deployer, the registry maintains itsregistry information (in kB), peering policy (4B*45k, anAS number is 4B, and there are 45k ASes) and protectionpolicy (5B*4209, a prefix is 5B, and an AS at most has4209 prefixes [34]). The total storage cost for all deploy-ers is around 9GB. The registry also caches the IP-to-ASmapping to verify IP address holdership, which takes uparound (5+4)B*473k = 4.2MB. Thus, the storage overhead ismoderate.

Another overhead on the registry is communication. Weassume five RRs for this evaluation. Since the registry infor-mation and policies are relatively stable, the updates of them

are not frequent, and the communication cost is relativelylow. The dominant communication overhead should be on theon-demand filtering requests. Measurement shows that 12805spoofing attacks happen in a three-week period [33] – if everyattack triggers a request, there are 610 requests per day. Uponreceipt of a request, an RR replicates it to other RRs and sendsthe PPUs to the deployers in its region. On average, an RRneeds to process 9k transactions for a request, or 9k*610 =5.6 million transactions per day. This number is far less thanthe number of DNS requests handled by Google’s name server(70 billion per day) [35], which implements cryptographybased DNSSEC [36]. So we believe that hosting the registryis technically practical.

2) M3: The space cost of M3 is low since it only storesthe local information and the protected prefixes, and theprefix compression algorithm takes at most 75.9MB memory.The computation overhead is low as we have analyzed inSection V-B.1. Another main cost is the communication in theon-demand filtering mode. Communicating with the registryis lightweight since there are only hundreds of requests perday. M3 also installs ACLs on ASBRs using the existingcommunication channels of the NMS. However, the overheadmay become significant if the ACL is updated too frequently.In this case, M3 can accumulate the requests received in aperiod, e.g., 10 minutes, and then calculate and install theaccumulated ACL updates. Operators can set the period lengthaccording to their specific circumstances to trade off betweencost and response time to on-demand filtering requests.

VI. DISCUSSION

A. Deployment Incentives vs. Global Welfare

MEF generates high deployment incentives by selectivefiltering. It only drops the identified spoofing packets whichattack deployers, instead of all the identified spoofing packets.Selective filtering motivates ASes to deploy MEF, but reducesglobal welfare. In other words, egress filtering produces apublic good, which benefits all ASes on the Internet; MEFmakes it a club good by benefiting only the club members(peers) [37]. In reality, efficient provision of public goods oftenrequires the presence of a government. However, Internet is adecentralized system, and there is no such a government. Thatis the root cause why the deployment of IEF is still under-provisioned despite many years of appeal.

Making spoofing filtering a club good reduces global wel-fare, but makes efficient provision without a government possi-ble. Simple stated, higher incentives attract more deployment,and more deployment increases global welfare. Fig. 12 showsthe reduction of global spoofing attacks with the growth ofdeployment ratio, which is generated using the same simu-lation setting as Section V-A.2. Although the global welfaregrows sublinearly under random deployment, a small set ofstrategically selected deployers can create very high globalwelfare.

B. Accounting

MEF system works well when all deployers correctly imple-ment MEF. However, a malicious AS may claim that it has


Fig. 12. Reduction of global spoofing attacks.

deployed MEF but does not really filter for its peers. Thus,we may need an accounting method to uncover the incorrectoperations of MEF.

The accounting method can base on voluntary probings likeSpoofer Project [4]. Volunteers can download a probing tooland a set of parameters (such as probing destinations and thespoofed source addresses) from a website hosted by the reg-istry, and run the tool to test their ASes. The registry collectsthe probing results and verifies whether an AS correctly filtersfor its peers. If an AS operates MEF incorrectly, it is removedfrom the deployer list and prohibited from registering for atime period. If an AS incorrectly operates MEF for manytimes, it is regarded as a malicious AS and prohibited fromregistering again.

VII. CONCLUSION

Due to the lack of deployment incentives, the best cur-rent anti-spoofing practices are insufficiently deployed on theInternet, and spoofing attacks are still prevalent. In this paper,we propose a new anti-spoofing method MEF, which has thefollowing advantages:

• MEF provides ASes with high deployment incentives forboth d-DoS and s-DoS.

• Deployers of MEF can gain the same protection as egressfiltering, while non-deployers cannot gain free protection(on-demand filtering mode).

• MEF has no false positives when correctly operated.• MEF incurs minimal deployment cost. An AS only needs

to install a software extension to NMS.

We present the detailed design of the MEF system and aprefix compression algorithm to fit filtering rules in routers’limited resource. We evaluate the deployment incentives ofMEF in both theory and simulations with real Internet dataand compare it with existing anti-spoofing methods. Theresults show that the on-demand filtering mode of MEF is theonly one which achieves continuously growing deploymentincentives for both d-DoS and s-DoS.4 We also evaluate theperformance and overhead of the prefix compression algorithmand the entire system. The results verify the practicality ofMEF.

4On-demand filtering mode of IEC also achieves this, but this mode is notan “existing” method. It is a “straw man” proposed in this paper.

APPENDIX A

We analyze the overhead of each step in Algorithm 1, andsum them up to get the overall overhead.

A. BuildELCPTree

The procedure BuildELCPTree is shown in Algorithm 5.Note that this algorithm deals with prefix overlaps – althoughwe assume that the prefixes in B L and W L do not haveoverlaps, in practice they do. In Line 11, InsertNode findsthe right place in the tree to insert the node. The procedure isshown in Algorithm 6. In Line 18, De-Overlap breaks downthe overlapped prefixes so that black and white nodes onlyappear at leaves. The algorithm is omitted for lack of space.

When we insert a node in W L or B L, at most one extraintermediate node is inserted. When we de-overlap a node(prefix), at most H new nodes are added, where H is aconstant. The space cost is thus O(|B L| + |W L|). Wheneverwe insert or de-overlap a node, we start from the root. In theworst case, we have to go through each level until the bottom,and the corresponding cost is O(H ). Hence, the time cost isO(|B L| + |W L|), too.

Algorithm 5 Build ELCP Tree1: procedure BUILDELCPTREE(B L, W L)2: root ← Node(0.0.0.0/0)3: root .color ← none4: for p f x in B L ∪W L do5: node← Node(pf x)6: if p f x ∈ B L then7: node.color ← black8: else9: node.color ← white

10: end if11: InsertNode(node, root)12: end for13: if root .le f t = null then14: root ← root .right15: else if root .right = null then16: root ← root .le f t17: end if18: De-Overlap(root)19: return root20: end procedure

B. CalcG

The weight of a leaf node is given as input. For each non-leaf node, g[node] = g[node.le f t]+g[node.right]. We omitthe detailed procedure since it is simple. Since the cost on eachnode is constant, both the time overhead and space overheadare O(|B L| + |W L|).

C. OptimizeELCPTree

OptimizeELCPTree includes four steps. We omit thedetailed procedure of the first three for their simplicity. The


procedure of Aggregate is shown in Algorithm 7. In allthe four steps, we only delete nodes from the tree, so the spaceoverhead is O(1). The overhead on processing each node isO(1). Hence the time overhead is O(|B L| + |W L|).

D. Output

Algorithm 4 traverses every node in the ELCP tree onlyonce, and uses O(1) time to print the prefix. So the timecomplexity is O(|B L ′|), and the space overhead is O(1).

E. Overall Complexity

By summing up the overhead of each step in Algorithm 1,we can get the overall complexity. Overall time complexity:O(|B L| + |W L| + |B L ′|Fmax ). Overall space complexity:O(|B L| + |W L|). Note that |B L ′| ≤ |B L|.

Algorithm 6 Insert Node1: procedure INSERTNODE(node, root)2: if node.pf x = root .pf x then3: root .color ← node.color4: return5: end if6: side← node.pf x[PfxLen(root .pf x)+1] = ‘0’ ? le f t :

right7: child ← root .side8: if child = null then9: node.parent ← root

10: root .side← node11: else if node.pf x is covered by child.pf x then12: InsertNode(node, child)13: else if child.pf x is covered by node.pf x then14: node.parent ← root15: root .side← node16: child.parent ← node17: if child.pf x[PfxLen(node.pf x)+1] = ‘0’ then18: node.le f t ← child19: else20: node.right ← child21: end if22: else23: newnode← Node(LCP(node.pf x, child.pf x))24: newnode.color ← none25: newnode.parent ← root26: root .side← newnode27: node.parent ← newnode28: child.parent ← newnode29: if node.pf x[PfxLen(newnode.pf x)+1] = ‘0’ then30: newnode.le f t ← node31: newnode.right ← child32: else33: newnode.le f t ← child34: newnode.right ← node35: end if36: end if37: end procedure

Algorithm 7 Aggregate Black Prefixes1: procedure AGGREGATE(root)2: if node = null then3: return4: else if node.le f t = null or node.right = null then5: return6: end if7: Aggregate(root .lef t)8: Aggregate(root .right)9: if node.le f t .color = node.right .color = black and

PfxLen(node.lef t .pf x) = PfxLen(node.right .pf x)= PfxLen(node.pf x) + 1 then

10: node.color ← black11: node.le f t ← null12: node.right ← null13: end if14: end procedure

REFERENCES

[1] R. Vaughn and G. Evron. (2006). DNS Amplification Attacks [Online].Available: http://www.isotf.org/news/DNS-Amplification-Attacks.pdf

[2] P. Ferguson and D. Senie. (2000). Network ingress filtering: Defeatingdenial of service attacks which employ IP source address spoofing[Online]. Available: http://tools.ietf.org/html/rfc2827

[3] F. Baker and P. Savola. (2004, Mar.). Ingress filtering for multihomednetworks [Online]. Available: http://tools.ietf.org/html/rfc3704

[4] (2013, Sep. 1). Spoofer Project [Online]. Available:http://spoofer.cmand.org/index.php

[5] R. Beverly, A. Berger, Y. Hyun, and K. Claffy, “Understanding theefficacy of deployed internet source address validation filtering,” in Proc.IMC, 2009, pp. 356–369.

[6] F. Bulk. (2009, Jan.). Are We Really This Helpless? (Re: IsprimeDOS in Progress) http://mailman.nanog.org/pipermail/nanog/2009-January/006996.html

[7] R. Dobbins and C. Morales, Worldwide Infrastructure Security Report,vol. 6. Burlington, MA, USA: Arbor Networks, 2010.

[8] M. Prince. (2013). The DDoS That Almost Broke the Internet[Online]. Available: http://www.heliontech.com/aes.htm

[9] B. Liu, J. Bi, and Y. Zhu, “A deployable approach for inter-As anti-spoofing,” in Proc. 19th IEEE ICNP, Oct. 2011, pp. 19–24.

[10] J. Wu, J. Bi, X. Li, G. Ren, K. Xu, and M. I. Williams. (2008, Jun.).A Source Address Validation Architecture (Sava) Testbed and Deploy-ment Experience [Online]. Available: http://tools.ietf.org/html/rfc5210

[11] J. Mirkovic and E. Kissel, “Comparative evaluation of spoofingdefenses,” IEEE Trans. Depend. Secure Comput., vol. 8, no. 2,pp. 218–232, Mar./Apr. 2011.

[12] K. Park and H. Lee, “On the effectiveness of route-based packet filteringfor distributed DoS attack prevention in power-law internets,” in Proc.Conf. Appl., Technol., Archit., Protocols Comput. Commun., Oct. 2001,pp. 15–26.

[13] A. Bremler-Barr and H. Levy, “Spoofing prevention method,” in Proc.24th Annu. Joint Conf. IEEE Comput. Commun. Soc., vol. 1. Mar. 2005,pp. 536–547.

[14] Z. Duan, X. Yuan, and J. Chandrashekar, “Constructing inter-domainpacket filters to control IP spoofing based on BGP updates,” in Proc.INFOCOM, 2006, pp. 1–12.

[15] J. Li, J. Mirkovic, M. Wang, P. Reiher, and L. Zhang, “SAVE: Sourceaddress validity enforcement protocol,” in Proc. INFOCOM, 2002,pp. 1557–1566.

[16] A. Yaar, A. Perrig, and D. Song, “StackPi: New packet marking andfiltering mechanisms for DDoS and IP spoofing defense,” IEEE J. Sel.Areas Commun., vol. 24, no. 10, pp. 1853–1863, Oct. 2006.

[17] X. Liu, A. Li, X. Yang, and D. Wetherall, “Passport: Secure andadoptable source authentication,” in Proc. 5th USENIX Symp. NSDI,2008, pp. 365–378.


[18] (2013, Aug. 30). RIPE IP Anti-Spoofing Task Force [Online]. Available:http://www.ripe.net/ripe/groups/tf/anti-spoofing

[19] (2012). BCP38 Deployment [Online]. Available: http://mailman.nanog.org/pipermail/nanog/2012-March/047093.html

[20] (2012). BCP38 Deployment [Online]. Available: http://mailman.nanog.org/pipermail/nanog/2012-March/047087.html

[21] J. Bi and B. Liu. (2012). Problem Statement of SAVI Beyond theFirst Hop (V4) [Online]. Available: http://tools.ietf.org/html/draft-bi-savi-problem-04

[22] B. Liu, J. Bi, and X. Yang, “FaaS: Filtering IP spoofing traffic asa service,” ACM SIGCOMM Comput. Commun. Rev., vol. 42, no. 4,pp. 113–114, Oct. 2012.

[23] M. Lepinski and S. Kent. (2012). An infrastructure to support secureinternet routing [Online]. Available: http://tools.ietf.org/html/rfc6480

[24] (2013, Dec. 1). Number Resources [Online]. Available:http://www.iana.org/numbers

[25] W. Zhou, L. Wang, and W. Jia, “An analysis of update ordering indistributed replication systems,” Future Generat. Comput. Syst., vol. 20,no. 4, pp. 565–590, 2004.

[26] C. J. Fidge, “Timestamps in message-passing systems that preserve thepartial ordering,” in Proc. 11th Austral. Comput. Sci. Conf., vol. 10.1988, no. 1, pp. 56–66.

[27] M. Chtepen, F. H. Claeys, B. Dhoedt, F. De Turck, P. Demeester,and P. A. Vanrolleghem, “Adaptive task checkpointing and replication:Toward efficient fault-tolerant grids,” IEEE Trans. Parallel Distrib. Syst.,vol. 20, no. 2, pp. 180–190, Feb. 2009.

[28] (2013, Dec. 1). Configuring IP Access Lists [Online]. Available:http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_note09186a00800a5b9a.shtml

[29] F. Soldo, K. Argyraki, and A. Markopoulou, “Optimal source-basedfiltering of malicious traffic,” IEEE/ACM Trans. Netw., vol. 20, no. 2,pp. 381–395, Apr. 2012.

[30] (2012, Oct. 11). Routeviews Prefix to AS Mappings [Online]. Available:http://data.caida.org/datasets/routing/routeviews-prefix2as/

[31] (2012, Oct. 11). Internet Topology Collection [Online]. Available:http://irl.cs.ucla.edu/topology

[32] B. Quoitin. (2012, Oct. 12). C-BGP [Online]. Available: http://c-bgp.sourceforge.net

[33] D. Moore, C. Shannon, D. J. Brown, G. M. Voelker, and S. Savage,“Inferring internet denial-of-service activity,” ACM Trans. Comput. Syst.,vol. 24, no. 2, pp. 115–139, 2006.

[34] (2013, Dec. 4). Cidr Report [Online]. Available: http://www.cidr-report.org/as2.0/

[35] (2013, Aug. 2). Google Public DNS: 70 Billion Requestsa Day and Counting [Online]. Available: http://googleblog.blogspot.com/2012/02/google-public-dns-70-billion-requests.html

[36] M. L. D. M. Roy Arends, R. Austein, and S. Rose. (2005).DNS security introduction and requirements [Online]. Available:http://tools.ietf.org/html/rfc4033

[37] R. Cornes, The Theory of Externalities, Public Goods, and Club Goods.Cambridge, U.K.: Cambridge Univ. Press, 1996.

Bingyang Liu received the B.S. degree in computersoftware from Tsinghua University, Beijing, China.He was a Visiting Student with the Department ofComputer Science, Duke University. He is currentlypursuing the Ph.D. degree with the Department ofComputer Science, Tsinghua University.

Jun Bi (M’99) received the B.S., M.S., and Ph.D.degree in computer science from Tsinghua Uni-versity, Beijing, China. He was a Post-DoctoralScholar with the High Speed Network Department,Bell Laboratories Research, and a Research Scientistwith the Bell Laboratories Research CommunicationScience Division and Bell Laboratories AdvancedCommunication Technologies Center. Currently, heis a Full Professor and the Director of the NetworkArchitecture and IPv6 Research Division, Institutefor Network Sciences and Cyberspace, Tsinghua

University, a Ph.D. Supervisor with the Department of Computer Science,Tsinghua University, and a member of the Tsinghua National Laboratory forInformation Science and Technology.

Athanasios V. Vasilakos (M’00–SM’10) is currentlya Professor with the University of Western Macedo-nia, Greece. He has authored or co-authored over200 technical papers in major international journalsand conferences. He is the author or co-author of fivebooks and 20 book chapters in the areas of commu-nications. He has served as a General Chair, Tech-nical Program Committee Chair, and TPC Member(i.e., INFOCOM, SECON, MOBIHOC) for manyinternational conferences. He served as Editor orGuest Editor for many technical journals, such as

the IEEE TRANSACTIONS ON NETWORK AND SERVICE MANAGEMENT,the IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY,the IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS, PART

B, the IEEE TRANSACTIONS ON INFORMATION TECHNOLOGY IN BIO-MEDICINE, the IEEE TRANSACTIONS ON COMPUTERS, the ACM Trans-actions on Autonomous and Adaptive Systems, the IEEE JOURNAL ON

SELECTED AREAS IN COMMUNICATIONS, the IEEE Communications Mag-azine, ACM/Springer WINET, and ACM/Springer MONET. He is a FoundingEditor-in-Chief of the International Journal of Autonomous and AdaptiveCommunication Systems and the International Journal of Arts and Technology.He is a General Chair of the Council of Computing of the European Alliancesfor Innovation.

Documents

436 IEEE TRANSACTIONS ON INFORMATION FORENSICS AND …netarchlab.tsinghua.edu.cn/~junbi/TIFS-2014.pdf · 2014-08-21 · 436 IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY,