DeepAI
Log In Sign Up

Interest Flooding Attacks in Named Data Networking: Survey of Existing Solutions, Open Issues, Requirements and Future Directions (Extended version)

Named Data Networking (NDN) is a prominent realization of the vision of Information-Centric Networking. The NDN architecture adopts name-based routing and location-independent data retrieval. Among other important features, NDN integrates security mechanisms and focuses on protecting the content rather than the communications channels. Along with a new architecture come new threats and NDN is no exception. NDN is a potential target for new network attacks such as Interest Flooding Attacks (IFAs). Attackers take advantage of IFA to launch (D)DoS attacks in NDN. Many IFA detection and mitigation solutions have been proposed in the literature. However, there is no comprehensive review study of these solutions that has been proposed so far. Therefore, in this paper, we propose a survey of the various IFAs with a detailed comparative study of all the relevant proposed solutions as counter-measures against IFAs. We also review the requirements for a complete and efficient IFA solution and pinpoint the various issues encountered by IFA detection and mitigation mechanisms through a series of attack scenarios. Finally, in this survey, we offer an analysis of the open issues and future research directions regarding IFAs. This manuscript consists of an extended version of the paper published in ACM Computing Surveys: https://dl.acm.org/doi/10.1145/3539730.

READ FULL TEXT VIEW PDF

page 1

page 2

page 3

page 4

12/08/2020

Access Control Mechanisms in Named Data Networks: A Comprehensive Survey

Information-Centric Networking (ICN) has recently emerged as a prominent...
03/02/2021

Information-Centric Networking in Wireless Environments: Security Risks and Challenges

Information-Centric Networking (ICN) has emerged as a paradigm to cope w...
04/14/2021

Phishing Mitigation Techniques: A Literature Survey

Email is a channel of communication which is considered to be a confiden...
04/09/2019

A Survey on Software-Defined VANETs: Benefits, Challenges, and Future Directions

In this paper, first we survey the state-of-the-art SDN based Vehicular ...
07/05/2022

Sanitization of Visual Multimedia Content: A Survey of Techniques, Attacks, and Future Directions

The exploding rate of multimedia publishing in our networked society has...
04/16/2020

Online Social Deception and Its Countermeasures for Trustworthy Cyberspace: A Survey

We are living in an era when online communication over social network se...
03/04/2019

A Bibliometric Analysis of Publications in Computer Networking Research

This study uses the article content and metadata of four important compu...

1. Introduction

A long time has passed since the creation of the Internet. Back then, the goal was to interconnect pairs of hosts. With the constant growth of the connected devices that will reach almost 30 billion in 2023 (1), which represents roughly three times the global population, the actual Internet architecture was not designed for such massive numbers of hosts. In addition, Internet usage itself has changed. Users are interested in the content to retrieve rather than its source. In addition, security was an afterthought when the Internet was created, which opened the door to security and privacy issues. Taking all these challenges in mind, the need for a new, suitable, and secure Internet architecture is essential. The research community started the discussion on a new architecture about three decades ago (Chapin et al., 1991). Since then, many Future Internet Architectures (FIAs) were proposed like Xtensible Internet Architecture (XIA) (Anand et al., 2011), Nebula (Anderson et al., 2013), and others. However, the most promising FIA architecture candidate is Information Centric Networking (ICN) (Ahlgren et al., 2012; Xylomenos et al., 2013). Several architectures were proposed under the umbrella of ICN, like Data-Oriented Network Architecture (DONA) (Koponen et al., 2007), Publish-Subscribe Internet Technology (PURSUIT) (Fotiou et al., 2010), Scalable & Adaptive Internet soLutions (SAIL), COntent Mediator architecture for content-aware nETworks (COMET) (García et al., 2011), and MobilityFirst (Seskar et al., 2011). But the most promising information-centric architecture is Named Data Networking (NDN). NDN is a project funded by the US Future Internet Architecture in 2010 and maintained at UCLA (Zhang et al., 2010). NDN takes its roots from the Content-Centric Networking (CCN) (Jacobson et al., 2007).

NDN adopts a content-driven communication approach where packet forwarding is based on data names rather than IP addresses. NDN also provides features such as in-network caching, built-in multicast, mobility support, and native security mechanisms. NDN focuses on securing the content rather than the communication channels. NDN mandates the use of data signatures, which permits users to retrieve any available piece of content no matter where it comes from, as long as the signature can be verified. Although NDN integrates security mechanisms, it is still not immune to certain new security and privacy issues (Tourani et al., 2017; Khelifi et al., 2018). One of these network threats is related to Interest Flooding Attacks (IFAs). IFA is a new type of attack that adversaries use to launch (D)DoS attacks in NDN.

This survey provides an in-depth study of IFA and gives a broad analysis of IFA solutions that have been proposed so far before pointing out the open issues and providing the research directions that need to be considered in the future. Before we dive deep into the subject, we first review existing surveys and discuss the importance and novelty of our survey compared to the literature.

1.1. Related Surveys

Several surveys about NDN and ICN security issues have been authored. Some of them briefly discussed IFA, while others detailed IFA. In the following subsection, we summarize and explain the differences between each authored survey. The authors of (AbdAllah et al., 2015) surveyed several ICN attacks and grouped them into four different categories: naming, routing, caching, and miscellaneous. The survey briefly discussed IFA and the number of cited solutions is very limited. Similarly, the authors of (Tourani et al., 2017)classified ICN threats into three categories: security, privacy, and access control. The authors defined IFA as a DoS attack and reviewed some countermeasures. However, the authors did not compare in detail the reviewed works. The survey in (Mannes and Maziero, 2019) discussed security threats and vulnerabilities in ICN. It classified the attacks into three categories: security in content, routers, and caches. It discussed IFA and presented several IFA solutions. Despite lacking many relevant works, this survey did not detail the cited solution, and the provided review does not mention their drawbacks. The authors of (Aamir and Zaidi, 2015) presented a survey about DoS attacks in CCN and classified them into three categories: flooding, forced computation, and cache/content manipulation. The authors discussed IFA and gave a detailed review of some countermeasure solutions. However, this survey did not talk about their drawbacks. Also, this survey does not compare the cited works. The authors in (Lutz, 2016) stated the benefits of the CCN paradigm on some security and privacy threats. Then, they outlined the actual challenges that need to be corrected. They talked about IFA and mentioned few countermeasure solutions without giving any comparison. The survey in (Ambrosin et al., 2018) compared four FIA architectures: Nebula, NDN, MobilityFirst, and XIA in terms of integrity, confidentiality, availability, authentication, trust, access control, and anonymity. This paper shortly discussed IFA and the number of cited works is very limited. Similarly, the survey (Chen and Mizero, 2015) provides a short review about some NDN security issues before briefly discussing IFA without mentioning any solution. The authors of (Buragohain and Nandi, 2020) classified NDN attacks according to the targeted layer. They classified IFA as an application layer attack and presented a few countermeasure solutions. However, the list of covered solutions is poor and misses recent and relevant works. In another context, the authors of (Khelifi et al., 2018) presented different security and privacy issues in Vehicular NDN (VNDN). This paper shortly discussed IFA and mentioned only two countermeasure solutions. The work presented in (Gasti and Tsudik, 2018) focuses on IFA and privacy attacks in NDN/CCN. It classified solutions into simple techniques, Anomaly/Attack detection, and PIT-less routing. The provided analysis and the list of IFA work are limited. It lacks recent and relevant works. The authors of (Rai and Dhakal, 2018) and (Rai et al., 2019) focused on IFA and gave a short comparison between some existing solutions. However, the authors did not review in detail cited works. Also, these two surveys miss many recent and relevant works. The survey in (Kumar et al., 2019a) focuses on IFA and cache/content attacks. It described IFA and its variants before reviewing and classifying several solutions. Although it provides a long list of IFA solutions, this survey does not cover the full spectrum of IFA works and misses many recent and relevant works. Also, the authors did not review in detail cited solutions. We summarized the above surveys in Table 1.

width= Ref Year Main focus Limitations Covered IFA solutions (Aamir and Zaidi, 2015) 2015 DoS attacks in CCN     Does not compare cited IFA solutions.     Does not talk about the drawbacks of cited solutions. 09 (AbdAllah et al., 2015) 2015 ICN attacks     Briefly talks about IFA.     The number of IFA solution is limited. 04 (Chen and Mizero, 2015) 2015 Security issues in NDN     Do not mention IFA countermeasure solutions. 00 (Lutz, 2016) 2016 Security and privacy challenges in CCN     Does not talk about the drawbacks of cited solutions.     Did not provide a comparison between cited IFA solutions. 08 (Tourani et al., 2017) 2017 ICN attacks     Does not compare in detail cited IFA solutions 08 (Ambrosin et al., 2018) 2018 Security and privacy in FIA architectures     IFA was very shortly discussed.     Very limited IFA solutions. 03 (Gasti and Tsudik, 2018) 2018 IFA and privacy in NDN/CCN     Does not compare cited solutions.     The paper misses relevant works. 06 (Khelifi et al., 2018) 2018 Security and privacy issues in VNDN     Briefly discuss IFA.     The number of cited solutions is very limited. 02 (Rai and Dhakal, 2018) 2018 IFA in NDN     The survey misses a lot of relevant works.     The comparison given is very limited.     Does not mention the drawbacks of solutions. 10 (Kumar et al., 2019a) 2019 Security threats in NDN     The survey misses some recent relevant works.     Does not compare in details the cited solutions.     Does not talk about the drawbacks of every solutions. 21 (Mannes and Maziero, 2019) 2019 Security threats in ICN     Does not detail cited solution.     Does not mention solutions’ drawbacks.     Misses many recent relevant research. 10 (Rai et al., 2019) 2019 IFA in NDN     Does not compare between the cited solutions.     Misses many recent relevant research. 06 (Buragohain and Nandi, 2020) 2020 Security threats in NDN     Briefly discuss IFA.     The number of cited solutions is very limited. 05 Our 2021 IFA in NDN 43

Table 1. Related Surveys

1.2. Motivation and Goal of the paper

Although the previously authored surveys talk about IFA and some countermeasure solutions, they only scratch the surface of the subject. These surveys fail to cover all the aspects of the attack. Therefore, the authors only focused on presenting the solutions without deep analysis and comparison. In addition, the mentioned surveys do not study the full spectrum of IFA variants and scenarios. They generally describe the conventional version of the attack. Moreover, the present surveys do not cover all the works present in the literature. For instance, the majority of recent (and relevant) works were not considered by these surveys. Considering all these limitations, there is a need for a survey that provides an in-depth study of IFA to bridge this gap. There is a need for a paper that provides a basic understanding of the attack, its variants, its characteristics, and the different techniques used to conduct such attacks. Furthermore, there is a need to provide a systematic and detailed review of all the countermeasure works present in the literature. In addition, a comparative study needs to be conducted to unravel the strength and weaknesses of each solution. Finally, there is a need to pinpoint the actual open issues and the lessons learned for future research directions.

1.3. Our Contributions

Existing surveys in the literature are not IFA specific or do not discuss and compare in detail related IFA solutions. To the best of our knowledge, our work is the first attempt that comprehensively and systematically review all the aspects of the Interest Flooding Attack. The highlights of the various aspects covered in this work are summarized below:

  • Our survey provides a comprehensive discussion on state-of-the-art IFA research and an exhaustive research taxonomy of IFA by considering its working principles and approaches.

  • Our survey reviews all the relevant IFA countermeasure solutions. It discusses the drawbacks of each one and presents a workflow that every IFA countermeasure solution follows.

  • Our survey provides a comprehensive comparison of existing solutions. This comparison takes into consideration different aspects: the type of collected information, the calculated metrics, the detection parameters, and the defensive actions.

  • Our survey provides an extensive list of non-conventional attack scenarios that existing works cannot handle and existing literature has not considered. Il also presents directions for future research associated with designing efficient and robust IFA solutions.

1.4. Methodology of Survey on Interest Flooding Attack in Named Data Networking

In this subsection, we present the methodology that we utilized during our review of the state-of-the-art Interest Flooding Attack. The process that we adopted is described below:

  • Surveyed Databases To achieve our objective and cover all the relevant IFA-related research, we have collected papers on domain-relevant electronic databases, including ACM Digital Library, IEEE Xplore, Science Direct, Springer Link, Wiley Online Library, and Hindawi. Furthermore, we have collected articles related to this domain from arXiv, Google Scholar, and ResearchGate. Figure 1(b) illustrates the distribution of collected IFA works depending on their publisher.

  • Filtering and Paper Selection Process The filtering process begins by categorizing each paper depending on its nature: a study paper, a survey paper, or a solution. The study papers category includes any IFA based study authored. It may include studies on the effects of IFA or a comparative study between some solutions, …etc. Regarding survey papers, we chose to cite any survey that mentions (briefly or extensively) IFA, whether it is NDN specific or an ICN survey. However, for the authored solutions, we chose a different approach. Before we cite a paper in this survey, we first read the proposed technique and then verify if we have already reviewed a similar solution. If a similar solution exists, we compare the authors of these two papers. If they are the same, we choose to cite only the most recent one (e.g., the authors presented it in a conference paper and then published the same solution in an article paper). However, if the authors are different, we choose to cite the oldest research paper. On the other hand, If a given paper presents an enhanced or a modified technique to another published solution, we cite them consecutively. During our research, we collected 97 IFA based works. In the end, we chose 72 papers. Figure 1(a) illustrates the distribution of cited works since the research community started studying IFA.

(a) Distribution of cited works per year
(b) Distribution of cited works per publisher
Figure 1. Statistics on cited IFA research papers

1.5. Organization of the Survey

We organize this survey in a top-down manner. Table 2 lists all the acronyms used in this paper. We begin with an overview of the NDN architecture in section 2. We talk about the key features of this architecture before concluding this section with its security components. Following that, we introduce the NDN security requirements in section 3 before talking about the availability attacks that target the NDN architecture in section 4. We discuss each attack and finish this section by briefly presenting the Interest Flooding Attack. In section 5, we dive into the main subject of this survey and detail IFA. We show the characteristics of the attack and its variants before giving an overview of the IFA related studies present in the literature. Section 6 focuses on IFA solutions that were authored and gives a detailed discussion on each solution. Section 7 introduces the Collect-Detect-Act workflow (CDA). This section presents an in-depth study of state-of-the-art solutions from different perspectives. Section 8 discusses unconsidered attacking scenarios. This section proposes several attacking scenarios that were not considered by existing solutions. Section 9 highlights the lessons learned and future research directions that need to be considered when designing solutions. Section 10

concludes this survey. This paper includes an appendix section in which we compare existing solutions in terms of simulation parameters and evaluation metrics the they adopted.

width=13cm Acronym Explanation Acronym Explanation NDN Named Data Networking SPOF Single Point Of Failure CCN Content-Centric Networking AI Artificial Intelligence ICN Information-Centric Networking NN Neural Network FIA Future Internet Architecture RBF Radial Basis Function PIT Pending Interest Table SVM Support Vector Machine FIB Forwarding Information Base ndnSIM NDN Simulator CS Content Store ipps interest packet per second IFA Interest Flooding Attack FIFO First In First Out DDoS Distributed Denial of Service LRU Least Recently Used HMM Hidden Markov Model LFU Least Frequently Used AS Autonomous System DC Domain Controller Mon Monitoring CDA Collect Detect Act LRT Likelihood Radio Test MLP Multilayer Perceptron MANET Mobile Ad-hoc Network ARI Autoregressive Integrated NFD NDN Forwarding Daemon XIA Xtensible Internet Architecture

Table 2. Acronyms used in this paper

2. Named Data Networking: Architecture Design

NDN is a data-centric Internet architecture designed to replace the host-centric TCP/IP architecture (Zhang et al., 2014; Al Azad and Mastorakis, 2022b, a). NDN falls under the umbrella of Information Centric Networking (ICN) where the focus is on the data rather than its location. NDN defines two entities: Producer and Consumer. Producers generate and offer content for the consumers to request. To fetch for a content, consumers send the name of the desired data into an Interest packet. NDN adopts a hierarchical naming scheme to identify contents (Afanasyev et al., 2017).

2.1. NDN Protocol Stack

The NDN protocol stack is composed of four different layers: application, network, link and physical layers (Zhang et al., 2018a). The application layer supports the operation of NDN applications and it also embeds transport protocols as system libraries. The network layer’s role is to route Interest and Data packets. It uses the application layer’s names to route the packets. The NDN link-layer supports a set of protocols like Ethernet and can use virtual links like IP and TCP overlays. Figure 2(a) shows the differences between the TCP/IP and NDN protocol stacks.

2.2. NDN Packet Types

