Poseidon: Mitigating Interest FloodingDDoS Attacks in Named Data Networking

Alberto Compagno∗, Mauro Conti∗,#, Paolo Gasti†,#, Gene Tsudik‡∗University of Padua, Padua, Italy

†New York Institute of Technology, New York, NY, USA‡University of California, Irvine, CA, USA

Abstract—Content-Centric Networking (CCN) is anemerging networking paradigm being considered as apossible replacement for the current IP-based host-centricInternet infrastructure. In CCN, named content becomesa first-class entity. CCN focuses on content distribution,which dominates current Internet traffic and is arguablynot well served by IP. Named-Data Networking (NDN)is an example of CCN. NDN is also an active researchproject under the NSF Future Internet Architectures (FIA)program. FIA emphasizes security and privacy from theoutset and by design. To be a viable Internet architecture,NDN must be resilient against current and emergingthreats.

This paper focuses on distributed denial-of-service(DDoS) attacks; in particular we address interest flooding,an attack that exploits key architectural features of NDN.We show that an adversary with limited resources canimplement such attack, having a significant impact onnetwork performance. We then introduce Poseidon: aframework for detecting and mitigating interest floodingattacks. Finally, we report on results of extensive simula-tions assessing proposed countermeasure.

I. INTRODUCTION

The Internet is an amazing success story, connectinghundreds of millions of users. The way people access andutilize it has changed radically since the 1970-s whenits architecture was conceived. Today, the Internet hasto accommodate new services, new usage models andnew access technologies. Users are increasingly mobile,constantly accessing – and contributing to – remoteinformation using a variety of devices such as laptopsand smartphones. Ever-increasing mobility, device het-erogeneity, as well as massive amounts of user-generatedcontent and social networking are exposing the limits ofthe current Internet architecture.

To this end, there are some recent research efforts [23],[33], [22], [24], [6] with the long-term goal of designing

#Work done in part while at University of California, Irvine.

and deploying a next-generation Internet architecture.One such new architecture is Named Data Networking(NDN). It is based on the principle of Content-CentricNetworking, where content – rather than hosts – occu-pies the central role in the communication architecture.NDN is one of the five NSF-sponsored Future InternetArchitectures (FIA) [11]; like the rest, it is an on-going research effort. NDN is primarily oriented towardsefficient large-scale content distribution. Rather thanestablishing direct IP connections with a host servingcontent, NDN consumers directly request (i.e., expressinterest in) pieces of content by name; the network isin charge of finding the closest copy of the content, andof retrieving it as efficiently as possible. This decouplingof content and location allows NDN to efficiently imple-ment multicast, content replication and fault tolerance.

One of the key goals of the NDN project is “securityby design”. In contrast to today’s Internet, where securityproblems were (and are still being) identified along theway, the NSF FIA program (for all of its projects)stresses both awareness of issues and support for featuresand counter-measures from the outset. To this end, thispaper investigates distributed denial of service (DDoS)attacks in NDN.

DDoS attacks are considered to pose serious threats tothe current Internet. They are generally performed usinga large number of compromised hosts (zombies) thatinject specially crafted IP packets in order to overwhelmtheir victims. The effectiveness of DDoS attacks isusually proportional to the number of zombies. NDNis not immune to them and might actually offer avenuesfor new DDoS attacks.

In NDN, each content consumer’s request (called an“interest”) causes NDN routers to store a small amountof transient state. This state is flushed as the content isrouted back to the consumer. This has been pointed outin previous work as a plausible attack vector – under the

arX

iv:1

303.

4823

v1 [

cs.N

I] 2

0 M

ar 2

013

2

name of interest flooding attack [12]. However, there hasbeen, thus far, no evidence whether interest flooding iseven possible. In particular, to the best of our knowledge,there is no experimental work that estimates the amountof resources (i.e., bandwidth, number of compromisedhosts available to the adversary, etc.) required to suc-cessfully carry out interest flooding attack.

Roadmap and Contributions. Motivated by the im-portance of addressing security in the early stages ofa potential new Internet architecture, we focus on DDoSover NDN, specifically, using interest flooding attack. Webelieve that interest flooding attack and countermeasuresdeserve an in-depth investigation before NDN can beconsidered ready for large-scale deployment.

While some preliminary results of this research ap-peared in [7], in this paper we show, via extensivesimulations, that interest flooding attacks are not justtheoretical. It is, in fact, relatively easy to performinterest flooding with rather limited resources. In par-ticular, we simulate interest flooding over two realistictopologies [14]: the German research network DFN andthe AT&T network.

We then briefly discuss both proactive and reactivecountermeasures. Next, we focus on reactive counter-measures and propose techniques for early detection ofinterest flooding. (This was left as an open problemin [12].) We then describe the design and implementationof Poseidon – a framework for local and distributedinterest flooding attack mitigation. Finally, we report onthe effectiveness of proposed methods.

Organization. We proceed with an overview of NDNin Section II and discuss interest flooding and proposedcountermeasures in Section III. Section IV details oursimulation environment and Section V evaluates theimpact of interest flooding attack in our setup. Section VIpresents the Poseidon framework which is evaluated inSection VII. Finally, Section VIII overviews related workand Section IX concludes the paper.

II. NDN OVERVIEW

NDN supports two types of messages: interests andcontent [3]. A content message includes a (human-readable) name, a payload and a digital signature com-puted by the content producer.1 Names are composedof one or more components, which have a hierarchicalstructure. In NDN notation, “/” separates name compo-nents, e.g., /ndn/com/cnn/politics/frontpage.

1Content packets also carry additional fields that are not relevantto this paper and are therefore ignored.

Content is delivered to consumers only upon explicitrequest. Each request corresponds to an interest message.Unlike content, interests are not signed. An interestmessage includes a name of requested content.2 In caseof multiple content under a given name, optional controlinformation can be carried within the interest to restrictdesired content. Content signatures provide data originauthentication. However, trust and key management isthe responsibility of each application.

NDN routers forward interests towards the contentproducer responsible for the requested name, using nameprefixes (instead of today’s IP prefixes) for routing. For-warding Information Base (FIB) is a lookup table used todetermine interfaces for forwarding incoming interests,and contains [name prefix, interface] entries. Multipleentries with the same name prefix are allowed, sup-porting multiple paths under which a given name prefixnamespace is reachable. Each NDN router maintains aPending Interest Table (PIT) – a lookup table containingoutstanding [interest,arrival-interfaces] entries.

