A Novel Congestion-Aware Interest Flooding
Attacks Detection Mechanism in
Named Data Networking
Ahmed Benmoussa∗ , Abdou el Karim Tahari∗ , Nasreddine Lagraa∗ , Abderrahmane Lakas†
Farhan Ahmad‡ , Rasheed Hussain§ , Chaker Abdelaziz Kerrache∗¶ , Fatih Kurugollu‡
∗
Department of Computer Science, University of Laghouat, Algeria
College of Information Technology, United Arab Emirates University, Al Ain, UAE
‡ Cyber Security Research Group, College of Engineering and Technology, University of Derby, Derby, UK
§ Institute of Security and Cyber-Physical Systems, Innopolis University, Innopolis, Russia
¶ Department of Maths and Computer Science, University of Ghardaia, Ghardaia, Algeria
Emails: ∗ {ah.benmoussa, k.tahari, n.lagraa, ch.kerrache}@lagh-univ.dz † alakas@uaeu.ac.ae
‡ {f.ahmad, f.kurugollu}@derby.ac.uk § r.hussain@innopolis.ru
†
Abstract—Named Data Networking (NDN) is a promising
candidate for future internet architecture. It is one of the
implementations of the Information-Centric Networking (ICN)
architectures where the focus is on the data rather than the
owner of the data. While the data security is assured by definition,
these networks are susceptible of various Denial of Service (DoS)
attacks, mainly Interest Flooding Attacks (IFA). IFAs overwhelm
an NDN router with a huge amount of interests (Data requests).
Various solutions have been proposed in the literature to mitigate
IFAs; however; these solutions do not make a difference between
intentional and unintentional misbehavior due to the network
congestion. In this paper, we propose a novel congestion-aware
IFA detection and mitigation solution. We performed extensive
simulations and the results clearly depict the efficiency of our
proposal in detecting truly occurring IFA attacks.
Keywords—Named Data Networking, Interest Flooding Attack,
Denial of Service, Network congestion.
I. I NTRODUCTION
According to Ciscos Visual Networking Index, the Internet
traffic will reach 254 Exabytes per month by 2020. With the
constantly growing number of connected objects (nearly 20
billion in 2018) and the sheer amount of data exchanged, a
new and more suitable Internet architecture is needed. The
need for new Internet architecture is because of the change
in the perspective of Internet usage. The Internet users are
more interested in the content rather than in the sources of
these contents. Furthermore, the content should reach the
consumers as soon as possible [1]. Besides that, security
was an afterthought when the actual Internet architecture was
developed. Mobility and multicast were also adapted years
after the Internet was created and they are still not fully
adapted with the actual Internet [2], [3].
With these new challenges come new solutions. One of
the proposed future Internet architecture projects is Internet
Centric Networking (ICN). Several architectures were proposed under the ICN project. Named Data Networking is
the promising instantiation of the ICN. NDN changes the
network paradigm from host-centric to data-centric [4]. NDN
incorporates intrinsic security to Internet by providing security
to the contents rather than to the communication path. However, it is still not immune against attacks like DoS/DDoS.
One of the DoS/DDoS attacks that targets an NDN node is
Interest Flooding Attack (IFA). The goal of the attacker is to
overwhelm the NDN node with Interests in order to make it
unavailable.
Several solutions were proposed to mitigate the IFA. Some
solutions are local and others collaborative, distributed, and/or
centralized [5]–[11]. These solutions use network traffic statistics to detect IFAs; however, the type of statistics they use,
might be different. The existing solutions do not take network
congestion into account. In fact, no existing solution take the
network congestion as a parameter for detecting IFA which can
lead to false alarms. Besides the conventional parameters, in
this work, we consider network congestion as an additional
parameter for detecting the IFA. Hence, our proposal can
detect whether there is an intentional IFA or unintentional
phenomenon caused by the congested network.
The rest of this paper is organized as follows: In section
II, we briefly describe the NDN architecture, the forwarding
process and finish this section by talking about IFA. In section
III, we present our solution to detect and mitigate an IFA.
Afterwards, in Section IV, we evaluate our proposed solution.
Finally, in section V, we conclude the paper.
II. NAMED DATA N ETWORKING : A B IRD ’ S V IEW
Named Data Networking (NDN) is a candidate architecture
for Future Internet Architecture (FIA) to replace traditional
TCP/IP Internet architecture [4], [12]. NDN is an extension
of an earlier project in the domain of FIA named ContentCentric Networking (CCN). NDN architecture relies on
the data-centric paradigm where data is the pinnacle of
the communication architecture rather than the hosts. NDN
uses data names instead of IP addresses for communication,
978-1-7281-1856-7/19/$31.00 ©2019 IEEE
Authorized licensed use limited to: BEIJING INSTITUTE OF TECHNOLOGY. Downloaded on December 08,2020 at 03:30:32 UTC from IEEE Xplore. Restrictions apply.
which are hierarchically structured and meaningful, e.g.,
this paper may have the name: "org/icccn/28/ndn/A
Novel-Congestion-Aware-Interest-FloodingAttacks-Detection-Mechanism-in-Named-DataNetworking"
NDNRouter
InterestPacket
ContentStore
(CS)
PendingInterest
Table(PIT)
AddIncoming
interface
ReturnData
Forwarding
InformationBase
(FIB)
Forward
Interest
Dropor
NACK
A. NDN Architecture
NDN uses two types of packets for communication among
nodes, i.e., (1) Interest packets and (2) Data packets. Interest
packets are used by end users to request specific data, normally
known as ”consumers” in NDN. These interest packets propagates through the NDN network in search of the data requested
by the consumers. Any node, having this data responds back to
the consumer with a data packet. These data producing nodes
are known as ”producers” in NDN.
To fetch specific data, NDN node sends an interest with
the name of the desired data. The network then tries to find
this data from the closest possible location. Further, every data
packet in NDN is digitally signed to keep the data intact.
In order to disseminate interest and data packets in the
network, every NDN node is equipped with following three
data structures, i.e.,
• Pending Interest Table (PIT): PIT corresponds to the
repository where the actual, not yet satisfied interest
packets are stored. These interests will be held until they
are satisfied or timed out. Every PIT entry contains the
name of the requested data and the interfaces from where
these interests came from.
• Forwarding Information Base (FIB): FIB represents the
second data structure of NDN core, which acts in a
similar fashion as IP routing table. However, in NDN,
FIB stores the namespaces instead of IP addresses.
• Content Store (CS): CS within the NDN node acts as a
cache node and is used mainly for caching purposes. CS
integrates various cashing policies such as least recently
used (LRU), first in first out (FIFO), to name a few. Every
node in NDN can store the data that passes through it
depending on the node’s caching policy.
B. NDN Forwarding
When an interest arrives at a router, it first checks the
existence of the requested data in the CS. If a copy of the
requested data is already stored, the router will then sends
back this data packet downstream. If the CS does not have the
requested data, the router checks if there is a pending entry
of this interest in the PIT table (i.e., the router received a
request for this data before). If the PIT table already contains
an entry for this data, it will add to this entry the interface
from where this interest came from. If there is no entry in the
PIT table (e.g., there is no pending request for this data), the
router will add a new entry to the PIT table with the name
of this requested data. Then, the router uses the FIB table to
route the interest packet to the next node (router or producer).
When an interest is satisfied, a data packet is sent back.
When a router receives a data packet, it will first check if
this data was requested before by checking the respective entry
ReturnData
CacheData
PendingInterest
Table(PIT)
ContentStore
(CS)
DataPacket
(Signed)
DropData
Fig. 1. Request/Response operations in NDN
in the PIT table. If there is no entry in the PIT table, the router
will discard this data packet. If there is an entry in the PIT
table, the router will choose to store (or not) this data packet
(depends on the caching strategy) before forwarding this data
downstream. The process of sending/receiving packets in NDN
is described in figure 1.
C. Interest Flooding Attack
Interest Flooding Attack (IFA) is a type of attack that targets
NDN nodes directly as depicted in figure 2. It consists of
overwhelming an NDN router with a huge amount of interests
in order to charge the PIT table, so there will be no place
for the incoming legitimate interests. The initiator of an IFA
(could be one or many, local or distributed) sends a large
number of interests to target one or multiple routers within the
network. The attacker can perform IFA in three major ways:
1) Sending a large number of interests requesting existing
data. This scenario is not durable because of the routers’
capacity to store the data. Therefore, when the data is
requested, it will be quickly satisfied and the attack will
no longer take effect, unless the attacker wants to target
the router with a cache pollution attack which is not in
the scope of this paper.
2) By requesting dynamic data. In this scenario, the attacker
floods the victim with interests requesting dynamic data
(which are created dynamically after a request). It is
more harmful than the first scenario because the data is
created dynamically, so every interest should go to the
real producer of this data. Due to this reason, caching
data in the intermediate routers will not help in this
scenario.
3) Requesting non-existing data. This is the most dangerous
and the most used type of requests for performing an
IFA. In this scenario, the initiator sends a large number
of interests with invalid names. The goal of the attacker
is to make the interests packets stay in the PIT until they
time out because these requests will never be satisfied.
The third scenario is the hardest to mitigate among them.
Authorized licensed use limited to: BEIJING INSTITUTE OF TECHNOLOGY. Downloaded on December 08,2020 at 03:30:32 UTC from IEEE Xplore. Restrictions apply.
Discarded Interest
NDN Router
315
Ignored
User
Upth = 310
eth1
Number of Interest packets
310
Full PIT
Router A
Producers
CS
eth2
Attacker
NDN Network
Legitimate Interests
Forged Interests
305
10% ; α = 0,00001
Avg = 300
300
295
290
285
50% ; α = 0,1
Lowth = 150
1
8
15
22
29
36
43
50
57
64
71
78
85
92
99
106
113
120
127
134
141
148
155
162
169
176
183
190
197
204
211
218
225
232
239
246
253
260
267
274
281
288
295
280
Seconds
Fig. 2. Exemple of Interest Flooding Attack
III. P ROPOSED IFA D ETECTION M ECHANISMS IN NDN
Fig. 3. Average rate calculation example
A. Satisfaction Ratio
The first parameter used in our solution is the satisfaction
ratio. It represents the number of received data packets by the
number of issued interest.
Satisf action Ratioi =
# of Data P ackets Receivedi
# of Interest P ackets Issuedi
(1)
Every router monitors its interfaces and calculates the satisfaction ratios, periodically, associated with these interfaces.
This parameter will then be used by routers to detect malicious
interfaces. When the satisfaction ratio of an interface is low,
the router will consider this traffic as suspicious.
The satisfaction ratio could lead to false detection of malicious interface (e.g., when the network is congested or the data
producer is not reachable). Therefore, we induced network
congestion and interest rate parameter within our proposed
solution to get reliable detection results.
B. Incoming Interest Rate
This parameter represents the amount of interest packets
arriving at the specific interface of NDN router in a given
amount of time. This parameter is used by the routers to detect
abnormal rates, where, every router monitors the incoming rate
of each interface. When the rate exceeds the average threshold
level, the routers will consider it as suspicious and starts
investigations about the interest packets. The router calculates
the average rate of each interface independently, which is
obtained as follow:
N ewAvgi = (1 − α)OldAvgi + α × inrit
(2)
In equation 2, N ewAvgi is the newly calculated average of
interface (i), OldAvgi represents the actual average associated
with interface (i), while inrit is the incoming rate to interface
(i) of the router at time (t). Furthermore, the used skew factor
(α) is calculated as:
0.1,
if inr ∈ [Lowth , Avgi ]
α=
0.00001, if inr ∈ [Avgi , U pth ]
where, Avgi represents the average rate of interface (i).
U pth is the upper bound, which is given as avg + 10%Avg
while Lowth represents the lower bound threshold with value
of avg − 50%Avg.
In equation 2, we chose these values of α after a series of
tests. The main motivation of these tests was to identify and
chose a value that doesn’t influence on the average when an
IFA is happening.
We also decided to take in consideration only the 10%
(above average) part. So if an attack is happening, it will not
make the average value increases. For the lower bound α,
we decided to take only the 50% below average. We decided
to exclude the other part so it will not make the average rate
decreases very quickly (e.g., when interface is not active). The
figure 3 shows an example of rate average and upper/lower
thresholds.
C. Network Congestion
The third and last parameter in our proposed solution is
network congestion. The network congestion could lead to
false results upon detection of an IFA. When a router adds an
interest to the PIT table, it assigns with this interest a lifetime
(default 4 seconds). This newly added interest will stay in the
PIT table as long as it is not yet satisfied (data packet returned)
or timed-out (no data packet returned). When the network is
congested, interest and data packets take a long time to reach
destination. This delay makes the pending interests in the PIT
table to timeout, i.e., the pending interests times out before
they are satisfied. In this paper we chose a simple way to detect
a network congestion. The detection process is done locally
by every router. In our solution, we chose two parameters to
detect a network congestion:
• Number of timed-out interests: when a network congestion occurs, the number of timed out interest packets
increases. This is due to the delay as the pending interests
take longer time to be satisfied.
• Number of NACK packets: NACK packets are used to
carry the response to an interest packet which is not
satisfied. When the network is congested, the number
of NACK packets arriving in a period of time decreases
because of the delay.
We compare these two parameters to get the state of the
network (congested or not). If the numbers are not identical
or nearly identical, this means that the network is congested
i.e., the interest packets are timed out and no NACK packet
Authorized licensed use limited to: BEIJING INSTITUTE OF TECHNOLOGY. Downloaded on December 08,2020 at 03:30:32 UTC from IEEE Xplore. Restrictions apply.
returned. Another parameter that could be used to detect a
network congestion in NDN is the PIT table occupation. When
a network is congested, interest packets take longer time in
order to be satisfied, thus, staying longer in PIT tables of NDN
routers.
D. Proposed Algorithm
The routers monitor the incoming rate of their interfaces.
The average is calculated periodically by calling the Average
procedure. When an incoming traffic rate of interface (i) exceeds average rate of of this interface, the router will consider
it as suspicious and starts to investigate. The router will first
check the satisfaction ratio of this interface (by calling the
Procedure SatisfactionRatio). If the satisfaction ratio
is low, the router will check the network state. The router will
invoke the Procedure IsCongested to test if the network
is congested or not. When all parameters are satisfied, i.e.,
incoming rate is below average, the satisfaction ratio is low
and the network is not congested, The router will consider this
interface as malicious and block it. The algorithms 1, 2, 3 and
4 show these procedures in details.
Algorithm 1 Rate average calulation
1: procedure AVERAGE(int OldAvg, int inr)
2:
Avg ← OldAvg
3:
if ((Avg − (50%Avg)) ≤ inr ≤ Avg) then
4:
Avg ← 0.9 × Avg + 0.1 × inr
5:
else if (Avg ≤ inr ≤ (Avg + 10%Avg)) then
6:
Avg ← 0.99999 × Avg + 0.00001 × inr
7:
end if
8:
return Avg
9: end procedure
Algorithm 2 Satisfaction ratio calculation
1: procedure S ATISFACTION R ATIO(interface i, time t)
2:
float ratio ← 0
3:
Integer int nbr ← Number of Interest packets sent by
interface (i) in periode t
Integer data nbr ← Number of Data packets received by
interface (i) in periode t
5:
ratio ← data nbr/int nbr
6:
return ratio
7: end procedure
4:
Algorithm 3 Testing Network Congestion
1: procedure I S C ONGESTED
2:
bool congested ← f alse
3:
Integer timeoint nbr ← Number of Timed-out interests sent
4:
5:
6:
7:
8:
9:
by all interfaces
Integer nack nbr ← Number of NACK received by all
interfaces
if (timeoint nbr >> nack nbr) then
# of timed-out
interest is much bigger than # of Nack
congested ← true
end if
return congested
end procedure
Algorithm 4 Detecting an Attacker
1: procedure I S ATTACKER(interface i, int inr)
2:
bool attacker ← f alse
3:
int Avg ← GetAvg(interf ace i) Returns average rate of
interface (i)
int ratio ← Satisf actionRatio(interf ace i)
bool congested ← IsCongested
if (inr > Avg) AND (ratio is low) AND (congested =
false) then
7:
Block the interface (i)
8:
end if
9: end procedure
4:
5:
6:
IV. P ERFORMANCE EVALUATION
In this section, we provide details of the simulation settings
and the simulation results of our proposed solution to mitigate
IFA.
A. Simulation Settings
We evaluated our proposal using ndnSIM, which is an open
source simulator to design and model NDN networks [13].
In order to simulate our proposal to detect and mitigate IFA
in NDN, we considered a topology with seven routers, nine
producers and nine consumers. The attacker model used in our
simulation continuously sends huge amount of forged interest
packets with constanct bit-rate, i.e., (10000 interests/s).
Further, the consumers request data as follows: ‘Consumer1’ requests data from ‘Producer9’ using namespace
"/dest9/", ‘Consumer2’ requests data from ‘Producer8’
using namespace "/dest8/" and, so on. Simulation details
are provided in Table I.
In order to evaluate IFA, we start our simulations by
showing the effects of a congested network on the overall
performance. Afterwards, we show that the network congestion leads to false detection of IFA. In addition, we prove that
existing solutions relying on interest satisfaction ratio are not
effective when a network is congested. Finally, we simulate
an attack and show how the network is affected and how our
proposed solution solves the false detection decisions due to
the congested network.
B. Normal scenario
We start by simulating a normal scenario in order to
compare the results with other scenarios. The results show
that for a normal scenario, satisfaction ratio of nearly 100%
is achieved for every consumer. That means that nearly every
interest packet sent by consumers are satisfied (data packet
returned). In the next section, we will provide comparison of
these results with a congested network.
C. Congestion scenario
In this scenario, we simulate a congested network to see the
resultant impact on the NDN network. To simulate a congested
network, we restricted the throughput of the link between
Router1 and Router7 to maximum 1 Mbps and introduced the
delay of 100ms in this particular link. The simulation results
for this scenario are given as:
Authorized licensed use limited to: BEIJING INSTITUTE OF TECHNOLOGY. Downloaded on December 08,2020 at 03:30:32 UTC from IEEE Xplore. Restrictions apply.
TABLE I
S IMULATION SETTINGS
Parameter
Value
Simulation time
Number of nodes
Data Packet size
CS size
Cache replacement strategy
Forwarding Strategy
Average rate
Rate of legitimate users
Rate of attackers
Number of Attackers
300s, 150s
25
1,024Bytes
100
LRU
Best Route
300 interests/s
100 to 500 interests/s
10000 interests/s
01
700
Link
Throughput
Delay
Router Router
Router Producer
Router Consumer
Congested link
100Mbps
10Mbps
10ms
10ms
<1Mbps
100ms
# of interests
600
500
400
300
200
100
1
6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
101
106
111
116
121
126
0
Time (s)
Fig. 5. Number of Dropped packets by Router7 (Core Router)
14%
12%
10%
600
8%
500
6%
400
4%
300
2%
200
0%
1
6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
101
106
111
116
121
126
131
# of timed-out interests
700
100
1
6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
101
106
111
116
121
126
131
136
0
Consumer1
Consumer2
Consumer3
Time (s)
Fig. 6. Satisfaction ratios of Consumers 1, 2 and 3
Fig. 4. Number of timed-out Interests of Router1
1) Timed-out Interest Packets: We start by showing how the
network congestion impacts the timed-out interest packets. The
results shows that more than 90% of issued interest packets
are timed-out for congested network, which is a very huge
number. Further, the effect of network congestion on the PIT
of Router1 is depicted in figure 4, suggesting that about 90%
of pending interests are timed-out. This is due to the reason
that the network congestion in the network results in the delay
of the interest packets and as a result, the network experience
to drop these interest packets.
2) Dropped Packets: In this section, we show how the network congestion impacted Router7 (Core router). The figure
5 shows the number of dropped packets by the core router. It
is a considerable number when compared to the total number
of packets passing through the Core Router (1600 packets/s).
40% of packets are dropped. All the network packets (interest
and data packets) are passing through the core router. 40% of
whole network traffic is dropped.
3) Satisfaction Ratio: In this section, we analyze the impacts of a congested network on the satisfaction ratio. In
this section we prove that the existing solutions may give
false detection of an IFA. We can see that a congested
network can significantly decreases the satisfaction ratios of
router’s interfaces. For example Consumer1 who requests 100
interest/s is receiving an average of only 5 Data packets/s
which means a satisfaction ratio of 5%. The figure 6 shows the
satisfaction ratios values associated with consumers 1,2 and 3.
Solutions that relies only on the satisfaction ratio (e.g., Token
Bucket [6]) are inefficient when a network is congested.
In this section we showed how a congested network can
impacts the statistics of a router and may lead to mistakenly
detect an IFA. The other nodes in the network were not
affected by the network congestion.
D. Attack scenario
The last simulation scenario is the IFA scenario. In this scenario the Consumer3 is malicious. He is requesting 10000 of
forged interest packets per second. He is using the namespace
"/dest7/attack" to request data from Producer7 who satisfies interest packets in the namespace "/dest7/legit".
The goal of the attacker (Consumer3 in this scenario) is that
the interests arrive to destination (Producer7) without being
satisfied so they will stay in PIT tables until they time-out.
In this scenario we see a huge number of NACK packets.
This is the result of non existing data. The producers when
they receive an interest for non existing data they responds
Authorized licensed use limited to: BEIJING INSTITUTE OF TECHNOLOGY. Downloaded on December 08,2020 at 03:30:32 UTC from IEEE Xplore. Restrictions apply.
12000
10000
10000
8000
8000
6000
# of packets
# of packets
12000
Attack period
4000
2000
6000
Attack period
4000
2000
0
0
0
5
10
15
20
25
30
35
0
5
10
15
Time (s)
Attack started
20
25
30
35
Time (s)
Attack blocked
Attack started
Attack blocked
Fig. 7. Number of NACK packets receiver by Router1
Fig. 8. Timed-out interest packets by Router1
with NACK packets. The figure 7 shows the number of
NACK packets received by Router1 (Attacker’s Gateway). The
number of NACK packets starts to rise when the attack is
launched (at 10th second). The number of received NACK
packets will be stabilized at the value of 10000/s which equals
to the number of interest packets sent by the attacker. But
when the attacker is mitigated (blocked), the number of NACK
packets goes down to 0 NACK packet/s after 3 seconds.
Another parameter that changes when an attack is happening
is the timed-out interests. The figure 8 shows the number of
timed-out interest packets by Router1. We also noted some
timed-out Interest packets of legitimate users. This is because
of the attack but the number is not considerable compared to
the timed-out interest packets sent by the attacker. The number
of Timed-out interest packets in Router1 goes up in t = 10s
second (attack launch) until it stabilizes under 10000 timedout interest packets per second. Then this number starts to go
down in t = 30s when the attacker is blocked. This number
will goes down to 0 packet/s after 3 seconds.
In the results of figures 7 and 8 we see that the number
of NACK packets and timed-out interest packets are identical.
For our algorithm this mean that the network is not congested.
The not congested network is used by our algorithm to detect
an IFA initiator.
R EFERENCES
V. C ONCLUSION AND F UTURE D IRECTIONS
In this paper, we proposed a solution to detect and mitigate
the Interest Flooding Attacks in NDN. Our proposal takes
into consideration the network congestion and take it as a
parameter to avoid false alarms regarding the behavior of
the routers. Through simulation results we showed that the
network congestion can lead routers to mistakenly consider a
legitimate user as malicious. Finally we presented a scenario of
an IFA and showed how the attacker was mitigated. As future
works, we plan to extend our solution to detect other attacker
models. We are also planning to develop a collaborative
network congestion detection.
[1] J. Rexford and C. Dovrolis, “Future internet architecture: clean-slate
versus evolutionary research,” Communications of the ACM, vol. 53,
no. 9, pp. 36–40, 2010.
[2] R. Tourani, S. Misra, T. Mick, and G. Panwar, “Security, privacy,
and access control in information-centric networking: A survey,” IEEE
communications surveys & tutorials, vol. 20, no. 1, pp. 566–600, 2018.
[3] E. G. AbdAllah, H. S. Hassanein, and M. Zulkernine, “A survey of security attacks in information-centric networking,” IEEE Communications
Surveys & Tutorials, vol. 17, no. 3, pp. 1441–1454, 2015.
[4] L. Zhang, D. Estrin, J. Burke, V. Jacobson, J. D. Thornton, D. K.
Smetters, B. Zhang, G. Tsudik, D. Massey, C. Papadopoulos et al.,
“Named data networking (ndn) project,” NDN-0001, Xerox Palo Alto
Research Center-PARC, vol. 157, p. 158, 2010.
[5] P. Gasti, G. Tsudik, E. Uzun, and L. Zhang, “Dos and ddos in named
data networking,” in 2013 22nd International Conference on Computer
Communication and Networks (ICCCN). IEEE, 2013, pp. 1–7.
[6] A. Afanasyev, P. Mahadevan, I. Moiseenko, E. Uzun, and L. Zhang, “Interest flooding attack and countermeasures in named data networking,”
in 2013 IFIP Networking Conference. IEEE, 2013, pp. 1–9.
[7] H. Dai, Y. Wang, J. Fan, and B. Liu, “Mitigate ddos attacks in
ndn by interest traceback,” in 2013 IEEE Conference on Computer
Communications Workshops (INFOCOM WKSHPS). IEEE, 2013, pp.
381–386.
[8] A. Compagno, M. Conti, P. Gasti, and G. Tsudik, “Poseidon: Mitigating
interest flooding ddos attacks in named data networking,” in 38th annual
IEEE conference on local computer networks. IEEE, 2013, pp. 630–
638.
[9] T. N. Nguyen, R. Cogranne, G. Doyen, and F. Retraint, “Detection of
interest flooding attacks in named data networking using hypothesis
testing,” in 2015 IEEE International Workshop on Information Forensics
and Security (WIFS). IEEE, 2015, pp. 1–6.
[10] H. Salah, J. Wulfheide, and T. Strufe, “Coordination supports security:
A new defence mechanism against interest flooding in ndn,” in 2015
IEEE 40th Conference on Local Computer Networks (LCN). IEEE,
2015, pp. 73–81.
[11] A. Karami and M. Guerrero-Zapata, “A hybrid multiobjective rbfpso method for mitigating dos attacks in named data networking,”
Neurocomputing, vol. 151, pp. 1262–1282, 2015.
[12] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs,
and R. L. Braynard, “Networking named content,” in Proceedings of the
5th international conference on Emerging networking experiments and
technologies. ACM, 2009, pp. 1–12.
[13] S. Mastorakis, A. Afanasyev, and L. Zhang, “On the evolution of
ndnSIM: an open-source simulator for NDN experimentation,” ACM
Computer Communication Review, Jul. 2017.
Authorized licensed use limited to: BEIJING INSTITUTE OF TECHNOLOGY. Downloaded on December 08,2020 at 03:30:32 UTC from IEEE Xplore. Restrictions apply.