The NDN architecture uses two types of packets: Interest packets and Data packets. Figure 2(b) illustrates the NDN packets.

2.2.1. The Interest Packet

According to the latest NDN packet specifications (3), every Interest packet is composed of a set of mandatory and optional parameters. Each Interest packet must have a Name. It represents the name of the content that the consumer is requesting. The Nonce field is also mandatory when the Interest packet is transmitted over the network. It consists of a randomly generated 4octets long string. The Nonce is used to uniquely identify Interest packets, hence preventing them from looping in the network. The optional parameters that Interest packets may include are: CanBePrefix for the Interest packet’s name, MustBeFresh for the content of the requested data packet, InterestLifeTime represents for how long an NDN router will maintain state for this Interest, HopLimit and ForwardingHint are used in forwarding. The interest packet may also include application-specific parameters in ApplicationParameters. Furthermore, interest packets can also be signed when needed (4).

2.2.2. The Data Packet

Data packets are the response that NDN consumers expect when they send Interest packets. Data packets carry the content requested by a consumer. Each Data packet contains the following fields: the Name of the data, the payload of the Data packet held in the Content field and the DataSignature. Data packets may also contain some optional information in the MetaInfo fields: The ContentType, the FreshnessPeriod, which indicates how long the data can stay fresh, i.e., the producer did not produce newer data. The last parameter is the FinalBlockId which identifies the last packet of a sequence of fragments (2). NDN Data packets identify four principal content types. First is the BLOB type, which represents the default content type. The second is the LINK type, which is used to include a list of producers. This packet is used for forwarding purposes. The third is the KEY type, used to represent a certificate. Finally, the NACK type designates application-based NACK packets.

(a) TCP/IP and NDN Protocol Stacks
(b) NDN packets

2.3. NDN Node Model

The NDN protocol stack is composed of four different layers: application, network, link and physical layers (Zhang et al., 2018a). The application layer supports the operation of NDN applications and it also embeds transport protocols as system libraries. The network layer’s role is to route Interest and Data packets. It uses the application layer’s names to route the packets. The NDN link-layer supports a set of protocols like Ethernet and can use virtual links like IP and TCP overlays. Each node with the NDN stack maintains three data structures:

2.3.1. Pending Interest Table (PIT)

PIT is a data structure where are stored all the not yet satisfied Interest packets. Every pending Interest packet is stored in PIT until a Data packet returns or it times out. Each PIT entry contains the following fields: the name of requested Data (Interest packet’s name), the incoming interface(s), outgoing interface(s) and an expiry timer.

2.3.2. Content Store (CS)

Each NDN node can store the passing Data packets in a local cache (Cao et al., 2016). This enables NDN to offer in-network caching. Requests can be satisfied by an intermediate cache without going down to the source of the Data packet, which reduces time retrieval and saves links bandwidth. Each CS need to implement a caching policy to maintain its size and keep the most relevant and popular data. Many caching policies can be used, including but not limited to, FIFO (First In First Out), LRU (Least Recently Used) and LFU (Least Frequently Used) (Zhang et al., 2015; Din et al., 2017).

2.3.3. Forwarding Information Base (FIB)

FIB is used to forward incoming Interest packet to upstream nodes. Unlike IP networks, NDN’s FIB entries are indexed with name prefixes instead of IP addresses (Song et al., 2015). Every FIB entry is composed of a name prefix and a list of next hops. According to its forwarding strategy, routers can forward Interest packets to one or multiple hopes, hence enabling multi-path forwarding (Chan et al., 2017; Al Azad et al., 2021; Mastorakis et al., 2020b; Mtibaa and Mastorakis, 2020).

2.4. Routing and Forwarding

NDN routers use application namespace instead of IP addresses to forward packets (Li et al., 2018). Routers update and announce their FIB entries using routing algorithms (Lehman et al., 2016; Voitalov et al., 2017; Ghasemi et al., 2018), or a self-learning mechanism (Shi et al., 2017). Unlike IP routers, NDN routers use stateful forwarding, i.e., routers keep information about the received requests until they are satisfied or timed-out (Yi et al., 2013). The forwarding strategy forwards Interest packets according to the FIB entries, local measurements or other per-namespace forwarding policies (Shi, 2017). The forwarding strategy is also responsible for choosing the destination interfaces. NDN routers could also use multi-path forwarding to ensure priority, load-balancing and avoid failed links. Every Interest packet brings no more than one Data packet, and each response takes the reverse path of its corresponding request. The NDN forwarding process is illustrated in Figure 2.

Figure 2. Interest and data packet forwarding process

2.4.1. Interest packet forwarding: Requesting data

When a router receives an Interest packet, first it checks if the requested data can be satisfied from the local CS (i.e., it matches the received data name with the existing content names in the CS). If the requested data already exists in the local CS, the router sends back the Data packet to the source interface, i.e., from where the Interest packet came from. If the CS does not hold the requested Data packet, the router performs the following actions: first, it checks the PIT for any similar pending request, If an entry with a similar name already exists in the PIT, the router matches the source interface with all the interfaces associated with this pending entry. If the interface already exists, the incoming Interest packet is considered as a duplicate packet and will be discarded. Otherwise, the router adds the source interface to the list of interfaces associated with the pending Interest i.e., aggregates the incoming Interest packets requesting the same data. On the other hand, when no pending Interest with the same name exists in the PIT, the router creates a new entry for this Interest packet. Once the PIT lookup process finished, the router sends the Interest packet to its upstream neighbor(s) according to its forwarding strategy. NDN routers can also send a NACK packet to their downstream nodes when the Interest packet cannot be satisfied, e.g., no matching entry in FIB, the upstream links are down (Abraham and Crowley, 2017; Vusirikala et al., 2016).

2.4.2. Data packet forwarding: Receiving data

When a consumer’s request is satisfied from a data producer or in-network cache, a Data packet is sent back. When a router receives a Data packet, it checks if it was requested before by verifying the existence of a pending Interest with the name of the received data. If no match exists in the PIT, the router drops the received Data. Otherwise, and according to its caching strategy, the NDN router stores (or not) the received Data before sending it downstream to all the interfaces associated with the pending Interest in PIT. The aggregation of source interfaces gives NDN routers a built-in multicast mechanism.

2.5. NDN Security: Data-centric Security

The NDN design natively embeds security mechanisms and mandates the use of signatures in Data packets (Ramani et al., 2019). Producers need to digitally sign every Data produced. This will enable consumers to verify and validate the authenticity of the received Data. Also, it permits to network nodes, i.e., routers and repositories, to store Data (Psaras et al., 2018). Furthermore, it allows consumers to retrieve and accept Data packets regardless of their source (Newberry and Zhang, 2019). The NDN architecture integrates some security components to ensure data security (Zhang et al., 2018d). Figure 3 illustrates the below detailed security components.

2.5.1. Packet signature

Every Data packet includes a signature field (Zhang et al., 2016a). The signature binds the content of the packet to its name (Li et al., 2019b). The Signature field contains two components: SignatureInfo and SignatureValue. The SignatureInfo component embeds the name of the producer’s public key and the cryptographic algorithm used to sign the Data. The SignatureValue represents the bits of the generated signature. Althouth NDN does not mandate the use of signatures in Interest packets, however, in some scenarios where the authenticity of Interest packets is needed, signatures are required, e.g., a router sends a new route announcement, sending a command packet to an IoT device, etc. The Interest packet’s signature field includes additional components compared to the Data packet’s signature. It includes a SignatureNonce, a SignatureTime and/or a SignatureSeqNum. These components are used to add uniqueness to the signature.

2.5.2. Trust Schema and Access Control

Although that Data packet’s signature allows the consumers to validate the received Data and proof its originator, it does not show whether the signer is authorized to produce the data or not (Yu et al., 2015; Nour et al., 2021). Consumers need a mechanism that allows them to check if a producer has the right to produce Data under a given namespace, i.e. if a producer’s key has the right to sign a Data packet under a given namespace (Shang et al., 2017). Application-based trust policies are used to define which keys are authorized to sign which Data. Besides, applications can also implement access control policies to protect the content of a Data packet, through encryption, and permit only authorized nodes to decrypt it (Zhang et al., 2018c; Lee et al., 2018).

2.5.3. Key pairs and Certificates

Every data producer need at least one cryptographic key pair. Producers use private keys to sign Data packets and consumers use public keys to verify them. Each public key is embedded in a digital certificate. The NDN certificate is a Data packet signed by an issuer (Afanasyev et al., 2016). It contains the producer’s public key encoded in X509 format (Zhang et al., 2017). The name of an NDN certificate follows a specific naming convention: /SubjectName/KEY/KeyId/IssuerId/Version, where SubjectName is the prefix to which the key is bound to, i.e., the namespace to which the key can operate under. Followed by the keyword KEY is the KeyId, which represents the value of the key. The value can be an 8-byte long random value, SHA-256 digest of the public key, a timestamp or a numerical identifier. After that comes the information about the issuer and the version of the certificate. Like any NDN Data packet, certificates include also a signature field, i.e., signature of the issuer.

Figure 3. NDN security components

2.6. Named Data Networking vs TCP/IP

The following subsection introduces a comparison between NDN and TCP/IP in terms of routing and forwarding, multicast, mobility, and security. Table 3 summarizes the differences between these two architectures.

2.6.1. Routing and forwarding

Using names instead of IP addresses comes with some advantages: first, compared to IP addresses, names are unbound and have no limit. Second, address translation NAT is no longer needed. Third, there is no need to assign and manage IP addresses in local networks. Moreover, NDN networks are immune against packet looping so nodes can take full advantage of multipath forwarding. Figure 4 depicts the differences of packet forwarding between NDN and TCP/IP.

Figure 4. NDN vs TCP/IP packet forwarding

2.6.2. Multicast

IP networks support multicast, but setting up multicast groups in IP networks is hard. Members need to know the group address to join it. Also, the number of nodes in a multicast group is limited. Moreover, multicast groups are difficult to deploy in large networks like the Internet. NDN comes with a built-in multicast forwarding mechanism with no pre-configuration required. NDN routers aggregate source interfaces requesting the same content in PIT. This allows routers to send the data packet to all requesting interfaces at ones, hence performing multicast forwarding (Mastorakis et al., 2017).

2.6.3. Mobility

Mobility is another application field that NDN handles better than IP networks (Zhang et al., 2016b, 2018b). The constantly changing network topology and paths make packet routing challenging in mobile networks. The data-centric approach that NDN adopts is beneficial to mobile networks like MANETs (Mastorakis et al., 2020a; Li et al., 2019a). There is no need to maintain and manage nodes’ IP addresses. Besides, the cache-store that network nodes offer reduces the delivery time and gives alternative paths to requested data even if the source is not reachable (i.e., the data producer).

2.6.4. Security

IP networks rely on communication protocols like TLS (Dierks and Rescorla, 2008) and IPSec (Krishnan and Frankel, 2011) to securely send data packets. NDN networks, on the other hand, focalize on securing the network’s most valuable asset, the data. Unlike IP networks, NDN secures the data instead of securing its path. By securing directly the data, NDN networks relieve the nodes from maintaining and monitoring secure channels and allow data producers to only focus on securing the data that they produce (Zhang et al., 2018d).

Propriety NDN TCP/IP
Architecture Data-centric Host-centric
Identification Names IP addresses
Forwarding Stateful forwarding Stateless forwarding
Forwarding paths Request Multipath forwarding. The request packet could be forwarding through multiple faces Single path forwarding
Response The response packet takes the reverse path of the request The response packet does not necessarily take the request’s path
Caching Intermediate nodes All NDN routers offer in-network caching Routers do not offer data caches
End nodes Every NDN node can offer a data cache Only specific nodes like file servers and P2P nodes
Multicast Built-in multicast mechanism Uses multicast address range
Mobility The NDN nodes are independent of their location The nodes IP addresses are location dependent.
Security Secures data packets Secures communication channels using protocols
Table 3. Comparison between NDN and TCP/IP

3. NDN Security Requirements

3.1. Confidentiality

Information confidentiality is essential to any security system. Network entities should restrict any unauthorized actors from accessing any confidential resources. NDN opens new challenges for data confidentiality. Data packets are more susceptible to breaches because of in-network caching. To provide data confidentiality, NDN nodes need to use encryption and implement strict access control schemes to prevent data leakage (Shang et al., 2015).

3.2. Privacy

Privacy aims to prevent unauthorized actors from accessing private, personal, or confidential information which may be used to identify and track nodes or individuals. NDN uses application namespaces instead of IP address to route packets in the network layer. This can be challenging for privacy and anonymity. Users’ traffic could easily be monitored and filtered as showed in Fig. 5.

Figure 5. Example of a privacy attack

3.3. Authentication

The process of verifying the identity of a node is called authentication. In scenarios where nodes’ identity needs verification, authentication is necessary. It represents any additional information that can identify the authorized nodes like passwords and certificates. NDN mandates data packets signatures, which implies the authentication of every data packet before consumption.

3.4. Integrity

Data integrity prevents authorized and unauthorized nodes from making illegitimate modifications. The NDN architecture mandates the use of cryptographical signatures in every data packet produced. This enables a native data integrity mechanism in NDN. When the content of a data packet changes, consumers or network routers can easily detect it. However, this mechanism cannot provide immunity from threats. The data producer can suffer a key breach. The data content could also be altered before being signed by the producer.

3.5. Non-repudiation

Non-repudiation ensures that an entity cannot deny the production of a packet or its content. The data packet’s signature guarantees a non-repudiation mechanism in NDN. A data producer cannot deny the ownership of a data packet because it contains its signature. However, the private key of a producer could be stolen by a hacker or accidentally leaked because of human error. The certification authority could also be compromised. furthermore, interest packets are not signed by default. All these challenges are to consider when implementing a non-repudiation mechanism.

3.6. Availability

System availability consists of ensuring functional and uninterrupted access to authorized nodes. Multi-path forwarding and in-network caching are two strong assets that NDN offers to nodes to guarantee a high data availability level (Yeh et al., 2014). However, NDN Adversary nodes can launch (D)DoS attacks to affect and disturb systems availability. In NDN networks, routers and producers resources are potentials targets to (D)DoS attacks (Gasti et al., 2013).

4. Availability Attacks in NDN

Availability in NDN is susceptible to various types of attacks. In this section, we detail the availability attacks that target NDN routers and producers.

4.1. Availability Attacks Against Routers

Every NDN router component is a potential target for attackers. This subsection explains the availability attacks that routers can deal with.

4.1.1. Availability attacks against the Content Store

  1. [label=()]

  2. Cache pollution attack: To reduce time retrieval and network traffic, NDN nodes use the CS to cache the frequently demanded data. The cache pollution attack consists of altering the popularity of stored content. The attacker tries to evict popular content from caches by continuously requesting non-popular content. Figure 6(a) shows a scenario of cache pollution attack.

  3. Cache poisoning attack: Another CS-based attack is the cache poisoning attack. The goal of the attacker is to fill routers’ caches with invalid Data. The attacker tries to inject Data packets with valid names but altered or malicious content. Unlike cache pollution, cache-poisoning attacks are slightly hard to perform as it implies the modification of the content. The packet’s signature binds the name to the content, so any change on the content results in an invalid Data packet. However, the attacker can still spread malicious Data packets in the network, as routers tend to not verify Data authenticity at wire rate (Gasti et al., 2013). Attackers can perform cache poisoning attacks in two ways: (1) with malicious producers that send poisoned Data. In this scenario, the malicious producers could also cooperate with malicious consumers to flood the network with invalid Data (Nguyen et al., 2017). (2) With malicious consumers. In this attacking scenario, the malicious nodes either perform a man-in-the-middle attack or control compromised routers (e.g., edge routers) as shown in figure.6(b).

4.1.2. Availability attacks against the FIB

The availability attack that targets router’s FIB is the false route announcements. The purpose of this attack is to inject false routes into the network. The attacker needs to take control of the router to perform such an attack. The adversary, which controls an edge router, injects false paths to redirect legitimate requests to a malicious provider, as shown in Figure.6(c). In a different scenario, adversarial consumers can also send false routes in a mobile network, like Vanet, to perform other attacks like black holing or packet interception (Khelifi et al., 2018).

4.1.3. Availability attacks against the PIT

The main attack that targets PIT availability is the Interest Flooding Attack (IFA). An attacker target PIT’s availability by sending to it a large number of Interest packets so it cannot accept legitimate requests. We discuss IFA in detail in Sec.5.

(a) Example of a cache pollution attack
(b) Example of a cache poisoning attack
(c) Example of a false route announcement attack
(d) Example of an Interest Flooding Attack
Figure 6. Availability Attacks in NDN

4.2. Availability attacks against Producers