When an NDN router receives an interest, it first looksup its PIT to determine whether another interest forthe same name is currently outstanding. There are threepossible outcomes:

1) If the same name is already in the router’s PIT andthe arrival interface of the present interest is alreadyin the set of arrival-interfaces of the correspondingPIT entry, the interest is discarded.

2) If a PIT entry for the same name exists, yet thearrival interface is new, the router updates the PITentry by adding a new interface to the set. Theinterest is not forwarded further.

3) Otherwise, the router creates a new PIT entry andforwards the present interest using its FIB.

Upon receipt of the interest, the producer injects contentinto the network, thus satisfying the interest. The re-quested content is then forwarded towards the consumer,traversing – in reverse – the path of the correspondinginterest. Each router on the path flushes state (deletesthe PIT entry) corresponding to the satisfied interest. Inaddition, each router may cache a copy of forwardedcontent in its local Content Store (CS). Large piecesof content are split into fragments with predictablenames: e.g., fragment 5 of Alice’s photo could be named/flickr/alice/photo-1.jpg/5.

The above description of interest forwarding only ap-plies to content that has not been recently requested, i.e.,

2Or, a prefix of such a name – e.g. /cnn/politics is a prefixof /cnn/politics/frontpage

3

not present in the CS of intervening routers. Whereas, arouter that receives an interest for already-cached contentdoes not forward the interest further; it simply returnscached content and retains no state about the interest.

Not all interests result in content being returned. If aninterest encounters either a router that cannot forward itfurther, or a content producer that has no such content,no error packets are generated. PIT entries for unsatisfiedinterests in intervening routers are removed after a prede-fined expiration time. The consumer (who also maintainsits local PIT) can choose whether to regenerate the sameinterest after a timeout.

III. INTEREST FLOODING ATTACK AND

COUNTERMEASURES

It is easy to see that an adversary can take advantageof CS and PIT – two features unique to NDN routers– to mount DoS/DDoS attacks specific to NDN. Wefocus on attacks that exploit the PIT, in particular, rapidgeneration of large numbers of interests that saturate thevictim router’s PIT. Once the PIT is completely full,all subsequent incoming (un-collapsible) interests aredropped. Flooding an NDN router with interests saturatesits PIT if the rate of incoming interests is higher than therate at which entries are removed from the PIT, eitherdue to returning content or expiration. This is the goalof interest flooding attacks.

There are several analogies between well-known SYNflooding [31] and interest flooding. In a SYN floodingattack, the adversary’s goal is to consume resources onthe victim host by initiating a large number of TCPconnections. This requires the victim to keep state foreach connection for a relatively long time. The maindifference between SYN flooding and interest floodingattacks is the victim: the primary victims of interestflooding are routers. End-hosts are secondary victims.

As observed in [12], there are at least three waysto mount this attack. The adversary can issue closely-spaced interests for: (1) existing static content; (2)dynamically-generated content; or (3) non-existent con-tent. In the rest of this paper, we refer to interests fornon existing content as fake interests.

In strategy (1), the adversary requests distinct contentto avoid interest collapsing. If the flooding rate is suffi-ciently high, the producer (or, possibly, a router past thevictim) will start dropping packets. This causes intereststo linger in the victim’s PIT until they expire, eventuallyfilling up the victim’s PIT. However, depending on thevictim’s ability to satisfy interests quickly (and flushthem from the PIT), this strategy may be very expensive.

Also, router caches might lower the impact of this attack,satisfying adversary’s requests before they reach thevictim.

Strategy (2) is similar to (1), except that content isnever returned from caches. Also, (2) may impose moreload on the producer, due to the increased number ofrequests for content that can not be precomputed. Thiscould cause higher round-trip latency and higher rate ofdropped packets, which forces adversary’s interests toremain in the victim’s PIT longer.

Strategy (3) allows the adversary to create entriesin the victim’s PIT for which no content will ever bereturned. This has several consequences:

• Adversarial interests referring to non-existenc con-tent are stored in the victim’s PIT until they expire.

• The maximum rate of adversarial interests does notdepend on the bandwidth allocated by the victimto content packets, or on the adversary’s ability toreceive content.

• Adversarial interests cannot be satisfied by routercaches, since they request non-existing content.

• If constructed properly3 adversarial interests arenever collapsed.

These effects allow the adversary to efficiently fill upthe victim router’s PIT. which makes this attack moredangerous than (1) or (2). Therefore, in the rest ofthis paper, we focus on (3) – interest flooding via fakeinterests.

It is straightforward to construct interests that arerouted through the victim. Let R be the router advertisingnamespace /nsf/fia/. If the adversary issues interestsfor /nsf/fia/rnd (where “rnd” is a random string),they are forwarded through R.

We now consider some possible interest floodingcountermeasures and then propose a set of reactivetechniques (called Poseidon) in Section VI.

A. Proactive Countermeasures

Resource Allocation. Let mpu (maximum PIT usage)be the upper bound for the amount of PIT space requiredto route interests. We set mpu = rate · timeout, whererate is the sum of maximum rates of incoming interestson all interfaces, and timeout is the interest timeoutvalue. If PIT size is at least mpu, it cannot be completelyfilled up. However, large and fast PITs are difficultand expensive to implement [32]. Hence, if we assumethat most content is returned before the correspondinginterest expires, PIT size can be smaller than mpu.

3For example, a random component at the end of each name.

4

Alternatively, routers could set rate and timeout suchthat mpu matches PIT size. However, this would alsoreduce the amount of non-malicious traffic that a routercan forward.

Finally, a router could set a low timeout, such thatfake interests are removed more promptly. Unfortunately,this would increase the likelihood of content (corre-sponding to expired PIT entry) being dropped, thusaffecting network performance.

Error Messages. NDN stipulates that whenever an in-terest cannot be satisfied, no error message is returned tothe consumer. The NDN architecture could be amendedto allow producers and routers to issue error messageswhen content cannot be returned. Such messages couldbe routed exactly like content, and flush PIT state of therouters they traverse.

However, error messages have several drawbacks.There is a tradeoff between space and bandwidth usage:for each PIT entry removed by an error message, oneextra packet – i.e., the error message itself – must betransported by the network.