Producer-based availability attacks are mainly associated with IFA. Attackers could target one or multiple producers by sending a big amount of Interest packets towards them. Malicious nodes can lunch attacks against producers using all types of Interest packets mentioned in 5.2. The damage that IFA can inflect on producers depends on the nature of Interest packets used during the attack. Depending on the severity of IFA, producers can suffer resources damages due memory and processing overhead.

5. Interest Flooding Attack

The Interest Flooding Attack consists of flooding the network with a massive number of Interest packets to drown network routers and/or data producers, as shown in Figure 6(d). The main goal for attacking routers is to fill their PIT with unnecessary Interest packets so there will be no remaining entries for incoming legitimate Interest packets, which results in a denial of service. Additionally, data producers could also suffer a DoS from IFA. This includes memory exhaustion, service overload or any other hardware related overhead. attacks could be local, launched by one or a small group of nodes, or distributed, initiated by a large group of nodes often controlled by one master node.

5.1. Local and Distributed Interest Flooding Attack

IFA is considered local when one or a small group of locally connected attackers perpetuates them. Another form of IFA is distributed. A distributed IFA occurs when the victim suffers from massive traffic originating from a large number of distributed nodes. These groups of nodes, called botnets, are usually constituted of compromised systems managed by an attacker through one or multiple botnet controllers. Distributed IFA are difficult to stop and present a big threat as it floods the target with a large number of requests, resulting in a devastating attack. Botnet networks could implement hundreds of thousands to millions of nodes.

5.2. Taxonomy of IFA Requests

Attackers could perform IFA using two types of Interest packets. The first type of Interest packets carry valid data requests, and the second type carries invalid data requests.

5.2.1. Valid data requests

The first type of requests that attackers could use to attack a target with IFA is valid data requests. This type of data requests is further divided into two classes: requesting static data or dynamic data.

  1. Requesting static data: The first type of valid requests that attackers could use to perform IFA on a target is using Interest packets with valid names. Like any other valid Interest packet, these requests are satisfiable by data producers or network caches. The attack consists of sending an enormous number of Interest packets to the network to choke network routers and data producers. Static data are generally stored in intermediate caches or repositories, which reduces the traffic heading to producers, i.e., the request will be satisfied before reaching its producer. However, even that static data are likely to be found in network caches, the attack can still inflict serious harm to data producers especially in its debut, i.e., when data is not stored in caches. Besides, the malicious traffic induced by the attack can cause serious problems to the network especially in case of a large-scale attack.

  2. Requesting dynamic data: Dynamic data represent any content that producers generate on-demand. Unlike static content, dynamic data changes over time and needs to be produced when a request arrives. The optional FreshnessPeriod field in Data packets indicates for how long the content could be considered as fresh. Dynamic Data can range from the current record of a sensor in an engine to the actual stock price values. As their content are time-dependent, dynamic Data are usually not stored in caches. Attackers can take advantage of this aspect to lunch IFA against producers. In fact, dynamic data requests are normally not satisfied by network caches and are likely to be routed to their producers. This may cause high damage to producers as they use hardware resources to process and sign the content before sending it back.

5.2.2. Invalid data requests

An invalid data request corresponds to any Interest packet with an invalid content name, i.e., forged Interest packet. Attackers can lunch IFA using fake Interest packets. There are two different ways of forging an Interest packet’s name: the first method is to choose a completely random name for the Interest packet. As their names are random, the Interest packets will not reach any producer and will affect only network routers. Nevertheless, the first type of forged Interest packet could heavily affect the network, especially the routers near the source of the attack. The second method of forging Interest names is to append a random series of characters to a real producer’s prefix. This ensures that the forged Interest packet will reach the targeted producer. For example, if an adversary wants to target a producer ”/Prod”, the Interest packets’ names that the attacker may use are similar to ”/Prod/nonce” where nonce is a random value. This type of forged Interest packet will affect producers and all the network routers traversed by the forged Interest packet. IFA with invalid data requests is more harmful to the network compared to an IFA with valid data requests. This is because routers will not aggregate the Interest packets and will stay in PIT until they time-out. NACK packets help reduce the number of pending invalid PIT entries. However, the attack can still do harm to the network. Additionally, attackers can use this mechanism to flood the network with NACK packets.

5.3. IFA Studies

IFA was first mentioned in (Jacobson et al., 2009). The authors of this paper talked about how consumers could overwhelm the network by generating a huge number of Interest packets. Following that, several papers studied the IFA phenomenon and its impacts on the network. The authors of (Gasti et al., 2013) discussed IFA and cache poisoning attacks before giving some tentative countermeasures. The authors of (Choi et al., 2013) conducted a study on the impact of IFA, through a series of simulation tests, on the throughput and the delay. The authors in (Virgilio et al., 2013) evaluated three PIT architectures against IFA according to their memory consumption: the default PIT, a hashed names-based PIT, and a bloom filter-based PIT. Similarly, the authors of (So et al., 2013) presented a hash-based design to reduce memory occupancy. On the other hand, authors in (Pang et al., 2017) conducted a study on the collusive IFA, where attacker cooperate with a malicious provider to overwhelm the network. In (Compagno et al., 2015), the authors discussed the benefits and issues of using network-based and application-based NACKs to help mitigate IFA. Similarly, the authors of (Wang et al., 2017a) argued that NACK packets help routers from keeping pending Interests in PIT until they time out. Another similar study was presented in (Wang et al., 2019). The authors also recommend the usage of NACKs to remove pending requests and hence mitigate attacks. In (Signorello et al., 2017), the authors evaluated three collaborative solutions against two variants of IFA: The first uses different name prefixes. The second uses a mix of valid and invalid names. Similarly, in (Al-Sheikh et al., 2015), the authors compared five techniques according to their satisfaction ratio. In another context, The authors of (Kumar et al., 2019b)

conducted a comparison study between several machine learning algorithms to detect IFA.

6. Related Works on Interest Flooding Attacks

Many IFA solutions are present in the literature. In this section, we categorize the IFA related works into two main categories, as illustrated in Figure.7. The first category, named the stateless category mentions the solutions that took a stateless architecture approach to deal with IFA. The second is the stateful solutions category. This category is further classified into proactive and reactive solutions subcategories.

Figure 7. Taxonomy of IFA solutions

6.1. Stateless solutions

The solutions in this category chose a stateless approach to deal with IFA (i.e., do not store traffic-related information in PIT). The authors of (Ghali et al., 2017) proposed a new architecture named Stateless CCN. The solution modifies the Interest and Data packets to incorporate a new component, called Supporting Name, which includes the consumer’s prefix. Routers use the consumer’s name to forward back the content packet. In this architecture, every consumer needs to be identified, which raises prefix announcements and management problems. Besides, this architecture introduces some TCP/IP based threats, like reflective and privacy attacks.

In a different approach, the solution proposed in (Alston and Refaei, 2016) uses cryptographic tokens to route packets. Each receiving router updates these token, called route tokens, with additional information to forward the Data backward. Symmetric keys are used to ensure the integrity and confidentiality of route tokens. Although this solution prevents memory consumption due to PIT overhead, the proposed technique may consume a lot of processing resources, especially with large traffic. Attackers can use it as a tool to inflict high damage to routers, and the damage gets even higher as it gets closer to the core network.

6.2. Stateful solutions

The last main category of our classification groups the stateful solutions authored in the literature. The stateful solutions category is divided into: proactive and reactive solutions. Figure 8 illustrate the different stateful IFA solutions.

Figure 8. Taxonomy of stateful solutions

6.2.1. Proactive solutions

A small group of proactive countermeasure solutions are present in the literature. The authors of (Wang et al., 2017b) introduced micro-payments into the network to regulate IFA. Authority nodes in the network act as banks to conduct any virtual money-related actions. To request a Data packet, consumers need to add a prepayment to the Interest packet, which includes a PIT delay and content delivery fees. When the request reaches a destination, the node checks its content delivery fee, deducts the necessary amount, and sends the content downstream. Every traversed router takes an amount from the content delivery fee. The consumer receives the requested Data packet only if the fees are sufficient to cross all the nodes. The micro-payment system limits legitimate traffic. Also, legitimate consumers can be penalized in scenarios like unsatisfied requests or unavailable producers. Additionally, deploying and maintaining such a system is extremely hard in large networks, given that the system relies on central nodes to act as banks. To overcome this problem, the authors in (Zhang and Li, 2019)

proposed a payment solution that relies on auto-regressive integrated (ARI) and the hidden Markov models (HMM). When a router receives an

Interest packet, the price that the router charges to forward the incoming Interest depends on the number of pending requests associated with this interface. The router uses the satisfaction ratio as a parameter for the Hidden Markov Model to predict the consumer’s state, legal or bad. Besides the fact that legitimate traffic is penalized by the charge/reward mechanism, relying only on the satisfaction ratio to predict the consumer’s state may lead to false detection.

Another proactive solution was presented in (Li and Bi, 2014). It employs a proof-of-work mechanism to countermeasure the signing overhead resulting from IFA requesting dynamic content. When a consumer expresses the need for specific data, he needs to answer a puzzle sent by the producer and re-sends the Interest packet with the computed value (result). If it is correct, the producer sends back the Data. To reduce the communication delay resulting from retrieving/answering puzzles, the solution in (Tourani et al., 2020) relies on tokens that consumers get when they solve computational puzzles. When a consumer sends an Interest packet, the edge router verifies if the token exists in its table. If it does, it forwards the Interest and updates the count number of this token. Furthermore, core routers monitor the loss rate of each interface. When it reaches a threshold, the router suspects malicious traffic and starts using a bloom filter, instead of PIT, to store incoming Interest from this interface. Similarly, the authors of (Liu et al., 2018a) proposed BLAM, a lightweight bloom filter-based mitigation technique for IoT devices. In this solution, each IoT node uses a bloom filter array during the forwarding process. When an Interest arrives, the node matches its name with the bloom filter array. If an entry exists, the node continues the forwarding process. Otherwise, the node considers the received Interest as malicious and discards it. The proposed solution cannot be deployed on large networks as it requires knowing all the Data packets that producers offer. Similar to the last three techniques, this solution does not prevent IFA. Attackers can still flood the network with Interest packets.

6.2.2. Reactive solutions

Several IFA reactive solutions have been proposed. Reactive solutions are classified into router-based and producer-based solutions. Router-based solutions are further grouped into centralized and distributed solutions as showed in Fig 9.

Figure 9. Taxonomy of reactive solutions

Centralized router-based solutions Several centralized router-based IFA mitigation solutions exist in the literature. The solution presented in (Salah et al., 2015) relies on a Domain Controller (DC) and a group of selected routers named Monitoring Routers (MR) to detect IFA. The MRs calculate the PIT usage and the expired Interests associated with each interface. When these metrics exceed a certain threshold, the MRs send the name prefixes and their respective expiration rates to the DC. The DC will then decide on the infected name prefixes and inform the MRs. However, the metrics used can lead to false detection in the case of high legitimate traffic or unavailable producers. In addition, the legitimate requests going to infected prefixes can be affected. The authors proposed an enhanced version in (Salah and Strufe, 2016) capable of detecting collusive IFA. Compared to the previous solution, this mechanism relies only on PIT usage, which leads to false-positive situations affecting legitimate requests.

Unlike the previous two, the solution in (Yin et al., 2019) relies on every router to collects and sends to the domain controller the number of Interest, Data, and NACK packets. The controller calculates the satisfaction ratio associated with each router. If the metrics exceed their respective thresholds, the controller considers that this router is under attack and sends back the malicious prefixes. However this solution relies on the controller to calculate the metrics, which makes it a SPOF. Also, the traffic that routers send may overwhelm the network. To overcome this problem, the solution proposed in (Cheng et al., 2019) relies only on edge routers. when the rate and the number of timed-out Interests of a router’s interface exceed their respective thresholds, it informs the controller. The latter inspects the received traffic information and checks whether the links will reach their capacity. If one or more links are likely to reach their capacity, the controller determines that an IFA is happening and informs the routers on the interfaces to block. The proposed solution may consider high traffic rates as malicious.

The solution presented in (Alhisnawi and Ahmadi, 2020) has the particularity to rely not only on a domain controller but also a content provider. When the content provider router (CPR) receives an Interest, it verifies the name of the Interest against the FIB and the Quotient-based Cuckoo filter (QCF), which represents an updated list of fake Interest names. If the name exists in the QCF and no entry is found in FIB, it considers this Interest as malicious and sends its name within a warning message to the controller. The controller then updates the QCF before informing the edge routers. When an edge router receives the warning message, it restricts the originating interface. However, the QCF table could be used by attackers. Also, the content provider router needs to process all Interests of the AS, which is resource-consuming.

Distributed router-based solutions The majority of IFA solutions that exists in the literature are distributed router-based solutions. In (Nguyen et al., 2015), the authors presented a solution that uses hypothesis testing theory to detect IFA. Routers calculate a packet-loss rate associated with each interface to model the legitimate traffic. Then this model is used to detect IFA. Regardless of being a detection-only mechanism, the proposed solution relies only on the number of Interest and Data packets statistics to identify IFA, which may give false-positive results. Routers can alleviate this problem if they cooperate to detect IFA. The authors also employed this technique to detect collusive IFA in (Nguyen et al., 2019). Similarly, the proposed solution in (Xin et al., 2017) analyses the traffic using a discrete wavelet transform in an uncooperative way to detect collusive IFA. The detection process can be resource-consuming in some scenarios. These two solution do not act to mitigate attacks.

The authors of (Afanasyev et al., 2013) proposed a solution based on the token bucket. It consists of distributing the tokens according to interfaces’ satisfaction ratio. When a router calculates the limit values of an interface, it announces this limit to the neighboring routers connected to it. The receiving routers will then adapt their sending rates according to the received value. In addition to the satisfaction ratio, the solutions proposed in (Compagno et al., 2013), use the PIT usage of each interface. The router suspects malicious traffic when these two metrics exceed their thresholds. As a mitigation action, the router limits the incoming traffic and penalizes the interface with reduced thresholds. Then, it sends an alert message to the router connected to this interface to inform it about the reduced rate. Similar to the previous solution, the rate limit employed can impact legitimate consumers. Similarly, routers in (Dai et al., 2013) monitor the size of their PIT. When the size exceeds a certain threshold, the router generates a spoofed Data packet and sends it back to the originator of the spoofed Interest. Then, the edge router limits the rate of the source interface. Another pushback-based mechanism was proposed in (Xin et al., 2016). In this solution, routers monitor the name of incoming Interests and compute the interface’s cumulative entropy. When This latter exceeds an upper bound, the router confirms that an attack is undergoing. Afterward, the router sends a spoofed Data to the originators of the malicious prefix. When an edge router receives the spoofed Data, it applies rate limiting on source interfaces. Besides the resource exhaustion of the detection process, legitimate interfaces can be penalized by rate-limiting in some scenarios. Another drawback is that attackers can use the spoofed Data as a tool to drown the network.

The authors of (Wang et al., 2013) proposed a solution that decouples the malicious traffic from legitimate traffic to prevent PIT exhaustion. Routers monitor the number of timed-out Interest packets under each prefix. When the router considers the prefix under attack, it stores this prefix in a list called ”m-list”. The router forwards the Interest packet without storing it in PIT if the prefix exists in the m-list. This solution limits the effects of an IFA but does not stop it. Also, it affects legitimate requests. Furthermore, attackers can target the router’s resources by forging names to fill the m-list, which makes the solution inefficient. Similarly, the mechanism presented in (Wang et al., 2014a) monitors the timed-out Interest packet to detect IFA. It expands the FIB to include four additional fields. When an Interest times out before a Data returns, the router changes the mode value of this prefix to malicious and increments a related counter Ci in FIB. If the Ci value goes above a predefined threshold, the router applies rate limiting on this prefix. The rate-limiting used in this solution is associated with FIB entries, which affects all the traffic of this entry. The solution in (Vassilakis et al., 2015) also relies on the number of expired PIT entries. Edge routers classify each interface, according this metric, into three categories: normal, suspicious, or malicious. The edge router can reduce or block the traffic depending on the interface’s behavior. It also notifies other routers if it blocks a consumer. However, identifying NDN consumers is not an easy task, which makes this solution hard to apply.

The authors in (Tang et al., 2013) presented a two-phase detection mechanism. A router calculates the satisfaction ratio of each interface. If it exceeds its threshold, the router counts the number of expired Interests under each prefix. If the number exceeds its threshold, the router considers the prefix as malicious and starts blocking Interests going to this prefix. Similarly, in (Shinohara et al., 2016), routers calculate a reputation value for each interface depending on its satisfaction ratio. If an interface has a low reputation value, the router checks if the number of PIT entries is high. In this case, it discards incoming Interests. These two solutions do not prevent attackers. Additionally, they may lead to blocking legitimate Interest as they rely only on the satisfaction ratio.

The solution presented in (Wang et al., 2014b) relies on fuzzy logic to detect IFA. Every router on the network monitors the PIT occupancy and PIT expiration rates. The router takes these values as entries for the detection algorithm. If an IFA is detected, an alert message containing the malicious prefix is sent to downstream routers. When an edge router receives the pushback message, it limits the traffic going to the malicious prefix. The detection mechanism is resource-consuming. Besides, namespace-based rate-limiting can also affect legitimate requests and may lead to false-positive detection in some scenarios. To avoid false detection, the work presented in (Benmoussa et al., 2019) takes network congestion as a parameter when detecting IFA. Edge routers classify a consumer as suspicious when its incoming rate and satisfaction ratio are above and below their respective thresholds. After that, the router checks the network congestion to avoid false detection. It compares the number of timed-out Interests with NACK packets. If the network is not congested, the router classifies the consumer as malicious and blocks it. However, the congestion detection process employed is not cooperative, which may give false results in some scenarios.

Unlike the previous solutions, the authors in (Karami and Guerrero-Zapata, 2015) proposed an AI-based mechanism to mitigate IFA and cache poisoning using Radial Basis Function (RBF) neural networks. It uses a set of statistics as inputs, such as the number of satisfied and timed-out Interests. When the detector module signals malicious traffic, the router sends an alert message to source interfaces. The alert message contains the new reduced rate, the generation timestamp, and the reduction period. However, the rate-limiting can affect legitimate consumers. Another machine learning-based detection mechanism was proposed in (Zhi et al., 2019). In this solution, a router constantly collects the entropy of Interest

names, the satisfaction ratio, and the PIT usage of interfaces before using them as entries for the support vector machine (SVM) classifier. If the detector classifies it as an anomaly, the router declares that an IFA is happening. Following that, the router extracts the malicious prefixes using the Jensen-Shannon divergence. Then, it informs downstream routers about the malicious prefixes. This solution affects also the legitimate

Interest packets going to blocked prefixes. Similar to the previous solution, the detection process may consume a lot of resources.

The authors of (Ding et al., 2016)

presented a solution based on the vector space model and Markov chains. When the PIT size reaches an alarming level, the router determines a state for each received

Interest (normal, unknown, and risk). Upon receiving an Interest, a router first checks its state. If the previous (i.e., received from the upstream router) and the actual (i.e., calculated by the router) are both equal to risk, the router discards the Interest. To prevent legitimate requests from being discarded, the proposed solution stores a copy of unsatisfied Interests in a specific cache, so if an Interest with the same name arrives, the router considers it as legitimate. However, attackers can use this propriety to target routers. Additionally, the process of state checking consumes router’s resources.

A statistical solution, that uses Gini impurity, was proposed in (Zhi et al., 2018). A router monitors the name of received Interests

and calculates their probability. Then, it uses Gini impurity to measure the disparity of the set and compares it with a threshold to determine if an IFA is happening. After that, the router uses Gini impurity to compare the actual set with a previously recorded set to detect the malicious prefix. The proposed solution may lead to false-positive detection. Similarly, An entropy-based solution was proposed in

(Hou et al., 2019). Based on the fact that when IFA happens, the occurrence of forged names increases, and the Thiel entropy decreases. Every router records the names of incoming Interest packets and calculates their entropy to decide whether IFA is happening. The proposed solution can mistakenly consider legitimate traffic as malicious as it relies only on the statistical distribution of Interest names. Furthermore, storing Interest names may consume a lot of resources, especially in the case of a massive attack.

The authors of (Benarfa et al., 2019) presented a solution that relies on Active Queue Management (AQM). For each received Interest, the router randomly picks a pending Interest and matches its name with the received Interest. Then, it compares their source interfaces and checks the satisfaction ratio of the source interface. If it is under a threshold, the router drops both Interests. Otherwise, it drops the received Interest with a probability. However, attackers can timely orchestrate attacks to fill the target’s PIT so the router will start dropping incoming Interests. The authors modified this mechanism to include blocking (Benarfa et al., 2020). When an edge router detect that the PIT occupancy and the satisfaction ratio of an interface are above thresholds, it blocks it. However, legitimate traffic is still penalized by the mechanism and it increases as it gets close to the core network. Similarly, the authors of (Zhi et al., 2020) use a reputation-based early detection mechanism to counter collusive IFA. When an interface’s PIT usage is between the minimum and the maximum thresholds, the router drops incoming Interests with probability. The router defines the minimum and maximum thresholds according to the satisfaction ratio and the average RTT of an interface. The metrics used may lead to dropping a large portion of legitimate Interest, especially in core routers. Similar to the previous two, this solution is a traffic control mechanism, which does not stop attackers. Another solution that aims to counter collusive IFA was proposed in (Nakatsuka et al., 2018). It relies on the fact that malicious traffic is satisfied only by producers, which makes the mean hop count of each received Data

high and its variance low. Hence, edge routers store the hop count of each

Data and calculate the mean and variance of the recorded set. Following these values, the router affirms if a consumer is malicious or not. This solution may lead to mistakenly blocking legitimate users in scenarios where the legitimate requests need to be satisfied by the producer. Being a non-cooperative solution, the proposed solution is unable to detect attacks against routers. Another mechanism against collusive IFA was presented in (Shigeyasu and Sonoda, 2018). Each router monitors its PIT usage. If the rate reaches a threshold, the router examines the number of times the Data was satisfied from the router’s cache. If it equals zero, the router recognizes an ongoing attack. However, attackers can avoid detection since this solution relies on the fact that attackers send Interests with random names. Besides being a detection-only mechanism, it can also lead to false-positive detection in some scenarios (e.g., live streaming).

In (Pu et al., 2019), the authors presented a mechanism that uses a new structure called Operation Trace Table. The router uses it to record the traffic statistics associated with each interface. When the unsatisfaction ratio of an interface is above the average satisfaction ratio, the router reduces the interface’s share and distributes it equally among all interfaces. If the router receives an Interest from an interface that reached its allowed share, it forwards it to another outgoing interface to discover unknown paths. The proposed solution does not mitigate attackers. In addition, sending Interests to other routes may overwhelm upstream links and routers.

Each router in (Chen et al., 2019) randomly selects some prefixes from a recorded list containing calculated metrics for each prefix. Then, it constructs a group of search binary trees from the minimum and maximum values of the selected prefixes. After that, it calculates the average traverse path of chosen prefixes and uses it to calculate an abnormal score for each prefix. Finally, it notifies downstream routers with the malicious prefixes. The namespace-based rate-limiting penalizes legitimate Interest. Besides, the detection process can consume a lot of resources, especially for core routers. Additionally, this technique can take time to detect attacks.

Producer-based solutions Some producer-based reactive solutions were proposed in the literature. The solution proposed in (Zhang et al., 2019) relies on producers’ messages to initiate IFA mitigation. When a producer needs to release its resource, it sends a specific NACK packet to the gateway router. The generated NACK carries essentially the nature of the traffic, fake or valid, and all the fake names received under the affected prefix. When a router receives the NACK, it notifies neighboring routers of the fake names. If an edge router receives a NACK with traffic equal to fake, it blocks the source interfaces for some time. The fake names list used can burden routers in case of massive distributed attacks. Additionally, the proposed technique relies on producers’ feedback to initiate the mitigation process, which leaves routers vulnerable to attacks. To overcome this limitation, The authors of (Benmoussa et al., 2020) proposed a solution that relies on both producers and routers to mitigate IFA. Besides detecting conventional distributed IFA, it also detects distributed IFA where attackers adopt regular sending rates. When a producer is overwhelmed with requests, it sends a signed Interest asking routers to limit forwarding requests to the affected prefix. When received, the router stops forwarding Interests before informing neighboring routers. An edge router classifies a consumer as harmful when it keeps sending requests to the infected prefix and has a low satisfaction ratio along with a high number of timed-out Interests. Although the proposed mechanism can mitigate different types of distributed IFA without affecting legitimate traffic, it still may unintentionally block legitimate consumers.

A new version of (Wang et al., 2013) was proposed in (Liu et al., 2018b). In this solution, a new producer-based monitor mechanism was introduced to reduce the detection delay. When a producer receives a malicious Interest, it responds with a NACK to inform downstream routers. When a router receives the NACK, it checks whether a similar entry exists or not in the m-list. Although it reduces detection delays, this solution still does not stop attackers. Additionally, producers may consider some legitimate requests malicious. Similarly, each router in (Dong et al., 2020) maintains an m-list where it stores the affected prefixes received from producers. When the router receives an Interest, it checks its existence in the m-list. If it matches the information received from the producer, the router forwards the Interest. Otherwise, it drops it. Routers need to process every received Interest, which may consume resources due to hash verification. Also, the m-list can occupy a lot of memory in case of a massive attack with a large number of prefixes. Additionally, routers need to process application-based NACK packets.

Unlike the previous solutions, the mechanism presented in (Wu et al., 2020) mitigates collusive IFA. Routers monitor the interfaces’ throughput and PIT usage during fixed time windows to detect malicious traffic. When these metrics go above their thresholds, the router starts to delete the oldest PIT entries. However, this solution may delete legitimate requests.

7. CDA Workflow: Collect-Detect-Act

In this section, we provide an in-depth analysis of each authored solution. Our comparison depends on the information solutions collect, the metrics and parameters they use during detection, and the actions they take to counter IFA. To this end, we present CDA, which is a workflow that every solution follows. The CDA workflow consists of three activities Collect, Detect and Act as illustrated in Fig. 10.

Figure 10. CDA workflow

7.1. Collect

The first activity of the CDA workflow is Collect. During this activity, solutions collect a set of traffic-related information to detect IFA. The nature of this information varies from one solution to another. Some solutions rely only on router-based information (Afanasyev et al., 2013), (Salah et al., 2015), (Benmoussa et al., 2019), while others rely on producer-based information (Zhang et al., 2019),(Liu et al., 2018b). On the other hand, to detect IFA, some solutions rely on both router-based and producer-based information like (Benmoussa et al., 2020).

7.1.1. Collection parameters

Besides the source of collected traffic, router-based or/and producer-based solutions use a variety of parameters during the collect phase. We conducted a quantitative and qualitative comparison based on the parameters used by existing solutions to collect traffic information. The first column of Table 4 specifies proposed solutions. The next two columns indicate if a solution collects router or/and producer information during this phase. The fourth column shows whether a solution stores or not the collected traffic information. The fifth column provides the routers categories used by a solution. Routers are classified depending on their role in the system. The default value equals one. The following two columns specify whether a solution modifies the PIT and FIB tables. The ”New structure” field indicates if a solution introduces a new data structure. The last column specifies the solutions that rely on a central node during the Collect phase.

width= Ref Router statistics Producer statistics Statistics storage Router classes Modified PIT Modified FIB New structure Central node (Afanasyev et al., 2013) Yes No No 01 Flags: Inqueue, Fwd No No No (Compagno et al., 2013) Yes No No 01 No No No No (Dai et al., 2013) Yes No No 01 No No No No (Wang et al., 2013) Yes No Yes 01 No No Affected prefixes list No (Liu et al., 2018b) Yes Yes Yes 01 No No Affected prefixes list No (Wang et al., 2014b) Yes No Yes 01 No No No No (Wang et al., 2014a) Yes No Yes 01 No Yes No No (Karami and Guerrero-Zapata, 2015) Yes No No 01 No No No No (Zhi et al., 2019) Yes No Yes 01 No No No No (Vassilakis et al., 2015) Yes No No 01 No No No No (Salah et al., 2015), (Salah and Strufe, 2016) Yes No Yes     Monitoring     Normal No No No Yes (Yin et al., 2019) Yes No Yes 01 No No ADT and AIT Yes (Nguyen et al., 2015) Yes No Yes 01 No No No No (Xin et al., 2017) Yes No No 01 No No No No (Shigeyasu and Sonoda, 2018) Yes No Yes 01 No No No No (Ding et al., 2016) Yes No Yes 01 No No Unsatisfied Interests cache No (Xin et al., 2016) Yes No Yes 01 No No No No (Hou et al., 2019) Yes No Yes 01 No No No No (Zhi et al., 2018) Yes No Yes 01 No No No No (Nakatsuka et al., 2018) Yes No Yes 01 No No No No (Benarfa et al., 2019), (Benarfa et al., 2020) Yes No No 01 No No No No (Zhi et al., 2020) Yes No No 01 No No No No (Zhang et al., 2019) Yes Yes Yes 01 No No No No (Pu et al., 2019) Yes No Yes 01 No No Operation Trace Table No (Cheng et al., 2019) Yes No Yes     Monitoring     Normal No No No Yes (Chen et al., 2019) Yes No Yes 01 No No No No (Benmoussa et al., 2019) Yes No No 01 No No No No (Dong et al., 2020) No Yes Yes 01 No No Affected prefixes list No (Tang et al., 2013) Yes No No 01 No No No No (Shinohara et al., 2016) Yes No No 01 No No No No (Benmoussa et al., 2020) Yes Yes No 01 No No No No (Alhisnawi and Ahmadi, 2020) Yes No Yes 01 No No Quotient based Cuckoo filter Yes (Wu et al., 2020) Yes No No 01 No No No No (Tourani et al., 2020) Yes No No 01 No No Bloom filter No (Wang et al., 2017b) No No No 01 No No No No (Zhang and Li, 2019) Yes No No 01 No No No No (Liu et al., 2018a) No No No 01 No No Bloom filter array No Distribution 87% 10% 51% NA 2% 2% 23% 10%

Table 4. Collection parameters used by existing solutions

7.1.2. Key observations of our comparison

The fundamental observations of our comparative study on the information that solutions collect to detect attacks are as follows: The first thing that can be noted from Table 4 is that the majority of authored solutions rely on router information to detect IFA. Routers are the heart of a network. Each connection session passes through a router. That explains the reason of the deployment of the solutions on the routers. It permits gathering a maximum of traffic information, which helps detect ongoing attacks. Routers are favored over producers when deploying solutions, as shown in this study. Producers do not have a global view of a network. They are limited to the communication details that they receive. Solutions that rely only on producers’ information are not efficient to detect attacks against routers. That explains why only one solution chose to counter IFA using session information that producers collect. As NDN uses application-layer names at the network level, routers and producers can cooperate to share information. Some solutions took the hybrid approach. These solutions rely on both routers and producers to gather information. It is the case of three authored solutions.Another key observation regards information storage. Our comparison shows that half of the solutions record connection statistics. Stored information help in detecting attacks with an additional precision level as it implicates the use of more data. It also permits detecting behavioral changes in some cases. However, this process implies using additional storage capacity. In addition, it slows routers at high network peaks, especially those close to the core network. That explains why researchers are divided on the use of information storage. Our comparative study found that only two solutions adopted personalized PIT and FIB tables. Personalized tables occupy more space in memory as they store additional information, and the memory space they occupy grows considerably for core routers. Furthermore, connection processing times increase as routers perform more checks before forwarding packets, which leads to higher network delays. That explains why solutions do not use personalized tables. Nevertheless, solutions may employ a completely new structure, as shown in this comparative study. We notice that almost a quarter of solutions uses a new data structure. They are usually associated with PIT. Using a new data structure comes with a trade-off. It supplies additional information for routers but at the same time occupies more space and introduces processing and computational overhead. Finally, our study shows that some solutions rely on a central node to collect traffic information. They represent 10% of authored solutions. Router classes are mainly associated with centralized solutions. They describe the role that routers occupy in a system. We will discuss centralized solutions further in the next subsection.

7.1.3. Collection metrics

Routers and producers collect a variety of traffic-related statistics. Table 5 summarizes the metrics that existing solutions gather during the Collect phase. The first column of the table specifies proposals. The second column represents the rate of incoming Interest packets of each interface. When the sending rate of an interface reaches a threshold, the router suspects malicious behavior. Solutions usually couple the traffic rate with other metrics. The third column corresponds to the ratio of received Data packets to the total number of requested Interest packets in a given period. Routers/producers calculate the satisfaction ratio of each interface separately. The next column denotes the occupancy ratio of each interface in PIT, i.e., the number of pending Interest packets generated by an interface to the total number of PIT entries. The following four columns of the table show the nature of packets being counted during this phase. Solutions may collect the number of received Interest and Data packets, the number of timed-out pending Interest packets, and the number of NACK packets. The ninth column shows whether a solution stores the name of received Interest packets. The last column of the table shows whether the solution collects producer-based metrics, including but is not limited to processing overhead, memory consumption, and service overload.