It is unclear whether error messages should be signedby the entity that issues them. If they are, signaturegeneration costs might be high, thus punishing the pro-ducer. If they are not, they can themselves be used toimplement attacks. Also, in case of multipath forwarding(i.e., multiple copies of the same interest concurrentlyforwarded to different interfaces), error messages maybe handled differently with variable results.

In the rest of the paper we focus on reactive counter-measures.

B. Reactive Countermeasures

We now discuss some reactive countermeasures, char-acterized by a detection and a reaction phase. Detectioncan be local or distributed. In the former, routers relyonly on local metrics (e.g., PIT usage, rate of unsatisfiedinterests, amount of bandwidth used to forward content)to identify an attack. In the latter, nearby routers collab-orate to determine whether an attack is in progress andhow to mitigate it.

In case of successful interest flooding attack, thevictim router can easily identify an attack by observingwhether its PIT is full or whether the bandwidth allocatedto forwarding of content is very small. However, it maynot be possible for a router on the path to the victimto detect an attack in progress. Collaborative detectionmechanisms allow routers to exchange information abouttheir state, with the goal of detecting an attack inprogress as soon – and as close to the adversary – as

possible. Once an attack has been identified, routersmust react to mitigate it. Ideally, routers should drop allinterests from the adversary, while forwarding interestsfrom regular users. Alternatively, routers could drop allinterests corresponding to non-existent content. Clearly,routers can implement neither of these countermeasures:a smart adversary may be able to hide malicious traf-fic within legitimate data streams; additionally, routerscannot determine a-priori which interests will returncontent [12]. Feasible reaction strategies include:

1. Identifying a (set of) namespace(s) under attack,and rate limit the corresponding interests. Whilethis may not provide significant relief to the victimrouter, it could reduce the effects of the attack overother close-by routers.

2. Identifying a set of interfaces to which the attackis directed, or from which it is coming, and rate-limit them. If fake interests are spread over manydifferent namespaces but are concentrated over alimited set of interfaces, this approach may turn tobe more effective.

3. In addition to strategies 1. and 2., routers couldidentify PIT entries corresponding to (likely) fakeinterests and remove them before they time out.

With collaborative detection, routers not only exchangeinformation about the existence of an attack, but also the(locally detected) properties of such attack: strategies cantake into account feedback from multiple routers.

In this paper, we consider a particular collaborativeapproach – known as push-back [12] – to counter interestflooding. For each interface over which an attack hasbeen detected, the router informs its neighbors. Theserouters might then react without waiting to detect theattack themselves.

The amount of traffic generated by push-back mes-sages is negligible, in particular with respect to thatof error messages overviewed in Section III-B. In fact,when a router receives a push-back messages it doesnot forward it any further. Moreover, the number ofunsatisfiable interests – and therefore the number ofcorresponding hypothetical error messages – is expectedto be significantly higher than the number of push-backmessages sent under normal conditions.

Before presenting Poseidon (deferred to Section VI),we introduce our evaluation environment for assessingfeasibility of interest flooding attacks and the effective-ness of our countermeasures.

5

IV. EVALUATION ENVIRONMENT

We use simulations to quantify effects of both attacksand countermeasures. In particular, we run CCNx overNS-3 [25] via DCE. CCNx [2] is the official imple-mentation of NDN, originally developed by PARC, andreleased as open-source project in 2009. Even thoughCCNx codebase is still in early stage of development,it provides all basic functionalities of NDN. CCNxcurrently runs as an overlay on top of IP. Direct CodeExecution [8] (DCE) is a framework developed by IN-RIA to allow regular applications to access a networkenvironment simulated using NS-3. DCE allows us totest the latest CCNx, without reimplementing it for NS-3.

We emphasize that running simulations of NDN asan overlay (over IP) reflects the status of the currentCCNx implementation. In particular, even in the officialNDN testbed [23], links between routers are essentiallyGeneric Routing Encapsulation (GRE) tunnels carryingUDP packets.

Experimental Setup. Our experiments are performedover two topologies shown in Figure 1.

Figure 1(a) corresponds to DFN – “DeutschesForschungsNetz” – the German Research Network [9],[10], while Figure 1(b) corresponds to the AT&T net-work.

We use the symbols Rx, Cx, Px, and Ax to repre-sent the x-th router, consumer, producer, and adversary-controlled node, respectively. Continuous lines in Figure1 indicate connections between routers, dashed linesdenote connections between consumers and routers, anddotted lines represent connections between producersand routers. In both topologies, we had 16 (honest)consumers and 2 producers.

We first analyze the two topologies without any ad-versarial traffic. This provides us with a a baseline.

Each consumer issues interests for content producedby P0 and P1. Interests retrieve distinct pieces of non-existent content; therefore, routers cannot collapse themor satisfy them via cached content. Consumers send ashort burst of 30 interests, spaced by 2 ms, at timet = 1000 ms of the simulation. Starting from t =1200 ms, consumers switch to a rate of one interest every10.7 ms. In our configurations, such interest spacingallows routers to forward interests roughly at the samerate at which they receive content packets. We setrouters’ PIT size to 120 KB, while the interest expirationtime was set to the default timeout of 4000 ms.

We report the average of the various runs in Figure 2.

In particular, figures 2(a) and 2(b) show the total numberof contents (y-axis) received by the different routers(x-axis), for the DFN and AT&T, respectively. Figures2(c) and 2(d) show PIT usage (y-axis) as a functionof simulation time (x-axis) for the two topologies. Themaximum value on the y-axis for figures 2(c) and 2(d)corresponds to the total space available in the PITs(120 KB). Also, the two vertical lines (at 1000 ms and26000 ms) indicate the instant when consumers start andstop sending interests. (The same notation is used in allgraphs that refer to PIT usage reported in this paper.)

V. ATTACK EFFECTIVENESS

We assume that the adversary is able to corrupt aportion of the consumers, through which it implementsthe attack – i.e., issues fake interests. However theadversary is not allowed to control routers. We believethat this restriction is realistic and well represents thecurrent scenario of DDoS attacks (e.g., [16]). While wedo not exclude that attacks might come from internalrouters, we leave the investigation of this as future work.

In our simulations we observe that successful instanti-ation of interest flooding requires very small amount ofbandwidth. The adversary controls the nodes connectedthrough a red solid line in Figure 1. The three adversarialnodes (A0, A1, A2) send interests for non-existentcontent for the namespace registered by P0 – i.e., allfake interests are routed to P0. Similar to honest nodes,the adversary starts sending interests at t = 1000 ms.Fake interests are generated every 1.337 ms. Behavior ofhonest consumers is unchanged from the base scenario.