width= Router-based metrics Producer-based metrics Ref Satisfaction ratio PIT usage Traffic rate Timed-out Interests Number of Data packets Number of Interests Number of NACK Interest prefixes (Afanasyev et al., 2013) (Compagno et al., 2013) (Dai et al., 2013) (Wang et al., 2013) (Liu et al., 2018b) Malicious Interests (Wang et al., 2014b) (Wang et al., 2014a) (Karami and Guerrero-Zapata, 2015) (Zhi et al., 2019) (Vassilakis et al., 2015) (Salah et al., 2015) (Salah and Strufe, 2016) (Yin et al., 2019) (Nguyen et al., 2015) (Xin et al., 2017) (Shigeyasu and Sonoda, 2018) (Ding et al., 2016) (Xin et al., 2016) (Hou et al., 2019) (Zhi et al., 2018) (Nakatsuka et al., 2018) (Benarfa et al., 2019),(Benarfa et al., 2020) (Zhi et al., 2020) (Zhang et al., 2019) Resource exhaustion (Pu et al., 2019) Unsatisfaction ratio (Cheng et al., 2019) (Chen et al., 2019) (Benmoussa et al., 2019) (Dong et al., 2020) Number of forged Interests (Tang et al., 2013) (Shinohara et al., 2016) (Benmoussa et al., 2020) Resource exhaustion (Alhisnawi and Ahmadi, 2020) (Wu et al., 2020) (Tourani et al., 2020) (Zhang and Li, 2019) (Liu et al., 2018a) Distribution 30% 33% 15% 35% 7% 12% 5% 10% NA

Table 5. Collected metrics by existing solutions

7.1.4. Key observations of our comparison

The key observations of the performed comparative study on metrics used by solutions are as follows: First, we notice that the most used detection metric is the number of timed-out Interest packets. It was used by 35% of existing solutions. Many solutions consider timed-out pending PIT entries as an alarm for an ongoing attack. Attackers usually use non-valid requests to overwhelm networks, and malicious Interests stay in PIT until they time out. That is why solutions usually consider the high number of timed-out Interests as a potential attack. However, this metric may lead to false positives, e.g., non-available producers. Another observation from Table 5 states that the second most frequently used metric is PIT occupancy. The goal of adversary nodes when they perform IFA is to fill the target’s PIT with invalid requests so it cannot accept legitimate Interests. That justifies the use of PIT occupancy as a metric to detect attacks. However, this metric is not reliable in every scenario, as we will see in the next section. Our comparative study found that the satisfaction ratio is the third most used metric with 30% of solutions. Attackers usually perform IFA with invalid requests. That is why solutions consider low satisfaction-ratio levels as a sign of ongoing attacks. We also notice that solutions adopt either the satisfaction ratio or the numbers of timed-out Interest, as they both rely on the fact that the adversary floods the network with invalid requests. However, coupling these two metrics can help reduce false-positive detections that result from the use of the number of timed-out Interest packets. The next most used metric is the traffic rate. It was used by 15% of authored solutions. Adversary nodes send malicious requests at a high pace to overwhelm a network. That is why IFA is usually associated with high traffic rates. We also found that solutions always associate the traffic rate with another metric. Our comparison shows that some solutions count the number of received packets. This includes the number of Interest packets, Data packets, and NACK packets. For instance, we notice that the solutions, which use the number of Interest packets, usually compare it with timed-out Interests. We also remark that the solutions which collect the number of Data packets always compare it with the number of Interests. On the other hand, only two solutions keep statistics of NACK packets. One used it to detect network congestion and the other to exchange information. The last router-based metric of our comparative study regards Interest prefixes. This metric was essentially used by statistical-based solutions. They use this metric to calculate an entropy to detect prefixes under attack. Finally, our last observation regards the number of metrics used by each solution. We found that 39% of authored solutions rely only on one metric, and 34% of solutions use two metrics to detect IFA. It is considered insufficient to detect IFA in different situations. We will discuss this point further in the following sections.

7.2. Detect

The second activity of the CDA workflow is ”Detect”, in which solutions process the collected information to detect anomalies and ongoing attacks. There are two main IFA detection architecture designs, centralized, like (Salah and Strufe, 2016) and (Cheng et al., 2019), and distributed, like (Compagno et al., 2013) and (Dai et al., 2013). Before we detail the detection parameters that solutions may adopt during the Detect phase, we first discuss detection architecture designs. There are two architecture designs: centralized and distributed.

7.2.1. Centralized detection design

The centralized detection architecture relies on a central node to detect an IFA. The central node periodically receives traffic-related information from routers to analyze and decide whether an IFA is happening or not. The centralized detection is further categorized into cluster-based detection, selective nodes detection and global detection.

  1. [label=()]

  2. Cluster-based: The first centralized detection topology is cluster-based centralized detection. The central node groups the network routers into different clusters. The cluster will then collect its traffic information before sending it to the central node. After that, the central node analyzes the received information to detect attacks. When an IFA is detected, it sends back to the clusters the actions to take in order to mitigate the attack. Figure 11(a) illustrates the cluster-based centralized detection. None of the existing solution adopted a cluster-based detection approach.

  3. Selective nodes: The second centralized-based detection topology is using selective nodes. The central node selects a group of routers from the network. The selection criteria are essential to ensure a global view of the network. That is why the central node needs to select the most relevant routers to cover the maximum of the network’s traffic. The selected routers are responsible for sending the information that the central node needs in order to evaluate whether the traffic is malicious or not. This topology is illustrated in Fig. 11(b). After that, the central node sends back to the selected routers the proper actions to take. Solutions (Salah et al., 2015),(Salah and Strufe, 2016), and (Cheng et al., 2019) adopted the selective centralized detection mode.

  4. Global: The third and last centralized-based detection topology is the global topology. Every router in the network is part of the system. That is, every network router collects and sends the information of the traffic passing through it to the central node, as showed in Fig. 11(c). Similar to other centralized detection topologies, the central node analyzes the information that it receives from the network routers before deciding the proper actions to take. The solution presented in (Yin et al., 2019) chose the global centralized approach as its detection mode.

(a) Cluster-based centralized detection
(b) Selective nodes centralized detection
(c) Global nodes centralized detection
Figure 11. Distributed detection architectures

7.2.2. Distributed detection design

  1. [label=()]

  2. Autonomous detection: The first distributed detection approach is the autonomous detection. It means that network routers and data producers collect and detect IFA locally. In this approach, the network nodes do not share traffic or attack information with each other. The majority of existing works adopted the autonomous detection approach like (Benmoussa et al., 2019),(Benarfa et al., 2019), and (Nakatsuka et al., 2018).

  3. Cooperative detection: The second distributed detection approach that the network nodes can adopt is the cooperative detection. Network nodes share traffic-related information and take cooperative actions to mitigate IFA. The cooperative detection is further classified into partial cooperation and full cooperation.

    1. [label=(0)]

    2. Partial cooperation: In a partial cooperation design, the network nodes collaborate only on the mitigation action, like (Afanasyev et al., 2013), (Zhi et al., 2019) and (Benmoussa et al., 2020). Each node analyzes its local traffic to detect an IFA and then takes the proper action to mitigate it. After that, the node informs its neighbors about the action and cooperates to block the attack and stop its growth.

    3. Full cooperation: In a full cooperation distributed detection, the nodes fully cooperate to detect and mitigate IFA, i.e., the nodes share information and jointly decide on the actions to take. Solutions presented in (Liu et al., 2018b) and (Wang et al., 2017b) adopted the full cooperation detection mode.

7.2.3. Detection parameters

Proposed solutions employ multiple parameters to detect attacks. Table 6 details the parameters used by each mechanism. The first column of the table specifies proposals. The second column defines the entities that are responsible for detecting attacks. The following two columns indicate the architecture approach that solutions use to detect IFA, centralized or distributed. Centralized detection may employ the entire routers or just a selection of them. In distributed detection, routers work solemnly or cooperatively to detect attacks. The fifth column shows whether a solution employs AI to detect attacks. The sixth column specifies if a solution considered network congestion when detecting IFA. The ”Check interval” field represents the time that a solution waits for before it performs another detection check. The eight parameters determines the nature of IFA that a solution detect. The following two fields indicate exchanged packets during the Detect phase. The first parameter specifies if a solution introduces a new packet. The second parameter shows whether a solution modifies a packet (essentially an Interest packet). ”The number of thresholds” field represents the set of thresholds that a solution uses to detect attacks. The final parameter shows the categories that a solution uses to classify consumers.

width= Ref Detection actors Centralized detection Distributed detection AI-based Congestion aware Check interval IFA type Specific packets Modified packets Number of thresholds Consumer classes (Afanasyev et al., 2013) All routers No Autonomous No No Non existent No No 01 - (Compagno et al., 2013) All routers No Autonomous No No Non existent No No 02 - (Dai et al., 2013) All routers No Autonomous No No - Non existent No No 01 - (Wang et al., 2013) All routers No Autonomous No No - Non existent No No 01 - (Liu et al., 2018b) All routers Producers No Cooperative No No - Non existent No No 01 - (Wang et al., 2014b) All routers No Cooperative Fuzzy logic No real-time - No No 02 Normal Malicious (Wang et al., 2014a) All routers No Autonomous No No - Non existent No No 02 - (Karami and Guerrero-Zapata, 2015) All routers No Autonomous RBF NN No - All types No No 02 - (Zhi et al., 2019) All routers No Autonomous SVM No time period Non existent No No - - (Vassilakis et al., 2015) Edge routers No Autonomous No No - Non existent No No 02 Legitimate Suspicious Malicious (Salah et al., 2015) Mon routers and DC Selective nodes Autonomous No No Window q Non existent Yes No 02 - (Salah and Strufe, 2016) Mon routers and DC Selective nodes Autonomous No No Window q Collusive Yes No 01 - (Yin et al., 2019) DC Global nodes No No No - Non existent Yes No 02 - (Nguyen et al., 2015) All routers No Autonomous No No - Non existent No No 01 - (Xin et al., 2017) Edge routers No Autonomous No No - Collusive No No 01 - (Shigeyasu and Sonoda, 2018) All routers No Autonomous No No - Collusive No No 02 - (Ding et al., 2016) Edge routers No Autonomous No No Windows L Non existent No Interest state and router ID 01 - (Xin et al., 2016) All routers No Autonomous No No - Non existent No No 01 - (Hou et al., 2019) All routers No Autonomous No No - Non existent No No 01 - (Zhi et al., 2018) All routers No Autonomous No No Time Non existent No No 01 - (Nakatsuka et al., 2018) Edge routers No Autonomous No No Time window Existent No No 02 - (Benarfa et al., 2019), (Benarfa et al., 2020) All routers No Autonomous No No - Non existent No No 03 - (Zhi et al., 2020) All routers No Autonomous No No - Collusive No No 02 - (Zhang et al., 2019) Producers No Autonomous No No - All types No No Producer based Normal Suspicious (Pu et al., 2019) Edge routers No Autonomous No No Window Non existent No No 01 - (Cheng et al., 2019) Mon routers DC Selective nodes No No No - Non existent Yes No 03 - (Chen et al., 2019) All routers No Autonomous No No time interval Non existent No No 02 - (Benmoussa et al., 2019) Edge routers No Autonomous No Yes - Non existent No No 04 Legitimate Suspicious Malicious (Dong et al., 2020) Producers No Autonomous No No - Non existent No No Producer based - (Tang et al., 2013) All routers No Autonomous No No - Non existent No No 02 - (Shinohara et al., 2016) All routers No Autonomous No No - Non existent No No 02 - (Benmoussa et al., 2020) All routers Producers No Cooperative No No - All types No No 03 Normal Suspicious Harmful (Alhisnawi and Ahmadi, 2020) All routers No Cooperative No No - Non-existent No No 02 - (Wu et al., 2020) All routers No Autonomous No No Time window Collusive No No 02 - (Tourani et al., 2020) Core routers No Autonomous No No - Non existent No No 01 - (Wang et al., 2017b) All routers No Cooperative No No - All types No PIT delay&  content fees - - (Zhang and Li, 2019) Edge routers No Autonomous No No - Non existent No No - Legal Bad (Liu et al., 2018a) All nodes No Autonomous No No - Non existent No No - - Distribution NA 10% NA 7% 2% NA NA 10% 5% NA NA

Table 6. Detection parameters used by existing solutions

7.2.4. Key observations of our comparison

The key observations of our comparative study on the parameters that solution use during the detection phase are as follows: First, we found that 89% of solutions use routers as the detection actor. It includes both router-based and hybrid solutions. This number was predictable, as we previously noticed, in Table 4, that the majority of solutions rely on routers’ information. We also observed that all centralized solutions rely on the central node to decide whether IFA exists or not. Second, we notice that 94% of authored solutions adopted the distributed detection design, and only 10% chose the centralized architecture. Centralized solutions require additional deployment phases. It implies the exchange of control information with system nodes. Additionally, deployment complexity grows, as the network gets bigger. Furthermore, the traffic information that system nodes send to the central node may burden the network, especially in large deployments. That explains why a small portion of existing countermeasure solutions adopted the centralized architecture. Nevertheless, we found that two solutions chose a hybrid approach to detect IFA. Another key observation regards the use of AI to detect IFA. Although it can help increase detection precision and reduce false positives, only 10% of authored solutions used an AI-based algorithm. AI-based solutions require additional computational and memory resources, which may penalize some nodes. That explains why researchers usually do not choose to rely on AI. Our comparative study found that most proposals are solutions against the third type of IFA. As discussed earlier, it represents the most harmful IFA type, as it implies the use of invalid requests. The first type of IFA, which uses valid requests, causes less harm compared to the third type. That explains why 80% of solutions chose to counter IFA with non-existent content, and only one was authored for the first type. However, some solutions counter both types. It is the case of 10% of solutions. These solutions usually rely on both router-based and producer-based information to detect attacks. On the other hand, solutions against collusive IFA represent only 13%. It shows that the research community did not study in detail this IFA variant. Our last observation from this comparative study points to control packets that solutions exchange during detection. Solutions adopted two approaches: the first one implies the creation of new specific packets. This approach was exclusively used by centralized solutions. The second approach consists of sending control information within exchanged Interest packets. It modifies Interest packets, usually their name, to include additional information for neighboring routers. Using control packets may introduce delays to the network, as routers need to process them. Solutions that rely on control packets during detection represents 15% of the overall solutions.

7.3. Act

The last activity of the CDA workflow is ”Act”. After collecting the traffic related information, and detecting the existence on an IFA, solutions act by taking mitigation actions to stop the attack. Table 7 summarizes the mitigation parameters used by existing solutions. Before we detail the mitigation actions that solutions use to stop attacks, we first discuss the mitigation parameters that solutions may employ during this phase.

7.3.1. Mitigation parameters

Table 7 lists the parameters that solutions may use during the mitigation process. The first column specifies proposals. The second column corresponds to the way a solution work to mitigate attackers, autonomous or cooperative. System nodes may cooperate or work independently to stop IFA. The third column specifies the nodes that take the action against attacks. The following field represents the action that a solution adopts to counter IFA. Mitigation actions are detailed in the following subsection. The next two columns indicate whether a solution uses special packets during the mitigation process. The ”Control information” field lists the information that a solution shares during the mitigation process. The last column specifies whether a solution uses signed Interest packets or not.

7.3.2. Router-based mitigation actions

  1. [label=()]

  2. Rate-limiting: The first mitigation action that routers usually take after detecting an IFA is rate limiting. It consists of reducing the amount of traffic allowed from a given interface. When a router detects a malicious traffic, it first checks the source interface of this traffic. Following this, the router reduces the incoming traffic from this interface. The router may apply rate-limiting on the whole interface’s traffic or just for a given namespace. The vast majority of existing IFA countermeasure solution act by limiting the rate of incoming traffic.

  3. Block: The second router-based mitigation action consists of blocking the traffic of an interface. The network router, when necessary, can block an interface for a period. The blocking action is usually considered as a second-level reaction. When rate limiting does not suffice to throttle an attack, the router considers blocking the interface for a period. Interface blocking is particularly used by edge routers. The blocking periods may vary during time. Routers could increase the blocking period when the previous amount of time did not help to stop the attack. Blocking actions could be prefix-based (i.e., applied on a specific prefix) as used in (Tang et al., 2013) and (Zhi et al., 2019), or on interface-base (i.e., block all traffic of an interface) as used in (Benmoussa et al., 2019) and (Hou et al., 2019).

7.3.3. Producer-based mitigation actions

The producer-based mitigation actions are essentially associated with blocking. Data producers, when needed, may block the incoming network traffic. Producer-based blocking action can be temporary or permanent.

  1. [label=()]

  2. Temporary block: Temporary blocking consists of blocking the network traffic for a limited period. To throttle attacks, data producers use temporary blocking against malicious traffic. The blocked traffic could be the whole traffic of an interface or just a portion of the traffic (e.g., the network traffic heading to a particular service) as used in (Benmoussa et al., 2020).

  3. Permanent block: Data producers may also use permanent blocking against consumers. Producers can implement a security policy to permanently block consumers when needed (i.e., blacklisting consumers). Producers do not use permanent block against network interfaces.

width= Ref Mitigation method Mitigation actors Mitigation actions Specific packets Specific namespace Control information Signed Interests (Afanasyev et al., 2013) Autonomous All routers Rate-limit No No No No (Afanasyev et al., 2013) Cooperative All routers Rate-limit Yes - Rate limit announcements No (Compagno et al., 2013) Cooperative All routers Rate-limit Yes /pushback/alerts/ Reduced rate No (Dai et al., 2013) Cooperative All routers Rate-limit Yes No Spoofed Data No (Wang et al., 2013) Cooperative All routers Forwards Interest without using PIT Yes No Interfaces list No (Liu et al., 2018b) Cooperative All routers Producers Sends Nack Yes No Malicious Interest No (Wang et al., 2014b) Cooperative Edge routers Rate-limit (prefix) Yes /ALERT/IFA/ Malicious prefix No (Wang et al., 2014a) Autonomous All routers Rate-limit (prefix) No No No No (Karami and Guerrero-Zapata, 2015) Cooperative All routers Rate-limit Yes /pushbackmessage/alert/ Reduced rate No (Zhi et al., 2019) Cooperative All routers Block (prefix) Yes Empty Malicious prefixes No (Vassilakis et al., 2015) Autonomous Edge routers Rate-limit Block Yes - Blocked user No (Salah et al., 2015), (Salah and Strufe, 2016) Cooperative Mon routers Rate-limit (prefix) Yes - Infected prefixes No (Yin et al., 2019) Cooperative Edge routers Block Yes /CTRL/ Malicious prefixes No (Ding et al., 2016) Cooperative All routers Rate-limit (prefix) No No No No (Xin et al., 2016) Cooperative All routers Rate-limit Yes No Spoofed Data No (Hou et al., 2019) Cooperative All routers Block Yes No Spoofed Data No (Zhi et al., 2018) Cooperative All routers Rate-limit (prefix) Yes No Malicious prefix No (Nakatsuka et al., 2018) Autonomous Edge routers Block No No No No (Benarfa et al., 2019) Autonomous All routers Rate-limit No No No No (Zhi et al., 2020) Autonomous All routers Rate-limit No No No No (Benarfa et al., 2020) Autonomous Edge routers Rate-limit Block No No No No (Zhang et al., 2019) Cooperative All routers Producers Rate-limit Block Yes No RSN, PREF, C FakeList No (Pu et al., 2019) Autonomous Edge routers Rate-limit No No No No (Cheng et al., 2019) Cooperative Edge routers Block Yes /ndn/ddos/flooding/ Interfaces list Yes (Chen et al., 2019) Cooperative All routers Rate-limit (prefix) Yes - Malcious prefix No (Benmoussa et al., 2019) Autonomous Edge routers Block No No No No (Dong et al., 2020) Cooperative All routers Producers Rate-limit Yes No Affected prefixes No (Tang et al., 2013) Autonomous All routers Block (prefix) No No No No (Shinohara et al., 2016) Autonomous All routers Rate-limit No No No No (Benmoussa et al., 2020) Cooperative Edge routers Rate-limit (prefix) and Block Yes /ndn/PCIP /ndn/RCIP Affected prefix Yes (Alhisnawi and Ahmadi, 2020) Cooperative Edge routers Rate-limit Yes No No (Wu et al., 2020) Autonomous All routers Delete Interests No No No No (Tourani et al., 2020) Autonomous Core routers Bloom filter No No No No (Wang et al., 2017b) Cooperative All routers Rate-limit Yes No Insufficient fees No (Zhang and Li, 2019) Autonomous Edge routers Rate-limit No No No No (Liu et al., 2018a) Autonomous All nodes Rate-limit No No No No

Table 7. Mitigation parameters used by existing solutions

7.3.4. Key observations of our comparison

The fundamental observations of our comparative study on mitigation parameters are as follows: We first note that the number of solutions that cooperate to mitigate attacks represents 54%. The number may seem low as cooperation helps to better contain attacks, especially in the case of distributed IFA. However, cooperation implies a pre-configuration phase and the exchange of solution-based information. Scalability is also a challenge for cooperative solutions, especially in large deployments compared to the autonomous approach. We also notice from our comparison that autonomous mitigation is usually associated with edge routers, and solutions that employ core routers are always cooperative. The next observation regards the actions that authored solutions chose to mitigate attacks. Our study found that 66% of them apply rate-limiting. Countermeasure solutions chose this action for two reasons: (1) When applied on a core interface, it does not stop all the traffic. (2) Avoid penalizing legitimate consumers connected to edge routers after behavioral changes. (3) Avoid penalizing the traffic of a specific producer in case of prefix-based rate limiting. Routers usually employ rate limiting for a period. On the other hand, 29% of proposals adopted blocking as a mitigation action. We first notice that interface-based blocking is always associated with edge routers, which is understandable. Core routers do not block the whole interface’s traffic. However, all routers adopted prefix-based blocking. Our comparative study found that cooperative solutions employ control packets during mitigation. Solutions use them to exchange information. We found that the most shared information regards rate limiting. Routers, especially core routers, inform neighboring nodes after the application of traffic limitation. Some solutions also send the applied rate. The second most shared information within cooperative solutions is the affected/malicious prefix. It is associated with prefix-based actions. Routers use this information to ask other routers to limit/stop forwarding packets to that prefix. Our last observation regards the nature of packets used by cooperative solutions to share information. System nodes usually use Interest packets to exchange information between them. However, we discovered that only 14% of countermeasure solutions used signed Interest packets to share information, which is very low. Using non-signed Interest packets constitutes a threat to the reliability of a solution, as we will see in the following section.

8. Unconsidered IFA Scenarios

All existing IFA solutions may lack the detection of attacks in some particular scenarios, which attackers can take advantage of to flood the network and/or penalize legitimate consumers. In this section, we present and explain several unconsidered IFA scenarios.

8.1. Attacking scenarios against non cooperative solutions

This subsection groups several attacking scenarios that target non cooperative IFA solutions.

8.1.1. Targeting neighboring consumers in non-cooperative solutions

Targeting neighboring consumers in non-cooperative solutions. The attacking scenario illustrated in Fig. 12(a) shows how an attacker could take advantage of a non-cooperative solution to affect legitimate consumers. In this scenario, Router R1 takes a defensive action against its interfaces int1 and int2 because they reached their respective thresholds due to the malicious traffic. As a result, Router R1 will penalize legitimate consumers connected to Router R2 and those behind the switch.

8.1.2. Targeting distant consumers in non-cooperative solutions

Similarly, the scenario in Fig. 12(b) shows that attackers can also affect a distant legitimate consumer in a case of a non-cooperative solution. In this scenario, The router R2 applied rate limiting on its interface int2 in response to the malicious generated by the attacker, which lead to affecting the legitimate consumers. The attacker was able to penalize the distant consumer1 and consumer2.

(a) Attacking scenario against neighboring consumers in non-cooperative solutions
(b) Attacking scenario against distant consumers in non-cooperative solutions
Figure 12. IFA Scenarios against non-cooperative solutions

8.2. Attacking scenarios against cooperative solutions

This subsection groups several attacking scenarios that target cooperative IFA solutions.

8.2.1. Countering alert-based solutions with a compromised edge router

This attacking scenario counters solutions that rely on edge routers to stop attackers (e.i., edge routers are the only mitigation actors). Attackers can get around by taking control of the edge router that they are connected to. Adversary nodes will have the ability to continue flooding the network because the edge router will ignore all received solution-based alerts, as shown in 13(a). Routers could reduce the impact of the attack when they take defensive actions. However, in a solution where the edge router is the only mitigation actor, attackers will continue flooding the network.

8.2.2. Targeting legitimate consumers with alert messages

Some IFA solutions use alert messages to exchange information and action decisions. Attackers could take advantage of this feature to target legitimate consumers as shown in Fig. 13(b). In this scenario, the attacker forges an alert message and sends it to Router R2 to push it to take defensive action against the legitimate consumers connected to it. The attacker can conduct such attacks only if the solution uses non-signed alert messages.

8.2.3. Targeting routers resources with forged alert messages

Another way of using solution-based alert messages is to target routers’ resources. As shown in Fig. 13(c), the attacker continually sends forged alert messages to Router R2 to stress it with signature verification and leads it to computation overhead.

(a) Countering alert-based solutions with a compromised edge router
(b) Attacking scenario against legitimate consumers with alert message
(c) Targeting routers with forged alert messages
Figure 13. IFA scenarios against alert messages based solutions

8.2.4. Targeting routers resources with forged NACK packets

Similar to the previous scenario, attackers can also lunch attacks against routers that rely on NACK packets to send solution-based messages like (Liu et al., 2018b; Dong et al., 2020). To do so, attackers flood the targeted router with forged NACK packets to penalize him with computation overhead due to signature verification. Figure 14(a) illustrates this attacking scenario.

8.2.5. Flooding the network with solution-based spoofed Data packets

Some solutions like (Dai et al., 2013) use spoofed Data packets to counter malicious nodes. Attackers can take advantage of this feature to flood the network as shown in Fig. 14(b). In this scenario, the attackers who are in control of the edge router flood the network with forged Interest packets. Router R1 sends back spoofed Data packets to edge Router R3 to stop adversary nodes. Router R3 will take no action against the malicious nodes as it is controlled.

(a) Targeting routers with forged NACK packets
(b) Flooding the network with solution-based spoofed Data packets
Figure 14. IFA scenarios with forged packets

8.2.6. Countering prefix-based solutions

As mitigation action, some solutions like (Tang et al., 2013; Chen et al., 2019) apply rate-limiting or blocking on name prefixes that routers consider as malicious or under attack. However, attackers can easily overcome this restriction by changing the prefix of forged Interest packets to keep flooding the network, as shown in Fig. 15(a).

8.2.7. Affecting legitimate traffic in prefix-based solutions

Another attacking scenario against prefix-based solutions is illustrated in Fig. 15(b). The goal of the attacker in this scenario is to affect legitimate traffic heading to a specific producer. To do so, the attacker flood the network with forged Interest packets with the targeted prefix to push routers to take defensive actions against this prefix, which penalizes also legitimate traffic.

(a) Targeting prefix-based solutions
(b) Targeting legitimate traffic in prefix-based solutions
Figure 15. IFA scenarios against prefix-based solutions

8.2.8. Targeting the network with a distributed collusive attack

Figure 16(a) illustrates a scenario of a distributed collusive attack. Compared to the collusive attack presented in the literature, in this scenario, attackers work with a distributed group of malicious producers to overwhelm the network. Additionally, adversary nodes send with regular rates. Existing solutions rely on metrics like PIT usage and traffic rate, which are linked to the aggressive nature of adversary nodes. That makes it difficult for existing solutions to detect this attacking scenario. Because of its distributed nature, this attacking scenario generates high traffic and introduces important delays to the network even with regular sending rates.

8.2.9. Targeting the network with a low-rate distributed collusive attack

Another variant of the distributed collusive attack is the low-rate distributed collusive IFA. In this scenario, a large distributed number of attackers or infected bots request Data packets from malicious producers with low sending rates, as shown in Fig. 16(b). Similar to the previous scenario, existing collusive solutions rely on high traffic metrics to detect collusive attacks. It makes them inefficient against this attacking scenario.

(a) Targeting the network with a distributed collusive attack
(b) Targeting the network with a low-rate distributed collusive attack
Figure 16. Distributed collusive IFA scenarios

8.2.10. Targeting the network with low-rate distributed IFA

The attacking scenario depicted in 17(a) represent a distributed IFA with low sending rate. This attacking solution works with all solutions that use the traffic rate and PIT usage as detection metrics. Attacker overcome these solution by adopting a low sending rate to keep flooding the network with malicious Interest packets.

8.2.11. Targeting the network with low-rate and mixed distributed IFA

An even more hard-to-detect attacking scenario than the previous one is illustrated in 17(b). In these particular scenarios attackers and controlled nodes flood the network with valid and invalid Interest packets. This permits to attacker to counter other detection metrics like the satisfaction ratio and timed-out Interest packets.

(a) Targeting the network with low-rate distributed IFA
(b) Targeting the network with low-rate mixed distributed IFA
Figure 17. Low-rate distributed IFA scenarios

8.2.12. Scenario of a Smart IFA

In this scenario, attackers adopt a smart behaviour when launching IFA to avoid mitigation and keep flooding the network. The adversary nodes cooperate by sending malicious traffic one after another. The goal of attackers is to keep flooding the network in case an attacker gets mitigated. Another more sophisticated scenario is when an attacker keeps sending forged Interest packets and before reaching solution’s thresholds it stops and another attacker continue the attack. This attacking scenarios could be local as showed in Fig. 18(a) or distributed as illustrated in Fig. 18(b).

(a) Local IFA: case of smartly behaving attackers
(b) Distributed IFA: case of smartly behaving attackers
Figure 18. Smart IFA Scenarios

9. Lessons Learned and Future Directions

In this survey, we reviewed the literature on IFA depending on the information they collect, the metrics and parameters they use, and the actions they take. Based on our analysis, we found that IFA still represents a threat to NDN networks. The research community needs to conduct significant work to cover all its aspects. In this section, we list the key lessons learned and highlight research directions.

9.1. Lessons Learned

In the following, we list the fundamental lessons learned from this survey that could potentially help security researchers:

  1. Start by considering other IFA variants instead of conventional scenarios. Existing works generally focus on a specific type of IFA. However, as outlined in section 8, multiple IFA scenarios are still untreated by state-of-the-art works. Solutions need to widen their field of action and go off the beaten path to cover the full spectrum of the attack.

  2. Consider additional parameters to enhance the detection accuracy. As stated in this survey, existing solutions may classify legitimate requests as malicious, which leads to penalizing honest consumers. To this end, solutions need to consider additional parameters and proprieties during the detection process.

  3. Rethink the solution’s algorithm to adapt to behavioral changes. As outlined in Sec. 8, existing solutions are incapable of detecting attackers when they adopt different behaviors from those expected by the algorithm.

9.2. Future Research Directions

Accurate detection, embedded security, and autonomous adaptation are some of the research goals that need to be achieved while designing IFA solutions. In the following, we outline potential research directions:

  • Accurate detection and mitigation - Many effective countermeasure solutions are available. However, authored solutions are explicit and generally detect specific attacking scenarios. Additionally, these solutions cannot even stop the scenario that they are intended to detect when some conditions change, which leads to flooding the network with malicious traffic. In addition, false-positive rates are tightly linked to detection conditions, which leads to unfairly blocking consumers and their legitimate traffic, as shown in Sec.8. Newly designed solutions need to be more reliable. They need to revisit detection parameters and adopt intelligent approaches to cope with different IFA scenarios. For example, broad cooperation between network nodes could be considered, and concepts like federated learning and hybrid-based solutions could be of help.

  • Embedded security mechanisms - This research pathway suggests that solutions should embed security mechanisms to ensure reliable and undisrupted interconnectivity. The following prerequisites need to be part of a designed solution: (1) The solution-based information that nodes exchange needs to be securely validated and verified. (2) The solution needs to guarantee a secure and reliable transmission mechanism to ensure the integrity and authenticity of this information. (3) The solution needs to implement trust policies between participating entities. The implementation of these requirements will ensure a healthy environment among system nodes.

  • Autonomous adaptation - The existing solutions can face a stable attacking scenario. However, an intelligent attacker can alter between legitimate and malicious behavior to avoid detection. Hence, this research direction recommends that newly designed solutions should be able to autonomously adapt to different situations, including the intelligent attacker scenarios. Additionally, solutions need to adapt their parameters following network situations, especially in high traffic peaks.

  • Hybrid approaches - The following research pathway proposes to use hybrid solutions to detect and mitigate IFA. For example, a router may combine two solutions: one for conventional situations, in which it applies predefined rules, and another for non-conventional situations to detect behavioral changes. Another example of a hybrid approach consists of a modular solution. In this hybrid approach, tasks are distributed among the nodes of a system. Each node represents a module of the solution. Nevertheless, implementing hybrid solutions is challenging. It requires coordination between system nodes, which rises interoperability concerns. Another challenge consists of finding a balance between performance and resource consumption.

  • Deployment-friendly - Another aspect of a reliable IFA solution relies on its deployment. Newly designed solutions need to be able to scale at any level without affecting the overall system. Additionally, solutions need to offer easy deployment mechanisms for recently added nodes without adding significant load on nodes’ resources. A solution, as good as it is, needs to have a minimum impact on a device’s resources so it can work smoothly even in cases of high traffic peaks. Newly designed solutions need to have a low resource consumption fingerprint so attackers cannot take advantage of it to take down network nodes.