Attack results are plotted in Figure 3 for some repre-sentative nodes in both topologies. In particular, Figure3(a) and Figure 3(b) show the ratio of content packetsforwarded during the attack with respect to the samenetwork with no malicious traffic. Figures 3(c) and 3(d)show PIT usage.

Figure 3(a) demonstrates that the attack has significantimpact on the network. Several routers forward 20%of the original traffic. Similar behavior is evident fromFigure 3(b).

It is important to note that in both DFN and AT&Ttopologies, consumers are spread all over the networkand the number of adversaries is quite small (threefor both topologies). However, attack impact is signif-icant: fraction of packets forwarded by routers variesbetween 25% and 75% with respect to the base-linescenario. Differences in the effectiveness of the attackfor different routers can be explained by their distancefrom the adversary-producer paths. We emphasize that

6

C1

C0

C2

C3

C4

C5

C6

C7

C8

C9

C10

C11

C12

C13

C14

C15

R0 R1

R2

R3

R4

R5

R6 R7

R8

R9

R10

R11

R12

R13

R15

R14

R17

R16

R18

R19

R28

R20

R21

R22

R23

R24

R25

R26

R27

R29

P0

P1A0

A1

A2

(a) DFN topology

C0

C1

C2

C3

C4

C5

C6

C7

C8C9

C10

C11

C12C13

C14

C15

R0 R1

R2

R3R4

R5

R6

R7

R8

R9

R10R11

R12

R13

R14R15

R16

R17

R18

R19R20

R21

R22

R23

R24

R25

R26

R27

R28

R29R30

R31

R32

R33

R34

R35

R36

R37

R38R39

R40

R41

R42

R43R44 R45

R46

R47

R48

R49

R50R51

R52

R53

R54

R55

R56R57R58

R59

R60R61R62

R63R64

R65

R66

R67R68

R69

R70 R71

R72

R73 R74

R75

R76R77

R78

R79

R80

R81R82

R83

R84

R85R86

R87R88

R89

R90

R91

R92

R93R94

R95

R96R97

R98R99

R100

R101

R102

R103

R104 R105

R106

R107R108

R109R110R111R112R113R114R115

R116

R117

R118

R119R120

R121 R122

R123R124

R125R126

R127R128R129R130R131

P0

P1

A0

A1

A2

(b) AT&T topology

Fig. 1. Considered architectures: topologies

0

5000

10000

15000

20000

25000

30000

35000

40000

R0

R1

R2

R3

R4

R5

R6

R7

R8

R9

R1

0

R1

1

R1

2

R1

3

R1

4

R1

5

R1

6

R1

7

R1

8

R2

0

R2

1

R2

2

R2

3

R2

4

R2

5

R2

6

R2

7

R2

8

R2

9

# o

f co

nte

nts

re

ce

ive

d

Routers

(a) DFN: throughput (abs. values)

0

5000

10000

15000

20000

25000

30000

35000

40000

R0

R1

R2

R3

R4

R5

R6

R7

R8

R9

R1

0R

12

R1

3R

14

R1

5R

16

R1

7R

18

R1

9R

20

R2

1R

22

R2

3R

24

R2

5R

26

R2

7R

29

R3

0R

31

R3

2R

33

R3

4R

35

# o

f co

nte

nts

re

ce

ive

d

Routers

(b) AT&T: throughput (abs. values)

0

20000

40000

60000

80000

100000

120000

0 5000 10000 15000 200000 25000 30000

Siz

e (

byte

s)

Time (milliseconds)

R2R9

R13R18R27R24R21R23

(c) DFN: PIT usage

0

20000

40000

60000

80000

100000

120000

0 5000 10000 15000 20000 25000 30000

Siz

e (

byte

s)

Time (milliseconds)

R2R3R6

R23R31R37

(d) AT&T: PIT usage

Fig. 2. Baseline behavior (no attack)

reduced bandwidth available to consumers can only beattributed to high PIT usage, as shown in Figure 3(c)and Figure 3(d). It is easy to see that the fraction oftraffic forwarded by routers drops significantly once PITsfill up. As confirmed by Figure 3(a), R9 is the first toreach its PIT limit, quickly followed by R2. This canbe attributed to the central role R9 and R2 occupy inthe DFN topology. Similar observations can be made

for AT&T: R3 (closest to P0) is the first to succumb, asshown in Figure 3(d).

VI. OUR COUNTERMEASURE: POSEIDON

We now introduce Poseidon, a framework for mitigat-ing Interest flooding. Poseidon is a set of algorithms thatrun on routers. Its goal is to identify traffic anomalies(especially, interest flooding) and mitigate their effects.Poseidon continuously monitors per-interface rates of

7

0 %

20 %

40 %

60 %

80 %

100 %

R0

R1

R2

R3

R4

R5

R6

R7

R8

R9

R1

0

R1

1

R1

2

R1

3

R1

4

R1

5

R1

6

R1

7

R1

8

R2

0

R2

1

R2

2

R2

3

R2

4

R2

5

R2

6

R2

7

R2

8

R2

9

% o

f co

nte

nts

re

ce

ive

d

Routers

(a) DFN: Throughput (%)

0 %

20 %

40 %

60 %

80 %

100 %

R0

R1

R2

R3

R4

R5

R6

R7

R8

R9

R1

0R

12

R1

3R

14

R1

5R

16

R1

7R

18

R1

9R

20

R2

1R

22

R2

3R

24

R2

5R

26

R2

7R

29

R3

0R

31

R3

2R

33

R3

4R

35

% o

f co

nte

nts

re

ce

ive

d

Routers

(b) AT&T: Throughput (%)

0

20000

40000

60000

80000

100000

120000

0 5000 10000 15000 200000 25000 30000

Siz

e (

byte

s)

Time (milliseconds)

R2R9

R13R18R27R24R21R23

(c) DFN: PIT usage

0

20000

40000

60000

80000

100000

120000

0 5000 10000 15000 20000 25000 30000

Siz

e (

byte

s)

Time (milliseconds)

R2R3R6

R23R31R37

(d) AT&T: PIT usage

Fig. 3. Interest Flooding Attack (IFA): impact over baseline