10. Conclusion

Many solutions were authored since the proposal of the first IFA countermeasure mechanism. However, the proposed mechanisms still do not cover the full spectrum of potential IFAs. This survey broadly discussed IFA. Following that, it detailed, classified and compared the state-of-the-art solutions. After that, the survey discussed open issues through the presentation and analysis of several non-conventional attacking scenarios that were not considered before. Finally, the survey discussed the lessons learned and research directions by providing the requirements for a more robust and efficient IFA solution.

11. Appendix

In this section, we compare existing IFA solutions in terms of the parameters used during the simulation process, along with the evaluation metrics used to validate the proposed solution.

11.1. Simulation Parameters

In this subsection, we list and explain all the simulation parameters used to evaluate the proposed solutions. Table 8 summarizes the simulation environment adopted by the existing IFA solutions.

  • Simulator: The most common simulator used to evaluate IFA solutions is the NDN network simulator (ndnSIM) (Mastorakis et al., 2017)

    . ndnSIM is an open-source network simulator based on ns-3 and designed to conduct NDN based simulation studies. Some solutions evaluated their work using Matlab. On the other, one existing IFA solution was evaluated using OMNeT++, which is another network simulator.

  • Network topology: Several network topologies were used by existing works during the evaluation part. The most commonly used topologies are the Rocketfuel topologies(Spring et al., 2002).

  • Links bandwidth: This metric represents the bandwidth chosen for the links during the simulation.

  • Network delay: It represents the network delay values chosen for during the evaluation.

  • Forwarding strategy: It shows the strategy adopted by routers to forward interest packets.

  • Dishonesty ratio: This metric equals the number of malicious nodes deployed during the simulation to the total number of nodes.

  • Number of producers: It represents the number of producers deployed in the network.

  • Rate of consumers: This parameters equals the frequency at which legitimate consumers send interest packets.

  • Rate of attackers: It represents the number of malicious interest packets sent by attacker in a period.

  • Nature of malicious interest: it shows the nature of interest packets used by malicious nodes during the attack.

  • PIT size: This parameter denotes the size of routers PIT adopted during the simulations. It is represented in memory size or number of entries.

  • Interest lifetime: It represent the value of the InterestLifetime field chosen for the evaluation.

  • Intermediate Cache: This simulation parameter states whether or not routers use the local CS to satisfy incoming interest packets.

  • CS size: Equals the capacity of a router’s CS in terms of the number of entries (i.e., data) that it supports.

  • CS strategy: This parameter represents the cache replacement strategy adopted by routers.

  • Data size: It represents the size of the Data packet chosen during the simulation.

width= Ref Simulator Network topology Links bandwidth Network delay Forwarding strategy Dishonesty ratio Number of producers Rate of consumers Rate of attackers Nature of malicious interest PIT size Interest lifetime Intermediate Cache CS size CS strategy Data size (Afanasyev et al., 2013) ndnSIM Binary tree Rocketfuels AS 7018 10Mbps - 01 - - Non-existent - - No - - 1100Bytes (Compagno et al., 2013) ndnSIM Rocketfuel AS 7018 - - - 01 30ipps 01int/min Non-existent 120KB - - - - (Dai et al., 2013) - Rocketfuel AS 1755 - - - - 01 - 1000ipps Non-existent - - - - - (Vassilakis et al., 2015) ndnSIM Random - - - - 20ipps 1000ipps Non-existent - - - - 1KB (Wang et al., 2014b) ndnSIM Rocketfuel AS 7018 1-100Mbps Best route 01 20ipps 400ipps Non-existent 100 entries Yes 500 entries LRU 1KB (Salah et al., 2015) ndnSIM Rocketfuel AS 3967 - - - - - 500- 10000ipps Non-existent 5000 entries - No - - 1100Bytes (Salah and Strufe, 2016) ndnSIM Rocketfuel AS 3257 - - - 01 malicious 100ipps 200- 5000ipps Non-existent 5000 entries No - - 1100Bytes (Wang et al., 2013) ndnSIM Rocketfuel AS 7018 1-100Mbps Best route 01 10-1000ipps 100ipps Non-existent Unlimited - Yes 500 entries LRU 1KB (Wang et al., 2014a) Matlab - - - - - - Poisson distribution Poisson distribution Non-existent - - - - - - (Karami and Guerrero-Zapata, 2015) ndnSIM Matlab DFN-like Rocketfuel AS 7018 - - - 02-05 100-600ipps 400- 3000ipps Existent and non-existent - - - - - - (Ding et al., 2016) ndnSIM Small tree Rocketfuel AS 7018 1-100Mbps - 01 67-1000ipps 2000- 20000ipps Non-existent 10000 entries No - - - (Nguyen et al., 2015) ndnSIM Matlab Binary tree - - - - 01 Poisson distribution - - - - - - - - (Xin et al., 2017) ndnSIM China Telecom - - - 01 50ipps Random distribution - 200 entries No - - - (Xin et al., 2016) ndnSIM Small tree 100Mbps Best route 01 200ipps 20ipps Non-existent 50 entries No - - 1KB (Zhi et al., 2018) ndnSIM Small tree - - - 01 50ipps 100ipps Non-existent 200 entries - - - - (Nakatsuka et al., 2018) ndnSIM Rocketfuel AS 1221 1-100Mbps - 10 100ipps 100ipps Existent - - - - - 1KB (Benarfa et al., 2019),(Benarfa et al., 2020) ndnSIM Small topology Rocketfuel AS 7018 - - - 01 30ipps 100- 10000ipps Non-existent 600KB - - - - - (Zhang et al., 2019) ndnSIM Meshed topology - - - 01 40ipps 100- 6000ipps Existent and non-existent - - Yes 200 entries - - (Hou et al., 2019) ndnSIM Binary tree - - - 01 200ipps 1000- 2000ipps - 50 entries - - - - (Pu et al., 2019) OMNeT++ Small tree - - - - - - - - - - - - - - (Zhang and Li, 2019) ndnSIM Small Tree Large network - - - 01 - - - - - - - - - (Alston and Refaei, 2016) - Internet- like 300Mbps - - - 5ipps - - - - - - - 500Bytes (Cheng et al., 2019) ndnSIM Modified Rocketfuel AS 7018 - Best route 01 40ipps 13ipps then higher Existent 2000 entries - - - 1100Bytes (Liu et al., 2018b) ndnSIM GEANT 155Mbps- 20Gbps Best route 01 250ipps 200ipps - - - Yes 1000 entries - 4KB (Liu et al., 2018a) - GEANT 100Mbps- 20Gbps - - 01 20ipps 200ipps - - - - - - 4KB (Chen et al., 2019) - Binary tree - - - 01 100ipps 2000ipps Non-existent 300 entries - - - - (Zhi et al., 2019) ndnSIM Binary tree 10Mbps - 01 500ipps 100ipps Non-existent 200 entries - - - - (Yin et al., 2019) ndnSIM Binary tree Small topology - - 02 5-10ipps 100ipps Non-existent 100 entries - - - - - (Wang et al., 2019) Matlab Rocketfuel AS 7018 1-100Mbps - - - - - - - - - - - - (Benmoussa et al., 2019) ndnSIM 25 nodes topology 1-100Mbps Best route 09 100- 500ipps 10000ipps Non-existent - - Yes 100 entries LRU 1KB (Dong et al., 2020) - Small topology 100Mbps- 1Gbps - 01 100ipps 1000ipps Non-existent - - - - - (Zhi et al., 2020) ndnSIM 25 nodes topology 1-100Mbps - - 500ipps 500- 2000ipps - 100 entries - - - 512Bytes (Shinohara et al., 2016) ndnSIM Binary tree 10Mbps - 01 1000ipps 10000ipps Non-existent 275 entries - - - - (Shigeyasu and Sonoda, 2018) - 12 nodes topology 1Mbps - 02 10ipps 320- 2030ipps Non-existent 50 entries - Yes 10 entries FIFO 1KB (Tang et al., 2013) ndnSIM 100-to-1 topology 10Mbps - 01 200ipps 200ipps Non-existent Unlimited - - - - (Benmoussa et al., 2020) ndnSIM 18 nodes topology 10Mbps- 1Gbps Best route 03 100ipps 1500ipps- 10000ipps Existent and non-existent Unlimited - Yes 100 entries LRU 1KB

Table 8. Simulation Parameters

11.2. Evaluation Metrics

In this subsection, we detail all the evaluation metrics used by existing IFA works to validate the proposed solutions. Table 9 summarizes the evaluation metrics used by each existing solution.

  • Satisfaction ratio: It equals the number of Data packet returned to the total number of interest packets issued.

  • PIT usage: This metric is also called PIT occupancy. The PIT usage of an interface represents the number of pending Interest packets sourced by this interface to the total capacity of the PIT.

  • Number of PIT entries: This metric represents the number of pending PIT entries of an interface. Some solution use this metric to detect abnormal traffics. This metric is compared to the usual activity of an interface to detect a malicious traffic.

  • Number of Interest packets: Unlike the number of PIT entries metric, which includes only pending Interests, this metric represents the total number of Interest packets issued by an interface.

  • Number of Data packets: It represents the total number of Data packets received by an interface in a period.

  • Number of satisfied Interest packets: It represents the total number of Interest packets that resulted in a Data packet.

  • Number of dropped packets: This metric represents the total number of dropped packet recorded for a given interface.

  • Number of timed-out Interest packets: It represents the number of timed-out Interest packet of a given interface. An Interest packet times-out when its InterestLifetime reaches zero before a response comes back.

  • Number of NACK packets: Represents the number of NACK packets recorded by a router for one or all its interfaces.

  • Traffic rate: As already defined, traffic rate on an interface equals the frequency of incoming Interest packets.

  • Interest drop rate: This metric represents the number of dropped Interest packets, due to PIT saturation, to the total number of Interest packets issued (by an interface) or received by a router.

  • Delay: It represents the time that takes an Interest packet to reach a destination.

  • False positive ratio: This metric represents the number of wrongly classified events as malicious to the total number of events recorded.

width= Ref Satisfaction ratio PIT usage # of PIT entries # of Interests # of Data # of satisfied Interests Dropped packets # of timed-out Interests # of NACK packets Traffic rate Interests drop ratio Delay False positive ratio (Afanasyev et al., 2013) (Compagno et al., 2013) (Dai et al., 2013) (Vassilakis et al., 2015) (Wang et al., 2014b) (Salah et al., 2015),(Salah and Strufe, 2016) (Wang et al., 2013) (Wang et al., 2014a) (Karami and Guerrero-Zapata, 2015) (Ding et al., 2016) (Xin et al., 2017) (Xin et al., 2016) (Zhi et al., 2018) (Nakatsuka et al., 2018) (Benarfa et al., 2019), (Benarfa et al., 2020) (Zhang et al., 2019) (Hou et al., 2019) (Pu et al., 2019) (Zhang and Li, 2019) (Alston and Refaei, 2016) (Cheng et al., 2019) (Liu et al., 2018b) (Liu et al., 2018a) (Chen et al., 2019) (Zhi et al., 2019) (Yin et al., 2019) (Benmoussa et al., 2019) (Zhi et al., 2020) (Shinohara et al., 2016) (Shigeyasu and Sonoda, 2018) (Shigeyasu and Sonoda, 2018) (Benmoussa et al., 2020)

Table 9. Simulation Evaluation Metrics

Acknowledgments

This work is partially supported by National Science Foundation awards CNS-2104700, CNS-2016714, and CBET-2124918, the National Institutes of Health (NIGMS/P20GM109090), the Nebraska University Collaboration Initiative, and the Nebraska Tobacco Settlement Biomedical Research Development Funds.

References

  • [1] (Cisco Visual Networking Index: Forecast and Trends 2018–2023)(Website) External Links: Link Cited by: §1.
  • [2] (NDN Data packet)(Website) External Links: Link Cited by: §2.2.2.
  • [3] (NDN Packet Format Specification version 0.3)(Website) External Links: Link Cited by: §2.2.1.
  • [4] (Signed Interest Packet)(Website) External Links: Link Cited by: §2.2.1.
  • M. Aamir and S. M. A. Zaidi (2015) Denial-of-service in content centric (named data) networking: a tutorial and state-of-the-art survey. Security and Communication Networks 8 (11), pp. 2037–2059. Cited by: §1.1, Table 1.
  • E. G. AbdAllah, H. S. Hassanein, and M. Zulkernine (2015) A survey of security attacks in information-centric networking. IEEE Communications Surveys & Tutorials 17 (3), pp. 1441–1454. Cited by: §1.1, Table 1.
  • H. B. Abraham and P. Crowley (2017) Controlling strategy retransmissions in named data networking. In 2017 ACM/IEEE Symposium on Architectures for Networking and Communications Systems (ANCS), pp. 70–81. Cited by: §2.4.1.
  • A. Afanasyev, J. A. Halderman, S. Ruoti, K. Seamons, Y. Yu, D. Zappala, and L. Zhang (2016) Content-based security for the web. In Proceedings of the 2016 New Security Paradigms Workshop, pp. 49–60. Cited by: §2.5.3.
  • A. Afanasyev, X. Jiang, Y. Yu, J. Tan, Y. Xia, A. Mankin, and L. Zhang (2017) NDNS: a dns-like name service for ndn. In 2017 26th International Conference on Computer Communication and Networks (ICCCN), pp. 1–9. Cited by: §2.
  • A. Afanasyev, P. Mahadevan, I. Moiseenko, E. Uzun, and L. Zhang (2013) Interest flooding attack and countermeasures in named data networking. In 2013 IFIP Networking Conference, pp. 1–9. Cited by: Table 8, Table 9, §6.2.2, item 2a, §7.1, Table 4, Table 5, Table 6, Table 7.
  • B. Ahlgren, C. Dannewitz, C. Imbrenda, D. Kutscher, and B. Ohlman (2012) A survey of information-centric networking. IEEE Communications Magazine 50 (7), pp. 26–36. Cited by: §1.
  • M. W. Al Azad and S. Mastorakis (2022a) Reservoir: named data for pervasive computation reuse at the network edge. In 2022 IEEE International Conference on Pervasive Computing and Communications (PerCom), pp. 141–151. Cited by: §2.
  • M. W. Al Azad and S. Mastorakis (2022b) The promise and challenges of computation deduplication and reuse at the network edge. IEEE Wireless Communications. Cited by: §2.
  • M. W. Al Azad, S. Shannigrahi, N. Stergiou, F. R. Ortega, and S. Mastorakis (2021) CLEDGE: a hybrid cloud-edge computing framework over information centric networking. In 2021 IEEE 46th Conference on Local Computer Networks (LCN), pp. 589–596. Cited by: §2.3.3.
  • S. Al-Sheikh, M. Wählisch, and T. C. Schmidt (2015) Revisiting countermeasures against ndn interest flooding. In Proceedings of the 2nd ACM Conference on Information-Centric Networking, pp. 195–196. Cited by: §5.3.
  • M. Alhisnawi and M. Ahmadi (2020) Detecting and mitigating ddos attack in named data networking. Journal of Network and Systems Management, pp. 1343–1356. Cited by: §6.2.2, Table 4, Table 5, Table 6, Table 7.
  • A. Alston and T. Refaei (2016) Neutralizing interest flooding attacks in named data networks using cryptographic route tokens. In 2016 IEEE 15th International Symposium on Network Computing and Applications (NCA), pp. 85–88. Cited by: Table 8, Table 9, §6.1.
  • M. Ambrosin, A. Compagno, M. Conti, C. Ghali, and G. Tsudik (2018) Security and privacy analysis of national science foundation future internet architectures. IEEE Communications Surveys & Tutorials 20 (2), pp. 1418–1442. Cited by: §1.1, Table 1.
  • A. Anand, F. Dogar, D. Han, B. Li, H. Lim, M. Machado, W. Wu, A. Akella, D. G. Andersen, J. W. Byers, et al. (2011) XIA: an architecture for an evolvable and trustworthy internet. In Proceedings of the 10th ACM Workshop on Hot Topics in Networks, pp. 1–6. Cited by: §1.
  • T. Anderson, K. Birman, R. Broberg, M. Caesar, D. Comer, C. Cotton, M. J. Freedman, A. Haeberlen, Z. G. Ives, A. Krishnamurthy, et al. (2013) The nebula future internet architecture. In The Future Internet Assembly, pp. 16–26. Cited by: §1.
  • A. Benarfa, M. Hassan, A. Compagno, E. Losiouk, M. B. Yagoubi, and M. Conti (2019) ChoKIFA: a new detection and mitigation approach against interest flooding attacks in ndn. In International Conference on Wired/Wireless Internet Communication, pp. 53–65. Cited by: Table 8, Table 9, §6.2.2, item 1, Table 4, Table 5, Table 6, Table 7.
  • A. Benarfa, M. Hassan, E. Losiouk, A. Compagno, M. B. Yagoubi, and M. Conti (2020) ChoKIFA+: an early detection and mitigation approach against interest flooding attacks in ndn. International Journal of Information Security. Cited by: Table 8, Table 9, §6.2.2, Table 4, Table 5, Table 6, Table 7.
  • A. Benmoussa, A. el Karim Tahari, C. A. Kerrache, N. Lagraa, A. Lakas, R. Hussain, and F. Ahmad (2020) MSIDN: mitigation of sophisticated interest flooding-based ddos attacks in named data networking. Future Generation Computer Systems 107, pp. 293–306. Cited by: Table 8, Table 9, §6.2.2, item 2a, item 1, §7.1, Table 4, Table 5, Table 6, Table 7.
  • A. Benmoussa, A. el Karim Tahari, N. Lagaa, A. Lakas, F. Ahmad, R. Hussain, C. A. Kerrache, and F. Kurugollu (2019) A novel congestion-aware interest flooding attacks detection mechanism in named data networking. In 2019 28th International Conference on Computer Communication and Networks (ICCCN), pp. 1–6. Cited by: Table 8, Table 9, §6.2.2, item 1, item 2, §7.1, Table 4, Table 5, Table 6, Table 7.
  • M. Buragohain and S. Nandi (2020) Demystifying security on ndn: a survey of existing attacks and open research challenges. In The” Essence” of Network Security: An End-to-End Panorama, pp. 241–261. Cited by: §1.1, Table 1.
  • J. Cao, D. Pei, X. Zhang, B. Zhang, and Y. Zhao (2016) Fetching popular data from the nearest replica in ndn. In 2016 25th International Conference on Computer Communication and Networks (ICCCN), pp. 1–9. Cited by: §2.3.2.
  • K. Chan, B. Ko, S. Mastorakis, A. Afanasyev, and L. Zhang (2017) Fuzzy interest forwarding. In Proceedings of the Asian Internet Engineering Conference, pp. 31–37. Cited by: §2.3.3.
  • L. Chapin, Dr. D. D. Clark, R. T. Braden, R. Hobby, and Dr. V. G. Cerf (1991) Towards the Future Internet Architecture. Request for Comments, RFC Editor. Note: RFC 1287 External Links: Link Cited by: §1.
  • J. Chen, G. Xing, M. Cui, H. Huo, and R. Hou (2019) Isolation forest based interest flooding attack detection mechanism in ndn. In 2019 2nd International Conference on Hot Information-Centric Networking (HotICN), pp. 58–62. Cited by: Table 8, Table 9, §6.2.2, Table 4, Table 5, Table 6, Table 7, §8.2.6.
  • S. Chen and F. Mizero (2015) A survey on security in named data networking. arXiv preprint arXiv:1512.04127. Cited by: §1.1, Table 1.
  • G. Cheng, L. Zhao, X. Hu, S. Zheng, H. Wu, R. Li, and C. Fan (2019) Detecting and mitigating a sophisticated interest flooding attack in ndn from the network-wide view. In 2019 IEEE First International Workshop on Network Meets Intelligent Computations (NMIC), pp. 7–12. Cited by: Table 8, Table 9, §6.2.2, item 2, §7.2, Table 4, Table 5, Table 6, Table 7.
  • S. Choi, K. Kim, S. Kim, and B. Roh (2013) Threat of dos by interest flooding attack in content-centric networking. In The International Conference on Information Networking 2013 (ICOIN), pp. 315–319. Cited by: §5.3.
  • A. Compagno, M. Conti, P. Gasti, and G. Tsudik (2013) Poseidon: mitigating interest flooding ddos attacks in named data networking. In 38th annual IEEE conference on local computer networks, pp. 630–638. Cited by: Table 8, Table 9, §6.2.2, §7.2, Table 4, Table 5, Table 6, Table 7.
  • A. Compagno, M. Conti, C. Ghali, and G. Tsudik (2015) To nack or not to nack? negative acknowledgments in information-centric networking. In 2015 24th International Conference on Computer Communication and Networks (ICCCN), pp. 1–10. Cited by: §5.3.
  • H. Dai, Y. Wang, J. Fan, and B. Liu (2013) Mitigate ddos attacks in ndn by interest traceback. In 2013 IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), pp. 381–386. Cited by: Table 8, Table 9, §6.2.2, §7.2, Table 4, Table 5, Table 6, Table 7, §8.2.5.
  • T. Dierks and E. Rescorla (2008) RFC 5246-the transport layer security (tls) protocol version 1.2. The Internet Engineering Task Force (IETF). Cited by: §2.6.4.
  • I. U. Din, S. Hassan, M. K. Khan, M. Guizani, O. Ghazali, and A. Habbal (2017) Caching in information-centric networking: strategies, challenges, and future research directions. IEEE Communications Surveys & Tutorials 20 (2), pp. 1443–1474. Cited by: §2.3.2.
  • K. Ding, Y. Liu, H. Cho, H. Chao, and T. K. Shih (2016) Cooperative detection and protection for interest flooding attacks in named data networking. International Journal of Communication Systems 29 (13), pp. 1968–1980. Cited by: Table 8, Table 9, §6.2.2, Table 4, Table 5, Table 6, Table 7.
  • J. Dong, K. Wang, W. Quan, and H. Yin (2020) InterestFence: simple but efficient way to counter interest flooding attack. Computers & Security 88, pp. 101628. Cited by: Table 8, §6.2.2, Table 4, Table 5, Table 6, Table 7, §8.2.4.
  • N. Fotiou, P. Nikander, D. Trossen, and G. C. Polyzos (2010) Developing information networking further: from psirp to pursuit. In International Conference on Broadband Communications, Networks and Systems, pp. 1–13. Cited by: §1.
  • G. García, A. Beben, F. J. Ramón, A. Maeso, I. Psaras, G. Pavlou, N. Wang, J. Śliwiński, S. Spirou, S. Soursos, et al. (2011) COMET: content mediator architecture for content-aware networks. In 2011 Future Network & Mobile Summit, pp. 1–8. Cited by: §1.
  • P. Gasti, G. Tsudik, E. Uzun, and L. Zhang (2013) DoS and ddos in named data networking. In 2013 22nd International Conference on Computer Communication and Networks (ICCCN), pp. 1–7. Cited by: §3.6, item 2, §5.3.
  • P. Gasti and G. Tsudik (2018) Content-centric and named-data networking security: the good, the bad and the rest. In 2018 IEEE International Symposium on Local and Metropolitan Area Networks (LANMAN), pp. 1–6. Cited by: §1.1, Table 1.
  • C. Ghali, G. Tsudik, E. Uzun, and C. A. Wood (2017) Closing the floodgate with stateless content-centric networking. In 2017 26th International Conference on Computer Communication and Networks (ICCCN), pp. 1–10. Cited by: §6.1.
  • C. Ghasemi, H. Yousefi, K. G. Shin, and B. Zhang (2018) MUCA: new routing for named data networking. In 2018 IFIP Networking Conference (IFIP Networking) and Workshops, pp. 289–297. Cited by: §2.4.
  • R. Hou, M. Han, J. Chen, W. Hu, X. Tan, J. Luo, and M. Ma (2019) Theil-based countermeasure against interest flooding attacks for named data networks. IEEE Network 33 (3), pp. 116–121. Cited by: Table 8, Table 9, §6.2.2, item 2, Table 4, Table 5, Table 6, Table 7.
  • V. Jacobson, M. Mosko, D. Smetters, and J. Garcia-Luna-Aceves (2007) Content-centric networking. Whitepaper, Palo Alto Research Center, pp. 2–4. Cited by: §1.
  • V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs, and R. L. Braynard (2009) Networking named content. In Proceedings of the 5th international conference on Emerging networking experiments and technologies, pp. 1–12. Cited by: §5.3.
  • A. Karami and M. Guerrero-Zapata (2015) A hybrid multiobjective rbf-pso method for mitigating dos attacks in named data networking. Neurocomputing 151, pp. 1262–1282. Cited by: Table 8, Table 9, §6.2.2, Table 4, Table 5, Table 6, Table 7.
  • H. Khelifi, S. Luo, B. Nour, and S. C. Shah (2018) Security and privacy issues in vehicular named data networks: an overview. Mobile Information Systems 2018. Cited by: §1.1, Table 1, §1, §4.1.2.
  • T. Koponen, M. Chawla, B. Chun, A. Ermolinskiy, K. H. Kim, S. Shenker, and I. Stoica (2007) A data-oriented (and beyond) network architecture. In Proceedings of the 2007 conference on Applications, technologies, architectures, and protocols for computer communications, pp. 181–192. Cited by: §1.
  • S. Krishnan and S. Frankel (2011) IP security (ipsec) and internet key exchange (ike) document roadmap. IETF RFC 6071, Ericsson. Cited by: §2.6.4.
  • N. Kumar, A. K. Singh, A. Aleem, and S. Srivastava (2019a) Security attacks in named data networking: a review and research directions. Journal of Computer Science and Technology 34 (6), pp. 1319–1350. Cited by: §1.1, Table 1.
  • N. Kumar, A. K. Singh, and S. Srivastava (2019b) Feature selection for interest flooding attack in named data networking. International Journal of Computers and Applications, pp. 1–10. Cited by: §5.3.
  • C. A. Lee, Z. Zhang, Y. Tu, A. Afanasyev, and L. Zhang (2018) Supporting virtual organizations using attribute-based encryption in named data networking. In 2018 IEEE 4th International Conference on Collaboration and Internet Computing (CIC), pp. 188–196. Cited by: §2.5.2.
  • V. Lehman, A. M. Hoque, Y. Yu, L. Wang, B. Zhang, and L. Zhang (2016) A secure link state routing protocol for ndn. Tech. Rep. NDN-0037. Cited by: §2.4.
  • T. Li, Z. Kong, S. Mastorakis, and L. Zhang (2019a) Distributed dataset synchronization in disruptive networks. In 2019 IEEE 16th International Conference on Mobile Ad Hoc and Sensor Systems (MASS), pp. 428–437. Cited by: §2.6.3.
  • Y. Li, Z. Zhang, X. Wang, E. Lu, D. Zhang, and L. Zhang (2019b) A secure sign-on protocol for smart homes over named data networking. IEEE Communications Magazine 57 (7), pp. 62–68. Cited by: §2.5.1.
  • Z. Li and J. Bi (2014) Interest cash: an application-based countermeasure against interest flooding for dynamic content in named data networking. In Proceedings of The Ninth International Conference on Future Internet Technologies, pp. 1–6. Cited by: §6.2.1.
  • Z. Li, Y. Xu, B. Zhang, L. Yan, and K. Liu (2018) Packet forwarding in named data networking requirements and survey of solutions. IEEE Communications Surveys & Tutorials 21 (2), pp. 1950–1987. Cited by: §2.4.
  • G. Liu, W. Quan, N. Cheng, B. Feng, H. Zhang, and X. S. Shen (2018a) BLAM: lightweight bloom-filter based ddos mitigation for information-centric iot. In 2018 IEEE Global Communications Conference (GLOBECOM), pp. 1–7. Cited by: Table 8, Table 9, §6.2.1, Table 4, Table 5, Table 6, Table 7.
  • G. Liu, W. Quan, N. Cheng, K. Wang, and H. Zhang (2018b) Accuracy or delay? a game in detecting interest flooding attacks. Internet Technology Letters 1 (2), pp. e31. Cited by: Table 8, Table 9, §6.2.2, item 2b, §7.1, Table 4, Table 5, Table 6, Table 7, §8.2.4.
  • R. Lutz (2016) Security and privacy in future internet architectures-benefits and challenges of content centric networks. arXiv preprint arXiv:1601.01278. Cited by: §1.1, Table 1.
  • E. Mannes and C. Maziero (2019) Naming content on the network layer: a security analysis of the information-centric network model. ACM Computing Surveys (CSUR) 52 (3), pp. 1–28. Cited by: §1.1, Table 1.
  • S. Mastorakis, A. Afanasyev, Y. Yu, and L. Zhang (2017) Ntorrent: peer-to-peer file sharing in named data networking. In 2017 26th International Conference on Computer Communication and Networks (ICCCN), pp. 1–10. Cited by: §2.6.2.
  • S. Mastorakis, A. Afanasyev, and L. Zhang (2017) On the evolution of ndnSIM: an open-source simulator for NDN experimentation. ACM Computer Communication Review. Cited by: 1st item.
  • S. Mastorakis, T. Li, and L. Zhang (2020a) DAPES: named data for off-the-grid file sharing with peer-to-peer interactions. arXiv preprint arXiv:2006.01651. Cited by: §2.6.3.
  • S. Mastorakis, A. Mtibaa, J. Lee, and S. Misra (2020b) ICedge: when edge computing meets information-centric networking. IEEE Internet of Things Journal 7 (5), pp. 4203–4217. Cited by: §2.3.3.
  • A. Mtibaa and S. Mastorakis (2020) NDNTP: a named data networking time protocol. arXiv preprint arXiv:2007.07807. Cited by: §2.3.3.
  • Y. Nakatsuka, J. L. Wijekoon, and H. Nishi (2018) FROG: a packet hop count based ddos countermeasure in ndn. In 2018 IEEE Symposium on Computers and Communications (ISCC), pp. 00492–00497. Cited by: Table 8, Table 9, §6.2.2, item 1, Table 4, Table 5, Table 6, Table 7.
  • E. Newberry and B. Zhang (2019) On the power of in-network caching in the hadoop distributed file system. In Proceedings of the 6th ACM Conference on Information-Centric Networking, pp. 89–99. Cited by: §2.5.
  • T. Nguyen, H. Mai, R. Cogranne, G. Doyen, W. Mallouli, L. Nguyen, M. El Aoun, E. M. De Oca, and O. Festor (2019) Reliable detection of interest flooding attack in real deployment of named data networking. IEEE Transactions on Information Forensics and Security 14 (9), pp. 2470–2485. Cited by: §6.2.2.
  • T. Nguyen, X. Marchal, G. Doyen, T. Cholez, and R. Cogranne (2017) Content poisoning in named data networking: comprehensive characterization of real deployment. In 2017 IFIP/IEEE Symposium on Integrated Network and Service Management (IM), pp. 72–80. Cited by: item 2.
  • T. N. Nguyen, R. Cogranne, G. Doyen, and F. Retraint (2015) Detection of interest flooding attacks in named data networking using hypothesis testing. In 2015 IEEE International Workshop on Information Forensics and Security (WIFS), pp. 1–6. Cited by: Table 8, §6.2.2, Table 4, Table 5, Table 6.
  • B. Nour, H. Khelifi, R. Hussain, S. Mastorakis, and H. Moungla (2021) Access control mechanisms in named data networks: a comprehensive survey. ACM Computing Surveys (CSUR) 54 (3), pp. 1–35. Cited by: §2.5.2.
  • B. Pang, R. Li, X. Zhang, J. Shi, and M. Huang (2017) Research on interest flooding attack analysis in conspiracy with content providers. In 2017 7th IEEE International Conference on Electronics Information and Emergency Communication (ICEIEC), pp. 543–547. Cited by: §5.3.
  • I. Psaras, O. Ascigil, S. Rene, G. Pavlou, A. Afanasyev, and L. Zhang (2018) Mobile data repositories at the edge. In USENIX Workshop on Hot Topics in Edge Computing (HotEdge 18), Cited by: §2.5.
  • C. Pu, N. Payne, and J. Brown (2019) Self-adjusting share-based countermeasure to interest flooding attack in named data networking. In 2019 International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData), pp. 142–147. Cited by: Table 8, Table 9, §6.2.2, Table 4, Table 5, Table 6, Table 7.
  • S. Rai and D. Dhakal (2018) A survey on detection and mitigation of interest flooding attack in named data networking. In Advanced Computational and Communication Paradigms, pp. 523–531. Cited by: §1.1, Table 1.
  • S. Rai, K. Sharma, and D. Dhakal (2019) A survey on detection and mitigation of distributed denial-of-service attack in named data networking. In Advances in communication, cloud, and big data, pp. 163–171. Cited by: §1.1, Table 1.
  • S. K. Ramani, R. Tourani, G. Torres, S. Misra, and A. Afanasyev (2019) NDN-abs: attribute-based signature scheme for named data networking. In Pr