unsatisfied interests with respect to overall traffic. Ifthese rates change significantly between two consecutivetime intervals, it sets a filter on the offending interface(s)(which reduces the number of incoming interests). Addi-tionally, Poseidon can issue a push-back “alert” messageto the same interfaces, to signal that an interest floodingattack is in progress. Upon receiving an alert message,it alters local detection thresholds.

Poseidon keeps several statistics on expired interests.In particular, for each of them it records namespaceand incoming/outgoing interfaces information. Relativelycommon network phenomenon (e.g., packet loss) andregular applications behavior usually account for only a(relatively) small amount of expiring interests in routers’PITs. In order to limit the number of false positive andminimize the reaction time, Poseidon monitors multiplemetrics concurrently.

In the next sections we introduce the detection andreaction phases of Poseidon. Notation used is shown inTable I.

A. Detection Phase

Attacks are detected using two parameters: ω(rji , tk),and ρ(rji , tk). The former represents the number of

R set of all routers in the network running Poseidonri i-th router, 1 ≤ i ≤ |R|rji j-th interface on router ritk k-th time interval

ω(rji , tk) rate between incoming interest and outgoing contentfor a given interface rji

ρ(rji , tk) PIT space used by interests arrived on interface rji ,measured at the end of interval tk

Ω(rji ) interest flooding detection threshold for ω(rji , tk)

P(rji ) interest flooding detection threshold for ρ(rji , tk)

TABLE INOTATION.

incoming interests divided by the number of outgoingcontent packets, observed by a router ri on its interfacerji within time interval tk:

ω(rji , tk) =(# of interests from rji at interval tk)

(# of content packets to rji at interval tk).

ρ(rji , tk) indicates the amount of space (in bytes) usedto store interests in PIT, coming from interface rji withintime interval tk.

Poseidon detects an attack when both ω(rji , tk) andρ(rji , tk) exceed their respective thresholds Ω(rji ) andP(rji ). The detection algorithm is executed at fixed time

8

intervals – typically every 60 ms – and in the presence ofparticular events, (i.e., push-back messages, as detailedbelow).

The parameter ω(rji , tk) is a good representation ofthe ability of routers to satisfy incoming interests ina particular time interval. (This is also confirmed byour experiments, detailed in Section VII.) In particular,ω(rji , tk) > 1 indicates that the number of contentpackets forwarded to rji is smaller than the number ofinterests coming from the same interface. However, asmall bursts of (either regular or non-satisfiable) interestsmay not be caused by an attack. Hence, taking intoaccount only ω(rji , tk) (i.e., not considering ρ(rji , tk))may cause the detection algorithm to report a significantnumber of false positives. Applying countermeasuresmay, in this case, produce negative effects to the overallnetwork performance.

We argue that neither increasing Ω(rji ), nor computingω(rji , tk) over longer intervals, produces the indentedeffects. In fact, in the first case the bound must be sethigh enough to avoid classification of short burst ofinterests as attacks; however this could inevitably leadto late- or mis-detection of actual attacks. Increasingthe size of the interval over which Ω(rji ) is computedmay reduce the sensitivity of Poseidon to short burstof interests. An interval length similar or longer thanthe average round-trip time of interest/content packet,in fact, may allow (part of) the content requested by theburst to be forwarded back, reducing ω(rji , tk) to a valuecloser to 1. However this could significantly increase thedetection time.

Instead, to improve detection accuracy (distinguish-ing naturally occurring burst of interests from attacks),Poseidon takes into account also ρ(rji , tk). This valuemeasures the PIT space used by interests coming froma particular interface. This allows Poseidon to maintainthe number of false positives low – when compared toconsidering solely ω(rji , tk) – while allowing it to detectlow-rate interest flooding. In a low-rate interest floodingattack the adversary limits the rate of fake intereststo keep ω(rji , tk) below its thresholds. Monitoring thecontent of the PIT allows Poseidon to observe the effectsof the attack, rather than just its causes, allowing forearly detection.

To sum up, different parameters monitored by Po-seidon act as weights and counterweights for interestflooding detection. When a router is unable to satisfyincoming interests over a relatively short period, ρ(rji , tk)

may exceed the detection threshold but ω(rji , tk) willnot; when the router receives a short bursts of interests,

ω(rji , tk) may become larger than Ω(rji ) but the PITusage will likely be within normal values. To stay unde-tected, an adversary willing to perform interest floodingmust therefore: (1) reduce the rate at which it sendsinterests, which limits the effects of the attack; and/or(2) restrict the attack to short burst, which makes theattack ineffective.

Thresholds Ω(rji ) and P(rji ) are not constant and maychange over time to accommodate different conditionsof the network. As an example, push-back messagesdescribed below provide input for determining moreappropriate values for these thresholds.

B. Reaction Phase

Once an interest flooding attack from interface rji ofrouter ri has been identified, Poseidon limits the rate ofincoming interests from that interface. The original rateis restored once all detection parameters fall again belowtheir corresponding thresholds.

When collaborative (distributed) countermeasures arein place, once a router detects adversarial traffic froma set of interfaces it limits their rate and issues analert message on each of them. An alert message is anunsolicited content packet which belongs to a reservednamespace (“/pushback/alerts/” in our implemen-tation), used to convey information about interest flood-ing attack in progress.

There are two reasons for using content packets ratherthan interests for carrying push-back information: (1)during an attack, the PIT of the next hop connectedto the offending interface may be full, and thereforethe alert message may be discarded; and (2) contentpackets are signed, while interests are not – this allowsrouters receiving alert messages to determine whetherthe information they carry is legitimate.

Routers running Poseidon do not process alert mes-sages as regular content: alerts are not checked againstPIT content and are not forwarded any further. Thepayload of an alert packet contains: the timestamp corre-sponding to the alert generation time; the new (reduced)rate at which offending interests will be accepted onthe incoming interface; and detailed information aboutthe attack – such as the namespace(s) used in maliciousinterests.

Router ri receiving a packet msg processes it asdetailed in Algorithm 1. A persistent interest floodingattack on router ri causes it to send multiple alert mes-sages towards the source(s) of the attack. Such sourceswill decrease their thresholds Ω(rji ) and P(rji ) untilthey detect the attack and implement rate-limiting on

9

the malicious interests. If no attack is reported for apredefined amount of time, thresholds are restored totheir original values.

This push-back mechanism allows routers that are notthe target of the attack, but are unwittingly forwardingmalicious interests, to detect interest flooding early. Inparticular, alert messages allow routers to detect interestflooding even when they are far away from the intendedvictim – i.e., close to nodes controlled by the adversary,where countermeasures are most effective.

Algorithm 1: MessageProcessing

input : Incoming packet msg from rji ; wait timeΩ(rji ); P(rji ); Scaling factor s;Alert message m from interface rji

1: if msg is ContentObject then2: process msg as ContentObject3: return4: end if5: if msg is AlertMessage then6: if Verify(msg.signature) and IsFresh(msg) and

time from last Alert received from rji > wait time then7: // Push-back reaction8: Decrease(Ω(rji ), s)9: Decrease(P(rji ), s)

10: else11: drop msg12: return13: end if14: end if15: if msg is Interest then16: if ω(rji , tk) > Ω(rji ) and ρ(rji , tk) > P(rji ) then17: drop msg18: if time from last Alert sent on interface rji > wait time

then19: // Push-back alert message generation20: send Alert to rji21: end if22: else23: process msg as Interest24: end if25: end if

VII. EVALUATION

In this section we report on experimental evaluationof countermeasures presented in Section VI. Our coun-termeasures are tested over the same topologies usedin previous experiments and detailed in Figure 1. Eachrouter implements detection techniques discussed in Sec-tion VI-A and countermeasures from Section VI-B.

As for the parameters used in our experiments, weconsidered these initial values: for each router ri, in-terface rji , Ω(rji ) = 3 and P(rji ) = 1/8 of the PIT size.Furthermore, we set scaling factor s = 2 and wait time(both used in Algorithm 1) to 60 ms.

The Decrease function divides the threshold in inputby s at each invocation. Similarly, the Increase functionincreases its input by 1/8 of the current value. Consumersrequest the same content at the same rate as in theprevious simulations. Similarly, the nodes controlledby the adversary implement interest flooding as in thesimulation in Section V.

Local Countermeasures. Figure 4 shows the result ofapplying local countermeasures. Values shown representthe average of 20 executions. Figure 7(a) and Figure7(b) report the ratio of content packets received withrespect to the scenario with no adversary. (For com-parison purposes, in the same figure we also report thecorresponding value with no countermeasures in place.)

Our results show that the rate-based (local) counter-measure – while simple – is very effective. In particular,the countermeasure is very effective in the DFN topology(Figure 7(a)). Most routers, in fact, forward virtually thesame amount of content they otherwise forward withoutattack – up from about 60% with no countermeasures.Moreover, with Poseidon no router forwarded less than80% of the original traffic in our experiments. Unfortu-nately, For the AT&T network, while the countermeasurecan still mitigate the effect of the attack (see Figure 7(b)),unfortunately its benefit is not as good as observed forthe DFN network.

Figures 4(a) and 4(b) report PIT usage over the sameexperiments. Figure 4(a) presents our results for the DFNarchitecture. For clarity, we do not report measurementsfor nodes R4, R29, R22, R25, R20, R14 – almostidentical to those of R18. Results for routers R3, R5, R6,R7, R8, R11, R12, R15, R17, R19, R26, and R28 arealso not reported being very similar to those of R13, R21,and R23. Similarly, some routers of the AT&T networkare not represented in Figure 4(b).

Our results also show that this countermeasure signifi-cantly reduces the PIT usage in presence of an adversary.The effects of the rate-based approach are evident att = 6000 ms, when fake interests corresponding to theinitial phase of the attack – those that triggered thedetection – expire. This shows that the detection timefor the attack is around one second.

Distributed Countermeasures. Figures 7(a) and 7(b)show the ratio of content packets received under at-tack with the the push-back countermeasure in place.To simplify comparison, we report the results of thesimulations of the attack without countermeasures andwith the previous (local) countermeasure.

Both architecture exhibits an interesting behavior: the

10

0

20000

40000

60000

80000

100000

120000

0 5000 10000 15000 200000 25000 30000

Siz

e (

byte

s)

Time (milliseconds)

R2R9

R13R18R27R24R21R23

(a) DFN: PIT usage

0

20000

40000

60000

80000

100000

120000

0 5000 10000 15000 20000 25000 30000

Siz

e (

byte

s)

Time (milliseconds)

R2R3R6

R23R31R37

(b) AT&T: PIT usage

Fig. 4. Rate-based (local) countermeasure

0 %

20 %

40 %

60 %

80 %

100 %

R0

R1

R2

R3

R4

R5

R6

R7

R8

R9

R10

R11

R12

R13

R14

R15

R16

R17

R18

R20

R21

R22

R23

R24

R25

R26

R27

R28

R29

% o

f conte

nts

receiv

ed

Routers

no countermeasurerate-based countermeasure

push-back countermeasure

(a) DFN: Throughput (%)

0 %

20 %

40 %

60 %

80 %

100 %

R0

R1

R2

R3

R4

R5

R6

R7

R8

R9

R10

R12

R13

R14

R15

R16

R17

R18

R19

R20

R21

R22

R23

R24

R25

R26

R27

R29

R30

R31

R32

R33

R34

R35

% o

f conte

nts

receiv

ed

Routers

no countermeasurerate-based countermeasure

push-back countermeasure

(b) AT&T: Throughput (%)

Fig. 5. Push-back (distributed) countermeasure

11

0 %

20 %

40 %

60 %

80 %

100 %

R0

R1

R2

R3

R4

R5

R6

R7

R8

R9

R1

0

R1

1

R1

2

R1

3

R1

4

R1

5

R1

6

R1

7

R1

8

R2

0

R2

1

R2

2

R2

3

R2

4

R2

5

R2

6

R2

7

R2

8

R2

9

% o

f co

nte

nts

re

ce

ive

d

Routers

no countermeasurerate-based countermeasure

push-back countermeasure

(a) DFN: Throughput (%)

0 %

20 %

40 %

60 %

80 %

100 %

R0

R1

R2

R3

R4

R5

R6

R7

R8

R9

R1

0R

12

R1

3R

14

R1

5R

16

R1

7R

18

R1

9R

20

R2

1R

22

R2

3R

24

R2

5R

26

R2

7R

29

R3

0R

31

R3

2R

33

R3

4R

35

% o

f co

nte

nts

re

ce

ive

d

Routers

no countermeasurerate-based countermeasure

push-back countermeasure

(b) AT&T: Throughput (%)

Fig. 7. Push-back (distributed) countermeasure

push-back mechanism offers visibly better performancecompared to the rate-based countermeasure. In partic-ular, for the DFN architecture, R28, R20, R29, andR25 forward 16%, 13%, 11%, and 8% more contentpackets than in their counterparts in using the rate-basedcountermeasure. The impact is far more important forthe AT&T network: for several routers the improvementwith respect to the local countermeasure is more than300%.

A similar conclusion applies also to the PIT usage –which is another measure for attach effectiveness. In fact,for the DFN it is possible to observe a significant benefitsof push-back comparing Figure 4(a) to Figure 6(a), inparticular for the PIT of router R27. Similarly, for theAT&T it is possible to observe a significant benefits ofpush-back comparing Figure 4(b) to Figure 6(b), e.g. forthe PIT of router R31.

So far we have considered cumulative results forthroughput; however, it is interesting to analyze alsohow the content packets throughput varies over time indifferent scenarios. Figures 8 and 9 show the effect ofour rate-based countermeasure on some routers, whichwe deem notable in our topologies. This figures clearlyillustrate that using the local (rate-based) countermeasurerouters are able to provide roughly the same throughputmeasured without interest flooding. We obtained analo-gous results (not shown with graphs) for the push-backcountermeasure.

An interesting phenomenon highlighted by Figures8(b) and 9(b) is the cyclical behavior of the amountof bandwidth available to content. This pattern can be

explained as follows. As soon as the PITs of these routersare filled up with fake interests, no legitimate interestsare forwarded and therefore no content is routed back.After four seconds – i.e., in our setting, the lifetime ofan unsatisfied interest – fake interests are removed fromthe PITs allowing routers to forward new (legitimate)requests for content. When this happens, the adversary isquickly able to fill up PITs again. This process continuesindefinitely for the whole duration of the attack.

0

50

100

150

200

250

300

350

400

0 3000 6000 9000 12000 15000 18000 21000 24000 27000 30000

# o

f p

ackets

/ 2

50

ms

Time (milliseconds)

Contents in from R27Contents in from R2

(a) R9: baseline

0

50

100

150

200

250

300

350

400

0 3000 6000 9000 12000 15000 18000 21000 24000 27000 30000

# o

f packets

/ 2

50m

s

Time (milliseconds)

Contents in from R27Contents in from R2

(b) R9: attack

0

50

100

150

200

250

300

350

400

0 3000 6000 9000 12000 15000 18000 21000 24000 27000 30000

# o

f packets

/ 2

50m

s

Time (milliseconds)

Contents in from R27Contents in from R2

(c) R9: rate-based countermeasure

Fig. 8. DFN: content throughput (abs. values)

VIII. RELATED WORK

NDN is an instantiation of the Content-CentricNetworking (CCN) paradigm (an alternative term

12

0

20000

40000

60000

80000

100000

120000

0 5000 10000 15000 200000 25000 30000

Siz

e (

byte

s)

Time (milliseconds)

R2R9

R13R18R27R24R21R23

(a) DFN: PIT usage

0

20000

40000

60000

80000

100000

120000

0 5000 10000 15000 20000 25000 30000

Siz

e (

byte

s)

Time (milliseconds)

R2R3R6

R23R31R37

(b) AT&T: PIT usage

Fig. 6. Push-back (distributed) countermeasure

“Information-Centric Networking” is largely synony-mous). Other related architectures include the Data-Oriented Network Architecture (DONA) [19] andTRIAD.

DONA is based on “flat” self-certifying names, com-puted as the cryptographic hash of the producer’s publickey and a (possibly) human-readable label. New contentis published – i.e., registered – with a tree of trustedresolution handlers to enable retrieval. Resolution han-dlers maintain a forwarding table that provides next-hopinformation for pieces of content in the network. Assuch, DONA does not support dynamically generatedcontent.

Similar to NDN, TRIAD [5] names content usinghuman-readable, location-independent names. It mapsnames to available replicas of data using an integrateddirectory. It then forwards requests until a copy of thedata is found. The data location is returned to the client,who retrieves it using standard HTTP/TCP. TRIAD relieson trusted directories to authenticate content lookups (butnot content itself). For additional security, the authorsof [5] recommend to limit the network to mutuallytrusting content routers.

There is lots of previous work on DoS/DDoS at-tacks on the current Internet infrastructure. Current lit-erature addresses both attacks and countermeasures onthe routing infrastructure [15], packet flooding [18],reflection attacks [26], DNS cache poisoning [27] andSYN flooding attacks [31]. Proposed counter-measuresare based on various strategies and heuristics, including:anomaly detection [1], ingress/egress filtering [30], IPtrace back [21], [29], ISP collaborative defenses [4] anduser-collaborative defenses [13].

The authors of [12] present a spectrum of possible

DoS and DDoS attacks in NDN. They classify thoseattacks in interest flooding and content/cache poisoning,and provide a high-level overview of possible counter-measures. However, the paper does not analyze specificattacks or evaluate countermeasures.

NDN caching performance optimization has beenrecently investigated with respect to various metricsincluding energy impact [17], [28], [20]. To the best ofour knowledge, the work of Xie, et al. [34] is the first toaddress cache robustness in NDN. This work introducesCacheShield, a mechanism that helps routers to preventcaching unpopular content and therefore maximizing theuse of cache for popular one.

IX. CONCLUSION

In this paper we discussed interest flooding-basedDDoS over NDN. We provided, to the best of our knowl-edge, the first experimental evaluation of the attack. Ourexperiments are based on the official NDN implementa-tion codebase; we argue that this setup provides reliableresults, and closely mimics the behavior of physical(non-simulated) networks.

We demonstrated that interest flooding attack is arealistic threat; in particular, we showed that an adver-sary with limited resources can reduce the amount ofbandwidth allocated for content objects to 15-25% ofthe total bandwidth.

We then introduced Poseidon, a new mechanism fordetecting and mitigating interest flooding. We showedthat the benefits of Poseidon are significant: in fact,routers running our countermeasure are able to usealways more than 80% (and often more than 95%) of theavailable bandwidth during the attack. Poseidon relies onboth local metrics and collaborative techniques for early

13

0

50

100

150

200

250

300

350

400

0 3000 6000 9000 12000 15000 18000 21000 24000 27000 30000

# o

f packets

/ 2

50m

s

Time (milliseconds)

Contents in from R3

(a) R4: baseline

0

50

100

150

200

250

300

350

400

0 3000 6000 9000 12000 15000 18000 21000 24000 27000 30000

# o

f p

acke

ts /

25

0m

s

Time (milliseconds)

Contents in from R3

(b) R4: attack

0

50

100

150

200

250

300

350

400

0 3000 6000 9000 12000 15000 18000 21000 24000 27000 30000

# o

f p

acke

ts /

25

0m

s

Time (milliseconds)

Contents in from R3

(c) R4: push-back countermeasure

Fig. 9. AT&T: content throughput (abs. values)

detection of interest flooding. Reaction to the attack iscoordinated between adjacent routers.

Our experiments suggest that in large complex net-works collaborative countermeasure provide better re-sults, while in simple topologies local countermeasuresare to be preferred.

REFERENCES

[1] G. Carl, G. Kesidis, R. R. Brooks, and S. Rai. Denial-of-service attack-detection techniques. IEEE Internet Computing,10(1):82–89, jan 2006.

[2] Content centric networking (CCNx) project. http://www.ccnx.org.

[3] CCNx protocol. http://www.ccnx.org/releases/latest/doc/technical/CCNxProtocol.html. Retrieved Jul. 2012.

[4] Y. Chen, K. Hwang, and W.-S. Ku. Collaborative detectionof ddos attacks over multiple network domains. IEEE Trans.Parallel Distrib. Syst., 18(12):1649–1662, 2007.

[5] D. Cheriton and M. Gritter. Triad: A new next-generationinternet architecture, 2000.

[6] ChoiceNet - Evolution through Choice. https://code.renci.org/gf/project/choicenet/. Retrieved Jul. 2012.

[7] A. Compagno, M. Conti, P. Gasti, and G. Tsudik. POSTER:NDN interest flooding attacks and countermeasures. In ACSAC,2012.

[8] NS3 DCE CCNx. http://www-sop.inria.fr/members/Frederic.Urbani/ns3dceccnx/getting-started.html. Retrieved Jul. 2012.

[9] DFN-Verein: DFN-NOC. http://www.dfn.de/dienstleistungen/dfninternet/noc/. Retrieved Jul. 2012.

[10] Germany - DFN/WiN. http://lit.jinr.ru/LCTA/txt/Reports problnet/icfa/pswg 20.htm. Retrieved Jul. 2012.

[11] National science foundation (NSF) future of internet architec-ture (FIA) program. http://www.nets-fia.net/.

[12] P. Gasti, G. Tsudik, E. Uzun, and L. Zhang. DoS & DDoSin named-data networking. Technical report, University ofCalifornia, Irvine, 2012.

[13] C. Gkantsidis and P. Rodriguez. Cooperative security fornetwork coding file distribution. In INFOCOM 2006, 2006.

[14] O. Heckmann, M. Piringer, J. Schmitt, and R. Steinmetz. Onrealistic network topologies for simulation. In ACM SIGCOMMMoMeTools, pages 28–32. ACM Press, 2003.

[15] J. Ioannidis and S. M. Bellovin. Implementing pushback:Router-based defense against ddos attacks. In NDSS, 2002.

[16] Low Orbit ION Cannon project on SourceForge. http://sourceforge.net/projects/loic/. Retrieved Jul. 2012.

[17] V. Jacobson, D. Smetters, N. Briggs, M. Plass, J. Thornton, andR. Braynard. Voccn: Voice-over content centric networks. InThe 2009 Workshop on Re-architecting the Internet, 2009.

[18] J.-H. Jun, H. Oh, and S.-H. Kim. Ddos flooding attack detectionthrough a step-by-step investigation. Networked EmbeddedSystems for Enterprise Applications, 0:1–5, 2011.

[19] T. Koponen, M. Chawla, B.-G. Chun, A. Ermolinskiy, K. H.Kim, S. Shenker, and I. Stoica. A data-oriented (and beyond)network architecture. In SIGCOMM ’07, pages 181–192, NewYork, NY, USA, 2007. ACM.

[20] U. Lee, I. Rimac, and V. Hilt. Greening the internet withcontent-centric networking. In e-Energy, pages 179–182, 2010.

[21] L. Lu, M. C. Chan, and E.-C. Chang. A general model ofprobabilistic packet marking for ip traceback. In ASIACCS,ASIACCS ’08, pages 179–188. ACM, 2008.

[22] MobilityFirst FIA Overview. http://mobilityfirst.winlab.rutgers.edu. Retrieved Jul. 2012.

[23] Named data networking project (NDN). http://named-data.org.[24] Nebula. http://nebula.cis.upenn.edu. Retrieved Jul. 2012.[25] NS-3. http://www.nsnam.org. Retrieved Jul. 2012.[26] V. Paxson. An analysis of using reflectors for distributed

denial-of-service attacks. SIGCOMM Comput. Commun. Rev.,31(3):38–47, July 2001.

[27] V. Ramasubramanian and E. Sirer. Perils of transitive trust inthe domain name system. In Proc. International MeasurementConference, 2005.

[28] E. J. Rosensweig, J. Kurose, and D. Towsley. Approximatemodels for general cache networks. In INFOCOM’10, pages1100–1108, Piscataway, NJ, USA, 2010. IEEE Press.

[29] R. Stone. Centertrack: an ip overlay network for tracking dosfloods. In USENIX ’00, SSYM’00, pages 15–15, Berkeley, CA,USA, 2000. USENIX Association.

14

[30] U. Tupakula and V. Varadharajan. A practical method tocounteract denial of service attacks. In ACSC ’03, pages 275–284. Australian Computer Society, Inc., 2003.

[31] H. Wang, D. Zhang, and K. G. Shin. Detecting syn floodingattacks. In INFOCOM, pages 1530–1539. IEEE, 2002.

[32] Y. Wei, B. Mathieu, P. Truong, G. Simon, and J. Peltier. Real-

istic Storage of Pending Requests in Content-Centric NetworkRouters. In ICCC 2012, 2012.

[33] XIA - eXpressive Internet Architecture. http://www.cs.cmu.edu/∼xia/. Retrieved Jul. 2012.

[34] M. Xie, I. Widjaja, and H. Wang. Enhancing cache robustnessfor content-centric networks. In INFOCOM, 2012.