3.4

PIT Utilization Ratio (PUR) values for all the CNMR's monitoring routers under an the attack mounted in [START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF]

3.9

In Fig. 3.9a, the Interest Satisfaction Ratio (ISR) is measured in the baseline scenario under the three novel IFAs. In Fig. 3.9b, PIT Utilization Ratio (PUR)

for monitoring routers under all the dierent attacks compared to the SoA results.

Introduction ix

The Internet started as an experiment escaping the lab in the early 70s and in a few decades time it has become a disrupting technology deeply changing our everyday lives. The foundations upon today's Internet lay are the same ones set at the time of the original architecture design. On the one hand, the targeted simplicity of the original layered Internet architecture has fostered a smooth proliferation of services to be designed and integrated into it. On the other hand, the easiness in the introduction of additional features has sometimes embedded point solutions ignoring the overall architectural framework. The proliferation of such ad-hoc patches has increased the complexity of the original Internet architecture. Because of the struggling deployment of new features over the last decades (e.g., IPv6 or IP multicast), there is a widespread fear that the evolutionary patch-work of the Internet has contributed to its ossication. That is, it has become hard or impossible to create any further innovation at the core of the Internet.

Innovation at the edge of the network works, but it constantly faces constraints imposed by the core which remains untouched. However, current Internet's issues with security and mobility models, network management, accounting, content distribution mandate infrastructural changes to be properly addressed. Therefore, a clean-slate design of the Internet architecture is required, that is, a redesign of the network based on a updated set of core principles. With that aim, a considerable amount of clean-slate research on future Internet architectures has been pursued since more than a decade.

Any future Internet design must acknowledge that today's Internet is largely dominated by multimedia content consumption. Users produce and consume several exabytes of contents permonth in a totally distributed and uncontrolled manner. The massive content distribution is supported by the current Internet via ad-hoc infrastructure overprovisioning and overlay orchestration mechanisms. In fact, Content Distribution Networks (CDNs), which represent the mainstream solution to the content distribution problem in the Internet, consist of dedicated servers placed in geographical proximity of users meant to hold content replicas and improve the users' download experience. Nevertheless, the widespread use of CDNs is a far from optimal solution to the content distribution problem. CDNs require agreements with ISPs and DNS redirections. Further, CDNs introduce considerable operational and capital costs which can only be aorded by a few big commercial players.

The need for a dedicated support to achieve ecient content distribution in the Internet stems from the absence in its original architecture design of content-oriented primitives at the network core. Internet was originally designed as a host-to-host communication network. Bidirectional data-exchanges in the Internet are achieved by explicitly including source and destination physical addresses in every IP datagram. Conversely, today's Internet usage is mainly focused on retrieving specic contents rather than on reaching specic sources providing those contents.

Information-Centric Networking (ICN) is a clean-slate research paradigm aiming to design a more content-oriented future Internet. By introducing content-oriented routing primitives, widespread in-network caching and asynchronous publish/subscribe-oriented communication models, ICN aims to improve content retrieval and use of network resources in the Internet architecture. Interests in traversed routers for potential Data packets to follow the reverse path to the original requester of a content.

In this dissertation we address the security issues introduced by the forwarding mechanism featured by the NDN architecture. The Pending Interest Table (PIT) in NDN networks allows nal users' Interests to create state in the network and achieve an asynchronous address-less Interest-Data exchange. On one hand, the PIT stateful mechanism enables properties like Interests aggregation, multicast Data delivery and native hop-by-hop control ow. On the other hand, the PIT stateful forwarding behavior can be easily abused by malicious users to mount a disruptive distributed denial of service (DDoS) attacks, called Interest Flooding Attacks (IFAs).

In IFAs, loosely coordinated botnets can ood the network with a large amount of hard-to-satisfy

Interests with the aim to overload both the network infrastructure and the content producers.

Countermeasures against the IFA have been proposed since the early attack discovery. However, a fair understanding of the defense mechanisms' real ecacy is missing since those have been tested under simplistic assumptions about the evaluation scenarios. Thus, overall, IFAs still appear easy to launch but hard to mitigate. This open security threat raises serious doubts about the worthiness of the PIT stateful forwarding mechanism in NDN networks.

The work presented in this manuscript shapes a better understanding of both the implications of IFAs and the possibilities of improving the state-of-the-art defense mechanisms against these attacks. The contributions of this work include the denition of a more complete and realistic attacker model for IFAs, the design of novel stealthy IFA attacks built upon the proposed attacker model, a re-assessment of the most-ecient state-of-the-art IFA countermeasures against the novel proposed attacks, the theorization of novel class of IFA countermeasures, the design of an instance of this new class of countermeasures which eciently addresses the novel stealthy IFAs.

Finally, this work also proposes to leverage the latest programmable data-plane technologies to design and test alternative forwarding mechanisms for the NDN which could be less vulnerable to the IFA threat.

The content of this manuscript is organized as follows. To conclude, the last section of this manuscript summarizes the contributions described in this dissertation and outlines several research directions for future work. With regard to the future work, rst, this dissertation paves the way for further improvements in the state-of-the-art defense mechanisms against IFAs. More precisely, ndings emerged throughout this work show the potential for hybrid reactive/proactive and/or control-plane assisted countermeasures to be designed and counteract IFAs more eectively. Second, this dissertation proposes to leverage the latest technologies in the eld of programmable data-planes for the design of NDN routers.

The NDN.p4 design was proposed shortly after the P4 language vision had emerged, so it was somehow constrained by that technology's infancy. Since then, the P4 language ecosystem has considerably evolved. Today, P4 features a richer language feature-set and is supported by many hardware/software targets. Recent advances in P4 can be used to rene the NDN.p4 design and fairly compare it to the state-of-the-art NDN router designs.

xiii Chapter 1

Future Network Architectures

The design principles for today's Internet had been developed in the 60s and 70s as the main outcome of a US defense research organization, the Advanced Research Projects Agency (ARPA), project. Less than twenty years later, the rationale that had shaped the design of the early Internet protocols was elegantly summarized in [START_REF] Clark | The design philosophy of the darpa internet protocols[END_REF]. The rst Internet design mainly aimed to interconnect existing packet switching networks to provide some larger services. On top of that, some secondary requirements were set, like reliability under transient network disruptions, support for dierent types of transport services, distributed network management tools, etc. The main goal of that early design was to provide a general and exible infrastructure upon which to easily implement and run diverse services. The realization of Internet built upon that original abstract architecture has, over the years, surpassed the initial expectations. In fact, today's Internet accommodates a much broader range of services.

Since the explosion of the World Wide Web, a new set of requirements and trends of use compromise some of the Internet original design principles and strain the current network infrastructure.

Most of the time, additional features have been added to the architecture as point solutions to meet specic, yet legitimate, requirements (e.g., mobility, security, IP addresses scarcity). Thus, some sort of absence of a broader "architectural thinking" has often embodied patches which, in the best case, have only broken some of the original design principles (e.g., several avors of middlebox violate the end-to-end principle [START_REF] Saltzer | End-to-end arguments in system design[END_REF]), but which, in the worst case, have introduced undesired and conicting feature interactions [START_REF] Braden | Developing a next-generation internet architecture[END_REF] (e.g., intrinsic IPsec/NAT incompatibilities).

Indeed, this incremental renement process has increased the architecture complexity and compromised its exibility therefore harming the conception and the smooth deployment of any future feature. Ideally, overturning this evolutionary path would imply to only develop and introduce new features coherently with the existing architectural framework. Nevertheless, today's really dierent requirements would require to devise a completely new architecture. This latter process is usually referred to as "clean-slate design" [START_REF] Feldmann | [END_REF].

A clean-slate approach implies rethinking the basic assumptions and design principles of the architecture to address simultaneously all the newly-emerged challenges that today's Internet is facing with. Many scientists question clean-slate research in networking as "impractical" since that does not lead to any short term deployment. Others think this intellectual exercise is rst benecial to the ongoing incremental Internet evolution and then plants seeds that will enable research experiments to consolidate in future networks [START_REF] Rexford | Future internet architecture: clean-slate versus evolutionary research[END_REF]. For those reasons, several big research frameworks [START_REF] Pan | A survey of the research on future internet architectures[END_REF] have been launched worldwide to encourage clean-slate research on the design of future Internet architectures. Although the projects dier from each other, there seems to be a small set of common goals that they all pursue. Those goals raise from the Internet require-ments of security, support for mobility of terminals, cost-eective and resource-ecient massive content-distribution, infrastructure scalability, need for ne-grained and seamless accounting and network management tools. Moreover, since the original design of Internet, many factors have changed like advances in technologies, stakeholders, new application requirements, role of and trust in involved parties, service dierentiation at the network core. This produces a broader perspective on the design of any internetworking architecture including end-users and economics aspects too.

Beyond the peculiarities of each proposed design, there are a few core factors which any new architecture design should consider. These factors could be gathered in ve main categories according to the domain of interest, although these domains are tightly interrelated:

• entities: at the beginning Internet was engineered for host-based communication between expensive mainframes. Since then, network participants have increased and, just to name a few, now include normal users, Internet Service Providers, government agencies, telco carriers, large commercial players (e.g., Google, Facebook, Microsoft, Apple). More actors bring more interests and so increase the conict of interests space [START_REF] Clark | Tussle in cyberspace: dening tomorrow's internet[END_REF].

• communications models: there has been an evolution from the single original client-server model to multiple communication models. The World Wide Web (WWW) and other technologies like Email have dictated a usage trend based on content retrieval from specic sources and access of services. Moreover, peer-to-peer (P2P) networks have boosted a model where content can be fetched simultaneously by dierent hosts found through some middleware support. Yet, the emergence of platforms for sharing user generated content (e.g., Youtube, Instagram, Flickr) has also considerably increased the daily quantity of content produced and consumed via the global network. Finally, the adoption of the Cloud Computing paradigm has generated yet another kind of trac which ooads computation and storage to resource pools distributed in the network.

• advances in technology: several technical challenges must be addressed when proposing any new architecture realization. Therefore, it is important to know the current, and to speculate on the foreseeable, hardware and software toolset which may be leveraged to address those challenges. For example, the scalability of a proposed routing approach or a new naming system may look unfeasible according to the state of art. However, a combination of technology advances and new algorithmic solutions may overcome this barrier in the short term (e.g., when IPv6 was proposed, there existed no algorithms to compute prex lookups in microsecond for those longer IP addresses, later on, a binary search on prex lengths algorithm was invented [START_REF] Waldvogel | Scalable high speed ip routing lookups[END_REF]).

• multi-requirements network: the conception of the original Internet architecture had envisioned a limited-size research network rather than a globally deployed one. Hence, a unique list of requirements was considered for the whole network. However, the diversity of today's Internet created by the multitude of actors and trends of use inevitably leads to a scenario where no t-all list can be conceived. Some requirements will apply to some portions of the network meanwhile they will strain in others.

• trends of information consumption: today's Internet trac is dominated by the access of contents. According to the latest Cisco's trac forecast [START_REF]Cisco Visual Networking Index: Global Mobile Data Trac Forecast Update[END_REF], the expected trac growth will increase threefold over the next 4 years, raising the bar to 127-fold from 2005 to 2021. The busy-hour Internet trac grows more rapidly than the average one, bringing up the phantom of the ash crowd eect. By 2021, trac from wireless and mobile devices will account for more than 63% of the the total Internet trac. When looking at the consumer trac by subsegment, "Internet Video" and "Web, email and data" largely drive the consumption.

Among the above factors, two issues deserve a particular attention since these have to be constantly addressed to keep the Internet alive and operational: i) the increase of the global trac and ii) the prominent use of mobile devices to consume/provide data. Both factors fear the Internet collapse because of the poorly scalable and resource demanding solutions, namely, infrastructure over-provisioning (as done, for example, with Content Delivery Networks) and network handover mechanisms (e.g., mobile IP), which have been so far devised to deal with them.

On one hand, the same forecast [START_REF]Cisco Visual Networking Index: Global Mobile Data Trac Forecast Update[END_REF] says that 70% of all Internet trac will cross Content Delivery Networks (CDNs) by 2021. CDNs consist of strategically deployed data centers to serve users in the geographical vicinity. The main aim of CDNs is the reduction of the latency experienced by end-users by bringing content copies closer to them. However, the service is a complex overlay solution which brings additional capital and operational costs, requires an agreement with a CDN provider and a DNS redirection mechanism. On the other hand, Mobile IP [START_REF] Perkins | Ip mobility support for ipv4, revised, Internet Requests for Comments[END_REF] is today's de facto standard to guarantee continuous connectivity despite mobility of host terminals.

The Mobile IP protocol is based on multiple software agents which perform either tunneling or address translation. Although mobility is provided transparently to end-users, this approach has several security issues, introduces triangulation routing problems and, of course, additional unpredictable latency.

Many of the clean-slate Internet research proposals use a holistic approach to deal with the above factors. That is, their design aims to fulll several of the requirements (security, mobility, reliability and availability, problem analysis, scalability, quality of service, economics [START_REF] Feldmann | Internet clean-slate design: What and why[END_REF]) for a global network at the same time. However, factors and requirements are variegated and so generate a complex interaction space. Hence, research projects usually put the main focus on one specic issue and then build around that to address some other primary requirements. For example, the Mobility project [14], funded by the NSF Future Internet Architecture (FIA) program, envisions a network design to ease the mobility of terminals. Then, as direct consequence of centering the design on the mobility requirement, other factors deserve immediate attention, likewise security and trust models for the open wireless access, name resolution and storage-aware routing protocols. Or yet another FIA project, the Expressive Internet Architecture (XIA) [START_REF] Xia | expressive internet architecture project[END_REF], mainly targets simultaneous support for diverse communication entities (e.g., users, services, content), called principals, meanwhile it enforces other properties like intrinsic security and exible addressing.

According to the actual large deployment and consequent usage of CDNs, any future Internet architecture will mainly need to deal with large-scale content distribution. Yet, this mainstream usage trend is sometimes either neglected or treated as secondary by most of the related research projects. Instead, a content-oriented approach is taken by another branch of clean-slate Internet research, called Information-Centric Networking (ICN). The ICN paradigm promotes the foremost role of the information in future network architectures. Among other design principles, ICN designs aim to empower directly the network architecture with mechanisms (e.g., ubiquitous innetwork caching, content-oriented routing primitives) to eciently support massive information distribution. The resulting content-oriented networks feature properties to promisingly address future Internet requirements and factors. Therefore, throughout the last decade, research on ICN has gained considerable traction and produced important scientic insights into the design of future networks.

The motivation and the general idea behind the ICN vision is presented in Sec. 1.1 where related research projects, tenets and research challenges of this paradigm are also outlined. Next, in Sec.

1.2 a specic instance of ICN is illustrated since it has been extensively target of study in this work. Finally, Sec. 1.3 explains how some other latest research on networking is (and will be) used to ease the deployment of and further experimentation on ICNs.

1.1 Content as rst-class citizen of the future Internet Information-Centric Networking (ICN) is a clean-slate approach to networking which has emerged to better support the most prominent content distribution models in the Internet. In fact, the current Internet architecture and the related set-of-protocols struggle to serve eciently today's massive production and consumption of multimedia contents through the global network. The key cause for such ineciency can be better explained by looking at the architecture hourglass model depicted in Fig. 1.1. The Internet Protocol (IP), which lays at the waist of the hourglass, oers a basic connection-less best-eort service to the upper layers and accommodates many lower dierent layer-2 technologies. The basic service oered by IP was meant in the early design to inter-connect a variety of existing packet switching networks. Thus, for simplicity, the IP narrow waist constitutes a datagram network, where packets are routed independently based on the destination address carried in their header. The basic IP packet processing logic mainly deals with hop-by-hop datagram forwarding according to pre-populated routing tables from one source address to a destination one. Therein, in its simplest form, a datagram header is agnostic to the payload content and, by consequence, does not provide information to perform any application-specic forwarding optimization.

At the dawn of the Internet, the intended simplicity of the original IP datagram did not seem too constraining. Moreover, additional datagram labeling mechanisms had been later devised to meet potential generic trac classication requirements (e.g., the DiServ protocol [START_REF] Grossman | New terminology and clarications for diserv, Internet Requests for Comments[END_REF] to dierentiate quality of service in network trac). However, despite the further renements, the original datagram unit design still implies that sometimes thousands or millions of identical (i.e., containing the same application layer payload) IP packets may be carried needlessly on the same path. Moreover, transferred data are hardly reusable after the end of a transport session, since they have not been stored anywhere on the path and their security, if any, was tied to the specic recipient providing them. Further, if either one or both communication endpoints move during the data transfer, the transport session has to be kept or re-established for the transfer not to be disrupted (by no surprise, the intricacies of protocols to support host mobility, like MobileIP, stem from this last requirement).

Research on Information-Centric Networking

The genesis of the research on ICN is hard to track back precisely since it should be fairly attributed to ideas converged from several domains into a unique research area. A tentative timeline of ICN research from the TRIAD project onwards is presented in [17]. However, the author does believe that a chronology should be dierently sketched outlining the birth and growth in parallel of some seminal ideas which made the soil fertile for the emergence of further more structured research frameworks. So, he rather proposes classifying existing related literature and research in three distinct epochs. The classication is illustrated in Fig. 1.2.

The rst generation of research on ICN, whose research projects are here named "the ancestors", includes four main works on the design of a more content-oriented Internet architecture. In a certain sense, those works laid down the foundations for most of the further related research.

In fact, they had identied the primary goals (improving security and performance of content distribution) and some key challenges (e.g., naming, routing and forwarding, security and trust models) in the design of such a future network as well as suggested some preliminary solutions later leveraged and rened by the next ICN architectures. The ancestors are:

• Standford's TRIAD project [START_REF]The triad project[END_REF]: in the early 2000s the TRIAD work [START_REF] Gritter | An architecture for content routing support in the internet[END_REF] is often credited to having pioneered the eld with the rst seminal proposal for a complete content-oriented Internet architecture. TRIAD's authors feared the inadequacy of transparent web proxies, CDNs and load balancing switches at web sites to implement content routing at the Internet scale. Those existing solutions are often proprietary and not ecient, further, violate some architecture principles. Therefore, TRIAD proposed an IP-compatible "content layer" to perform ecient content routing to content replicas in the network.

st Generation

The ancestors

nd Generation

The successors • PARC's Content-Centric Networking (CCN) [START_REF]The project ccnx at the palo alto research center[END_REF]: this work was rst advertised at Google [START_REF]A new way to look at networking, van jacobson at googletechtalks[END_REF] by Van Jacobson, and later on published in [START_REF] Jacobson | Networking named content[END_REF]. CCN treats content as the main network primitive, so departing from the address-based routing model of IP. CCN aims to improve content availability and security by devising a content-oriented level for the thin waist of the Internet's hourglass model. The authors illustrate the new CCN layer-3 protocol proposing packet formats and the router's forwarding plane. Further, they implement an open source prototype of the CCN stack and show its eciency for both le transfer and point-to-point network protocols.

3
• Berkeley's Data-Oriented Named Architecture (DONA) [START_REF] Koponen | Stoica, A data-oriented (and beyond) network architecture[END_REF]: DONA proposes a cleanslate Internet to achieve persistence of names, availability and authentication for data and services. The architecture mainly focuses on naming (using Self-Certifying Names) and name resolution (made by anycast routing on names) to establish the three aforementioned properties. DONA also uses ubiquitous caching and names lower in the network stack to achieve routing to nearest copies. The related work presented in [START_REF] Koponen | Stoica, A data-oriented (and beyond) network architecture[END_REF] acknowledges that this proposal merges several early ideas in an coherent architecture.

• Carzaniga et al.'s Content-Based Networking (CBN) [24]: a theoretical framework for CBN, which is proposed in [START_REF] Carzaniga | Content-based networking: A new communication infrastructure[END_REF], denes the required building blocks and primitives for a contentoriented communication infrastructure. Content-based networks are meant to oer better support for several classes of applications where data-transfers are triggered by receivers' interests without specic sender addresses. In modern networks, that communication model [START_REF] Carzaniga | Architectures for an event notication service scalable to wide-area networks[END_REF]. Therefore, CBN mandates new specic datagrams and functions on datagrams to be designed. As most pressing milestone, the work on CBN tackles the imminent need to explore the design space of content-based forwarding and routing algorithms [START_REF] Carzaniga | Forwarding in a content-based network[END_REF][START_REF] Carzaniga | A routing scheme for content-based networking[END_REF].

It should be recognized that at that early stage these works were not fully aligned on the same set of goals. The dierent aims of the ancestors projects are shown in Table 1.1. Nevertheless, they had presented many similarities (e.g., the exigence of some kind of in-network storage, name-based routing algorithms, name-resolution mechanisms) which were leveraged later by a second generation of projects.

The "successors" are projects which build upon the directions and the problems identied by the ancestors by analyzing technical solutions in more mature architectural frameworks. They are not presented anymore as separate ellipses in Fig. 1.2 since they do not stand anymore as fully separate projects. In fact, they can rather be grouped in macro categories which have taken mutually exclusive decisions on some core design principles like naming and routing (for a denition of those design principles see Sec. 1.1.2). On one hand, the PURSUIT project and its predecessor PSIRP [29] propose a clean-slate Internet architecture implementing a receiver-driven Publish-Subscribe paradigm. PURSUIT/PSIRP leverages the at identiers naming system proposed in DONA, but it features rendez-vous nodes to match publications to subscriptions and topology-manager nodes to build forwarding paths for content delivery. Further, it enhances the at identier names with the notion of scopes in order to organize the information distribution in the network and improve its reachability. Or, the Network of Information (NetInf ) architecture proposed by the 4WARD/SAIL project [START_REF]Scalable and adaptive internet solutions[END_REF] is based on a hybrid name-based routing and name resolution scheme. NetInf provides access to named Data by either forwarding requests by name or by querying a Name Resolution service or both. As PURSUIT/PSIRP, NetInf uses a at namespace to achieve persistent and location-independent naming of contents. On the other hand, architectures like NDN [START_REF]The named data networking (NDN) project[END_REF] (at the time of its inception, the academic fork of the PARC's The contributions made by the successors projects have fueled a third generation of projects that are hereby named "The deployables". These projects (some of which are still ongoing at the time of writing this manuscript) focus on both large-scale deployment of ICN prototypes and the application-driven iterative renement of the respective architectures. Application scenarios of this third generation include distribution of critical information in the aftermath of a disaster (the Green ICN project [START_REF]The greenicn project -architecture and applications of green information-centric networking[END_REF]), commercial viable IP-over ICN deployment (the POINT project [START_REF]The point project -ip over icn -the better ip[END_REF]), the optimization of the transport of passengers and goods (the Bonvoyage project [START_REF]The bonvoyage project[END_REF]), mobile healthcare and building automation and management systems (the NDN Next-Phase [START_REF] Fia-Np | Collaborative research: Named data networking next phase[END_REF]). This newest generation of projects pursues an application-driven evolution of the ICN architectures designed so far. The goal is testing ICN solutions/architectures against selected scenarios of use and enhancing them accordingly in an iterative fashion. Further, this research phase aims at two more targets: i) helping industry partners to develop Proofs of Concept of products and services exploiting ICN, ii) deploying more experimental facilities, ideally test-beds at global-scale, to advance the state of the research on ICN.

Design tenets

As illustrated in the previous section, past and ongoing research projects on ICN dier in the architectural solutions proposed, meanwhile they share several assumptions and goals. Therefore, it is reasonably possible to identify a set of design principles which are valid across dierent ICN architectures. The author summarizes the principles in one sentence before providing an in-depth denition for all of them: "Everything is information, Information is named, Names are scoping/forwarding hints".

First, as the paradigm name suggests, the Information is at the core of every ICN architecture.

The term is used generically to identify any kind information which is exchanged among network participants. Second, information needs persistent and unique names. Third, the names are to be used across dierent layers to improve the content localization and distribution.

Core principles of ICN are:

Naming of Information: in ICN, identiers are associated to every piece of information traversing the network. Those identiers hold some important properties. They are unique.

They are independent of location, of source (e.g., original producer, in-network replica, repository) providing them, and of the way the related data is retrieved. In general, their semantics, if any, is opaque to the network layer.

There have been mainly two naming schemes adopted by existing ICN architectures: hierarchical human-readable names (HRN) and at self-certifying names (SCN). An example of both The advantages of HRNs is that they are easy-to-understand, semantically meaningful, easy to aggregate (aggregation at large-scale of a similar naming scheme is done in today's DNS).

On the other hand, SCNs are meant to provide with the name itself the necessary information to verify some Data's security properties. Hence, SCNs are often made out of the hash of the content provider identity (e.g., the public key) concatenated by the hash of the content identier. The schemes hold dierent properties and suer from dierent issues. Naming properties for ICNs have been brilliantly outlined in [START_REF] Ghodsi | Information-centric networking: Seeing the forest for the trees[END_REF] where HRNs and SCNs are compared in terms of security, scalability and exibility, which are important requirements for any Internet architecture.

Communication Model: ICN architectures pursue publish/subscribe models as the main communication model in their networks. Thus, the data exchange between consumers and producers of information is asynchronous. Among other properties, this model provides two main advantages which are leveraged by the architecture to implement a content-oriented data-exchange.

First, the model decouples senders and receivers in space and time. Second, the publish/subscribe model gives more control both to the network, on how the information is stored and delivered, and to the consumers, which can better specify what information they are interested in fetching.

Self-Secured Data or Data-Centric Security: ICNs data are stored independently from specic network locations. Therefore, today's end-to-end security mechanisms (e.g., the Transport Layer Security protocol) cannot be used to implement secure communication in those networks. Instead, security must be ascertained through the content itself since that can be stored in and retrieved by any location in the network. To achieve that, every data must carry some additional meta-data information which can be used to assess its security properties. This security model usually requires a cryptographic technique applied to the name and the data itself.

For example, cryptographic signatures binding names and data can be used as small in-packet anti-tamper integrity proofs. It must be told that the choice of a certain naming schema has direct implications on the security.

In-Network Storage/Caching: ICN promotes to store popular contents in the network.

For that purpose, some ICN routers are supposed to be equipped with local storage to perform application-independent opportunistic caching of data. This capability will allow routers to serve requests locally if they hold a copy of the related contents in their caches. Obviously, in-network caching contribute both to improve data-availability and to reduce data-delivery delay. The benets of using in-network caches seems to be further supported by the evidence that content requests in today's Internet exhibit a high spatial and temporal locality [START_REF] Almeida | Characterizing reference locality in the www[END_REF].

Application-Program Interfaces: an ICN mandates a new communication API for applications to interact with the network layer. In fact, today's most dominant interface to the network, BSD's Sockets, does not t a data-oriented model. A socket binds an application to both a specic protocol and an endpoint. As advocated by previous work, a perfect network abstraction should break spatial and temporal bounds [START_REF] Demmer | Towards a modern communications api[END_REF]. Any ICN layer-3 protocol should expose to upper-layers applications primitives to publish and retrieve data. Dierent proposals have been advanced so far. They dier yet they usually refer to contents by name and may also take additional parameters to dene scope of publications and/or ltering criteria for searches.

Routing and Forwarding: in ICN, data-oriented algorithms and protocols are used to route requests and responses in the network. The related mechanisms are strictly tied to the naming system adopted by the architecture and may demand additional components, e.g., a name resolution system which converts object identiers to network locators. A cornerstone element of these protocols for ICNs is that they should be designed to allow the network to locate and fetch nearby copies of the requested contents. Sometimes this requirement is achieved on the y inside the network by adaptive forwarding mechanisms, while other times there are omniscient network components which translate content identiers to network locators.

The above principles have been unanimously stated in several related works [START_REF] Ahlgren | [END_REF]17], however, the author denes two more novel principles worth outlining:

• In-Network Capabilities: all the ICN architectures envision a "more sophisticated" processing done at layer-3 which may also require the existence of additional components, e.g., local caches in routers or name resolution agents.

• Cross-Layer Information: ICNs have architecture components like names or identiers which are carried across dierent layers. The components' semantics serves dierent purposes according to the layer where that is processed. This stems from the ICN objective to implement generic network services yet meeting application-specic requirements. This is a shift from the current IP model where, for example, the BSD socket abstraction requires applications to specify endpoints and select specic transport protocols. Those two pieces of information do not allow applications to specify any requirement beyond a small set of transport layer options. Conversely, in ICN architectures, names often specify requirements the network layer can build services upon. For example, names can embed access control scheme semantics in NDNs, or yet, they can scope information in PSIRP networks.

Benets

On the one hand, detractors of this network revolutionary paradigm often claim that indeed ICN does not oer many advantages beyond the ones produced by in-network caching of contents [START_REF] Fayazbakhsh | Less pain, most of the gain: Incrementally deployable icn[END_REF][START_REF] Ghodsi | Information-centric networking: Seeing the forest for the trees[END_REF]. On the other hand, advocates of the ICN postulate and research on scenarios to showcase the potential manifold benets of a data-oriented architecture. Hereby follow some of the improvements that an Information-Centric Network could bring:

Scalable vendor-free cost-eective content delivery: the delivery of content across the In- of consumer and producer nodes [START_REF] Tyson | A survey of mobility in information-centric networks: Challenges and research directions[END_REF]. In ICNs, content availability is determined by the network.

Reduction of middleware: most of today's applications are data/service-oriented and based on a publish/subscribe interaction scheme [START_REF] Eugster | [END_REF]. Those applications do not deal with the security, the performance and the reliability of the data transfer which are delegated to the lower layers in the network stack. This implies that from the application layer to the network one there often exists some middleware mapping between those dierent layer abstractions. The adoption of an Information-Centric Networking would reduce the intricacies of those in-between translation mechanisms by means of i) novel content-oriented APIs for application developers to access network services, ii) semantics-rich content identiers whose expressiveness may be leveraged down to the network layer to provide several services beyond ecient content delivery.

Glue for the Internet fringes: it seems that a unied system to inter-connect dierent Internet-of-Things (IoT) silo solutions is still missing. The proliferation of ad-hoc solutions has been partially conned by the emergence of a few unifying standards, e.g., the 6LoWPAN protocol. However, the IoT ecosystem still proliferates with diverse solutions as a proof that "the TCP/IP stack is not a good t to the IoT environment" [START_REF] Shang | Challenges in iot networking via tcp/ip architecture[END_REF]. The data-centric communication models of ICNs oer promising support to address the challenges of data retrieval delay, resource-constrained devices and intermittent network connections, in many IoT use cases [START_REF] Amadeo | Information-centric networking for the internet of things: challenges and opportunities[END_REF].

Open challenges

Beyond potential benets, the design and the deployment of Information-Centric Networks raise numerous challenges too. The main technical challenges for an Information-Centric Networking are hereby outlined, while a more comprehensive summary can be found in [START_REF] Perkins | Ip mobility support for ipv4, revised, Internet Requests for Comments[END_REF].

Naming: the main purpose of a name in ICNs is to provide persistent unique locationindependent identiers for contents. Meanwhile, a name can be used to create a veriable binding between the content and the name itself. This binding can be used to verify that the content received corresponds to the one requested by that name (the literature on ICN refers to this property as content integrity). Therefore, the choice of a naming scheme for an ICN inuences design choices related to security and trust models. Sec. Scalability of the routing system: as raised in [START_REF] Ghodsi | Information-centric networking: Seeing the forest for the trees[END_REF], any ICN architecture should be able to deal with a large number of objects. Conservative estimates suggest 10 12 objects. That order of magnitude would have a direct impact on the size of the routing tables in ICN-enabled routers.

Today, routing tables must be relatively smaller, roughly 10 Nevertheless, the choice to adopt HRNs could limit caching eectiveness by always routing requests towards the original providers. This argument was rst raised in [START_REF] Ghodsi | Information-centric networking: Seeing the forest for the trees[END_REF], however, since then, adaptive forwarding techniques 2 have been included in some ICNs [START_REF] Yi | Adaptive forwarding in named data networking[END_REF], which could potentially neutralizes this side-eect. In fact, an adaptive forwarding behavior would contribute to contents be fetched through and cached across dierent network paths to a set of content sources.

Security and privacy: ICN promotes a content-oriented security model where no secure channels exist between users and content providers. Implications on the security and privacy models naturally arise from this design choice. This novel security model immunizes the network against some well-known vulnerabilities which were caused by the Internet's host-centric communication model. However, ICN introduces novel components and features which open new attack surfaces. For example, this manuscript thoroughly analyzes the security vulnerabilities of a class of ICNs performing stateful forwarding. Furthermore, neither source nor destination addresses are included in ICN packets, hence, parties involved in a data-exchange benet from anonymity.

However, the name of and other information about every requested content are available to the all the nodes processing the related packets. This generates privacy issues on multiple dimensions: in-network caches, contents, names and signatures [START_REF] Chaabane | Privacy in content-oriented networking: Threats and countermeasures[END_REF]. The revealed information can be exploited for dierent purposes like censorship, tracking users' behaviors, non-repudiation.

Therefore, ICN proposals have to be carefully designed to support better privacy. A good survey of the related work identifying risks of and proposing mitigation mechanisms for privacy issues in ICNs can be found in [START_REF] Tourani | Security, privacy, and access control in information-centric networking: A survey[END_REF].

Caching: there are four main challenges to achieve ubiquitous in-network caching. The rst one relates to the decision of which nodes are eligible to cache contents, which is referred to the cache placement problem. The second one relates to the distribution of contents to deployed caches, which is referred to content placement. The third one deals with the ecient routing of content requests to the closest caches, which is referred to request-to-cache problem. The fourth one relates to the policy to empty and/or replace contents when there is no more space in cache, which is referred to the cache replacement policy. The above challenges are usually addressed according to performance/gain the caching techniques aim to achieve. Among the goals, delivery latency, cache utilization and network load are usually considered. Some of the performance indicators are conicting, thus, some caching techniques prioritize one metric over another one.

Deployment: although they may be considered of secondary issue in the early investigation of a clean-slate networking paradigm, activities like prototyping, simulating, testing are of foremost importance to validate and explore the implications of a network architecture design.

The goal is even more challenging since the needed experimentation should happen at large scale and under realistic trac conditions. A denition of such an experimental facility for clean-slate research on networking is provided in [START_REF] Feldmann | Internet clean-slate design: What and why[END_REF]. Current deployment challenges for ICNs include the design of ICN-compliant forwarding elements, the set-up of large-scale testbeds, standardization activities, solutions to achieve integration with and backward compatibility to the existing infrastructure.

1.2 A primer on Content-Centric/Named-Data Networking Among the available ICN realizations, CCN and its academic twin NDN have achieved a certain degree of maturity since their inception. Today, both ICN platforms and protocol specications are widely used as reference by the research community to further investigate challenges and opportunities in the Information-Centric Networking arena. This kind of architecture has been mainly investigated in the context of this work, hence, it is better illustrated in this section to help the reader familiarize with the architecture components and details which will be often referenced in the rest of the manuscript. The rest of the section is organized as follows. Sec. Around October 2012, the CCNx and the NDN projects got separated. First, a few months after the separation, PARC parted away from the NDN team and stated its design goals in a roadmap document for the release of CCNx 1.0 [START_REF]Ccnx 1.0 protocol specications roadmap[END_REF]. Then, in August 2013, the NDN consortium created a fork of the ccnx code. The separation has been most likely driven by irreconcilable divergences in design choices (see the Appendix A for the "Dierences between CCN and NDN"). Since the separation, CCNx and NDN have diverged on several features and there exists no comprehensive report documenting those 3 .

On one hand, PARC has contributed to the creation of important drafts which have been adopted

as working documents from the IETF ICNRG [START_REF] Marc | mosko@parc.com, Ccnx semantics, Working Draft[END_REF][START_REF]Ccnx messages in tlv format[END_REF]. In 2017, Cisco announced the acquisition of the CCN platform from PARC with the goal "to foster convergence of various dialects of ICN (namely CCN and NDN) into a single harmonized version of ICN, promoting wider and faster adoption of ICN-based solutions required to solve future networking needs" [START_REF]Cisco announces important steps toward adoption of information-centric networking[END_REF]. Cisco has merged the acquired CCNx code with other of its contributions and integrated all of it into the Community ICN (cICN) [START_REF]The community icn (cicn) project[END_REF] open-source project hosted by the Linux Foundation. set by the Interest is deleted since the related Data has been forwarded downstream.

The basic workow described above can be amended by the presence of a Strategy Component. A forwarding strategy is a piece of software logic which may perform adaptive forwarding decisions after the FIB lookup.

Packet format

The current packet format for NDN Interest and Data packets is the outcome of an iterative renement process old as the research project itself. The design of the NDN packet format is driven by a set of requirements: universality/elasticity, extensibility and process eciency [START_REF] Afanasyev | Icn packet format design requirements, Working Draft, IETF Secretariat[END_REF].

When requirements conict, they are sorted by priority. For example, the packet format is made of many variable length elds which provide exibility but at the price of an increase of the packet processing time.

The general structure of Interest and Data packets is illustrated in Fig. A Data packet may contain some meta information following the Name in the MetaInfo eld.

That meta-information species the type of content (e.g., simple payload or public key or link object), the validity time for this Data and the identier of the nal block in a sequence of data chunks. The MetaInfo eld is immediately followed by the payload. Finally, a Data always includes a Signature block made of two TLVs. Those elds, namely the SignatureInfo and the SignatureValue, contain respectively a signature description and the actual bits of the signature.

Naming

Names are a cornerstone of NDN. Names exhibit two main properties by design: network opacity and structured hierarchy. First, NDN names are opaque to the network. In fact, routers understand names structure for forwarding purposes but they are agnostic to any upper-layer semantics. This property was meant to guarantee names and the network layer to evolve independently. This desired opacity allows applications to dene specic name conventions without aecting the basic forwarding operations in the network. Second, NDN names are hierarchically structured. This has a twofold objective. Hierarchies can be exploited to achieve the scalability of the routing system through aggregation, as already discussed in Sec. The adaptive forwarding capabilities of NDN routers constitute a promising tool to detect, among the others, packet losses, network congestion, broken links and to measure packet delivery performance [START_REF] Yi | Adaptive forwarding in named data networking[END_REF]. Nevertheless, forwarding variable length names instead of xed size IP addresses requires a re-engineering of today's forwarding devices. In fact, NDN prototypes must be able to sustain line rates over tables supporting millions and even billions of names.

It must be said that such an enhanced forwarding plane implies a rethink of the role of the routing protocols in NDN networks [START_REF] Yi | On the role of routing in named data networking[END_REF]. The adaptive forwarding plane may overcome short term network churns without relying on the convergence of the upper routing protocol. Therefore, a less stringent requirement for quick convergence in routing protocols allows to explore routing protocols which were thought to be unsuitable before.

In-Network Storage NDN Data packets carry names and signatures, so their integrity and validity can be assessed independently from the source producing them. This implies they can be cached in routers'

Content Stores (CSes) to serve further requests for the same data. An NDN router's CS may be considered analogous to an IP router's local packet buer, except that buered IP packets cannot be reused while buered Data packets can be.

On one hand, in-network caching of both static and dynamic contents (e.g., a live-stream video) provide advantages. Cached static content can be leveraged to reduce the delivery time to consumers as well as the load on content producers and network links. Cached dynamic content can be leveraged by network for multicast communications or retransmissions after packet losses. On the other hand, cached contents raise several privacy issues, since any router can infer sensitive information about those [START_REF] Chaabane | Privacy in content-oriented networking: Threats and countermeasures[END_REF].

Furthermore, the NDN architecture supports an additional form of shared persistent storage, namely a repository, which has been developed to answer a common need among dierent distributed applications. A repository represents a shared data-set which needs to be synchronized among distributed participants. A repository, which includes a list of namespaces, is essentially a data-set of contents. This storage, which is usually more persistent and larger-volume than a CS, has been used so far to support les or keys sharing.

Finally, the NDN community is currently investigating dierent storage models, le-system or database like, to design standard method for applications to discover, trust and write to dierent kinds of persistent storage in the network.

Security and Privacy

The NDN comes with built-in security since a mandatory signature binds the name to the content in every Data packet. Therefore, once a Data is emitted in the network and is signed by the producer private key, its integrity is guaranteed and the content cannot be tampered. In fact, the signature and some additional information about the publisher identity (see the Data packet format illustrated in Sec. 1.2.2) can be used by consumers to verify the Data provenance too.

In this model, the trust is decoupled from the network and is left to applications to authenticate entities and grant those with privileges to perform operations.

The robustness of the NDN architecture can be theoretically evaluated against Internet's wellknown Denial-Of-Service (DoS) attacks. A seminal analysis of both resilience to existing attacks and architecture-specic vulnerabilities was presented in [START_REF] Gasti | DoS and DDoS in named-data networking[END_REF]. NDN is resilient to the attacks targeting specic network endpoints, since it has no notion of address. Hence, attacks which ood victims with trac to saturate their resources, e.g., TCP SYN ooding attacks, cannot be carried out. Furthermore, attacks carried out by compromised routers advertising invalid routes, e.g., black-holing via prex hijacking [START_REF] Yi | A case for stateful forwarding plane[END_REF], can be detected and circumvented by the NDN's adapative forwarding plane.

Nevertheless, some inherent NDN features can be leveraged by potential attackers to mount novel DoS attacks. In fact, the architecture has so far showed to be vulnerable to attacks which capitalize on per-packet state and storage in NDN routers. In particular, routers can be overowed with malicious requests aiming to stop them from serving legitimate requests. Those malicious requests aim to occupy routers' available resources, mainly the PIT space. This attack is commonly identied with the term Interest Flooding Attack and is extensively covered in Chapter 3. A second kind of NDN-specic threat relates to contents cached by routers. Data packets are all signed, so their validity can be ascertained by signature verication. However, line-rate signature verication of every Data is technically impracticable in routers. Moreover, even though consumers can verify signatures and so detect fake content, they do not have mean to ask routers to ush some contents from their caches. The two above conditions favor attackers to pollute routers' caches with fake content which is both fetched by consumers and stored in network caches. This attack is commonly referred to Content Poisoning [START_REF] Ghali | Needle in a haystack: Mitigating content poisoning in named-data networking[END_REF].

With regard to privacy, some NDN features enhance some privacy aspects. For instance, the absence of addresses makes impossible to identify source and destination entities of a communication in any point of the network. Nevertheless, the presence of caches and the use of human-readable names may reveal information about the requested Data. Indeed, NDN suers from the same general privacy issues other Information-Centric architectures are aected with, which have been briey described in 1.1.4. In fact, the semantic correlation between names and contents can be exploited to unveil or guess the payload of Data packets by only looking at names. Then, this information can be benignly used to prole users' requests or maliciously to censor some trafc. Further, cached contents are not encrypted by default. Thus, it is the responsibility of the content producer to prevent the content from being eavesdropped. However, the latter task is not easy, since plain cryptography would hinder the usefulness of the in-network caching for the encrypted contents.

Transport Layers?

The NDN architecture does not foresee any transport-layer protocol since most of the services provided by that layer have been spread across dierent other components. Usually a transport protocol builds upon a network protocol to provide delivery from a process on a machine to another process on a dierent machine with a certain reliability. Further, a transport layer provides abstractions to the applications to use the implemented delivery services. In the following, typical services implemented in a transport protocol (see Chapter 6 of [START_REF] Tanenbaum | Computer Networks[END_REF]) are analyzed in the context of the NDN architecture.

Addressing Congestion Control -Congestion control mechanisms deal with machines sending too many packets and too quickly in the network since this sort of behavior can cause network congestion and by consequence performance degradation. Although congestion occurs at routers, it is under the responsibility of both transport and network protocols to avoid it. Therefore, in IP networks, mechanisms to control congestion are implemented at both layers (for example, the Explicit Congestion Notication (ECN) ag bits in the IP header and the Additive Increase Multiplicative Decrease (AIMD) control law of the TCP protocol). Network congestion is a phenomenon that persists even in NDN networks. Nevertheless, since traditional congestion control mechanisms are designed for host-to-host connections, those cannot be directly leveraged by the connectionless NDN architecture. Moreover, the design of congestion control mechanisms for NDN has to take into account additional factors like in-network caching and multi-path forwarding. There have been so far several proposals of congestion control algorithms for NDN, a summary of the related work can be found in [START_REF] Ren | Congestion control in named data networkinga survey[END_REF].

API to the application layer -A proposal of a Consumer-Producer API for NDN exists and was rst presented in a technical report in 2014 [START_REF] Moiseenko | Consumer-Producer API for Named Data Networking, the NDN project team[END_REF] and then rened in [START_REF]Consumer-producer api for named data networking[END_REF]. Although the denition of this API is an ongoing process driven by the design of new applications, the current one already sets out two main requirements. First, the data transfer is controlled by properties of the namespace. Second, some Consumer and Producer requirements may be really dierent. So, the current NDN API denes two dierent programming abstractions: a Consumer context and a Producer one. The consumer context assists consumer applications to fetch contents under a certain prex name. While the producer context assists producer applications to perform data publishing under a certain prex name. Both contexts have options which can be used by applications to dene the parameters of the data transfer. For example, consumers may want to specify Interest selector elds or Interest retransmission policies; instead, producers may want to specify algorithms and key size for the signature of Data packets. Both contexts also supply callback functions to notify about events they may trigger.

Ongoing and future development

During the rst four years of the NDN's life, the research community had focused to address more fundamental questions like naming, scalable routing and forwarding on names, content-oriented security models [START_REF] Zhang | Named Data Networking Tech Report 001[END_REF]. Those dierent research questions were addressed within a consistent architectural framework. After that, throughout the next two years of the Next-Phase NSF award [START_REF] Fia-Np | Collaborative research: Named data networking next phase[END_REF], the research on NDN focused on the validation and the renement of the conceived architecture on dierent network environments through the design of several key applications.

The explored network environments were enterprise building automation and management systems (as test-case, the large Siemens building monitoring system deployed at the UCLA university facilities [START_REF] Shang | Securing building management systems using named data networking[END_REF]) and mobile health (as test-case, the Open mHealth non-prot patient-centric open platform to share clinical data [START_REF]Open mhealth, the rst and only open standard for mobile health data[END_REF]). Those environments had been selected to address two of the national priorities of the NSF, namely Health IT and Cyber-physical systems. With regard to the application design, the fruition of digital media through mobile devices like smartphones, laptops, vehicles, a.k.a. Mobile Multimedia, was selected. Both network environments and applications have been chosen since they characterize environments and communication patterns that a data-centric architecture could serve better than the current host-based TCP/IP architecture.

Those use cases have improved the status of the NDN architecture on dierent aspects with a special focus on namespace design, name-based access control, trust management, distributed synchronization of data-sets, routing and forwarding, congestion control. In the meantime, this phase of research has also outlined open issues which still deserve more investigation, e.g., producer mobility support [START_REF] Zhang | Kite: a mobility support scheme for NDN[END_REF], encryption-based access control [START_REF] Yingdi | Name-Based Access Control, the NDN project team[END_REF], a distributed always-on lookup service [START_REF] Afanasyev | NDNs: A dnslike name service for NDN[END_REF].

ICN enablers

Running ICN protocols in today's networks would require either to have all the network equipment to be "ICN aware" or to design an overlay network upon the Internet's TCP/IP protocol suite. The former scenario is quite unlikely to happen in the near future since a forklift upgrade of a large fraction of the deployed network equipment on a global scale is literally no feasible. The second scenario requires statically congured IP tunnels necessary to implement ICN services in the overlay network which, by the way, imposes a certain shift from the original vision of a native in-network support of the ICN functionality. Overall, this barrier to upgrade or replace the existing infrastructure, and the consequent frustration of a possibly very long, even neverhappening, deployment contribute to generate some strong fear of impracticality about the ICN paradigm.

Nevertheless, over the last decade research on computer networks has produced technologies which can enable ICN deployments in a short term. In particular, the Software Dened Networking (SDN) [START_REF] Feamster | The road to sdn: an intellectual history of programmable networks[END_REF] paradigm has changed the way today's networks are designed and managed.

The SDN introduces the separation of the control plane from the data-plane in forwarding elements like switches and routers 4 . The former runs the logic which decides how to handle the network trac. The latter operates the forwarding of packets based on the decision made by the former. With SDN, a single software running in the control-plane can control the data-plane of multiple devices via standard Application Program Interfaces (APIs).

Today, the de facto standard SDN API is OpenFlow (OF) [START_REF] Mckeown | Openow: enabling innovation in campus networks[END_REF], which is supported by many products across dierent network vendors. The OF API follows a programming model where switches hold tables of packet forwarding rules. In the most basic form, each rule has a matching pattern and a list of actions which can be associated to the table entry. Actions implement protocol-specic packet editing operations and forwarding decisions. Actions are executed on a packet when that matches the corresponding rule. OF does not dictate how control plane programs should be written. However, SDN and OF have allowed operators to write control-plane programs so to address disparate control and management issues in their networks [START_REF] Kreutz | [END_REF].

In theory, SDN could facilitate the deployment of ICN features in today's networks without requiring any network equipment upgrade. In practice, today's SDN standards like OpenFlow mostly work with standardized host-oriented protocols. This implies that those SDN standards can be directly leveraged to program networks to handle novel content-oriented ICN protocols.

Two approaches can be followed to overcome this issue. The long-term one is to envision extensions of the current SDN standards to accommodate the ICN protocols [START_REF] Veltri | Supporting information-centric functionality in software dened networks[END_REF]. The short-term one is to use the existing SDN solutions to oer the ICN functionality [START_REF] Vahlenkamp | Enabling information centric networking in ip networks using sdn[END_REF][START_REF] Melazzi | An openowbased testbed for information centric networking[END_REF]. The former solution is hardly applicable because of the long extension process of the existing SDN standards and of the ongoing evolution of the current ICN protocols. The latter seems the viable approach since it only relies on commercial SDN-enabled elements compliant to established standards.

Several works [START_REF] Vahlenkamp | Enabling information centric networking in ip networks using sdn[END_REF][START_REF] Melazzi | An openowbased testbed for information centric networking[END_REF] have already investigated how ICN functions could be supported via today's OF switches. Since OF denes matches and operations on TCP/IP protocols' header elds, an ICN protocol's elds must be mapped to the available OF elds. In the existing approaches this is usually done by either specialized nodes (border nodes in [START_REF] Melazzi | An openowbased testbed for information centric networking[END_REF]) or a control plane logic as in [START_REF] Vahlenkamp | Enabling information centric networking in ip networks using sdn[END_REF]. The mapping is mainly meant to i) identify ICN trac in the networks, ii) carry information related to the ICN protocol, e.g., content names, iii) dene ow identiers. Flow identiers are used to set-up forwarding paths for both requests and responses in SDN-enabled elements. Those SDN-based approaches may also allow ICN trac to traverse non-SDN network segments [START_REF] Vahlenkamp | Enabling information centric networking in ip networks using sdn[END_REF]. Despite the design dierences, the solutions in [START_REF] Vahlenkamp | Enabling information centric networking in ip networks using sdn[END_REF][START_REF] Melazzi | An openowbased testbed for information centric networking[END_REF] achieve ICN deployments over traditional IP-based networks by leveraging the SDN paradigm.

In addition to the existing SDN standards, another set of recently emerging solutions to program the data-plane of the network forwarding elements represents a promising enabler for the ICN. In fact, nowadays, the design of switching chips undergoes a transition from Application Spec Integrated Circuits (ASICs) to fully-programmable chips. ASICs were believed to be the only way to achieve the latency required to perform packet processing operations at high network speeds.

Yet, ASICs produced xed-function switches, i.e., switches able to operate on a predetermined set of protocols elds with a small set of predened actions. However, recent studies [START_REF] Bosshart | Forwarding metamorphosis: Fast programmable match-action processing in hardware for sdn[END_REF] showed that fully-programmable switching chips can be designed for the same purpose. The data-plane of those chips can be programmed to support non-standard protocols and packet processing operations. The emergence of these new switching chips has also fueled the dialogue about the need for a common high-level language to program dierent kinds of forwarding elements (e.g., software and hardware switches, Network Processor Units, FPGAs) [START_REF] Bosshart | P4: Programming protocol-independent packet processors[END_REF]. The design of such a language targets protocol-and target-independence to write portable and modular network programs.

We believe that the latest generation of programmable switches and the related high-level languages will both i) in a long-term ease the deployment of ICN over existing networks, ii) in a short-term enable experimentation of ICN protocols at an unprecedented pace. Both technologies will overcome the limitations posed by today's SDN standards. First, the new switching chips could be congured to understand and process ICN protocols without devising cumbersome translation mechanisms to map those protocols to standard protocols as done with today's OFbased elements. Second, ICN designs could for the rst time be written in a easy and portable way. This latter characteristic is absent in the state-of-the-art ICN designs, which are tailored to specic hardware and software platforms instead. Existing designs are dicult to share, modify, improve and so, use for further research.

To promote this line of research, we have implemented NDN.p4 [START_REF] Signorello | p4: Programming informationcentric data-planes[END_REF], the rst NDN router design written in the high-level language for packet processors P4, which is illustrated in chapter 5.

Although NDN.p4 features a partial implementation of an NDN router, because of the early P4's language specication limitations, its design is simple and can be ported over multiple P4compliant platforms. The NDN.p4 showcases for the rst time a promising direction to advance the deployment in research and production networks of ICN forwarding devices. Chapter 2

Summary

Pending Interest Table

The original main purpose for a table of the pending interests has been stated in the seminal paper on Content-Centric Networking (CCN) [START_REF] Jacobson | Networking named content[END_REF]. A table recording Interests forwarded upstream to potential content sources is used to send Data packets downstream to nodes requesting them.

That The PIT's 1-to-1 Interest-Data mapping, initially conceived as a control ow mechanism inspired by the ancestor data-ack mapping in TCP, oers several additional benets. In fact, state in PITs can be used to ooad complexity in the design of multipath routing protocols (e.g., loops avoidance) to the data-plane. Or yet, measurements over PIT entries can be leveraged directly by the data-plane to track the performance of every Interest-Data exchange and dene adaptive forwarding behaviors. For example, unusually large RTTs or expired PIT entries can be used to detect and react to anomalies in the network like broken links, congestion or, worse, attacks [START_REF] Yi | A case for stateful forwarding plane[END_REF].

The software and hardware design of the PIT in NDN routers has been an open challenge since the early inception of the NDN architecture. Several design choices must be taken, e.g., the choice of the data-structure, the sizing of the table and, when in hardware, the placement on the forwarding element's line cards. Further, PIT designs must also consider the requirements of a possible Internet-scale deployment. According to the research done so far, it seems that the design of a PIT working at common link speeds is feasible with the current technology. However, the security threat opened by the PIT per-Interest state seriously questions the existence of this component in the data-plane of NDN routers. Therefore, alternative forwarding mechanisms are more and more recently emerging, aiming to preserve some of the main PIT properties while avoiding the related security issues.

The content of this chapter is organized as follows. Section 2.1 describes the generic datastructure by focusing on the information contained and the requirements. Section 2.2 focuses on the software and/or hardware requirements for the design of the data-structure. Section 2.3 discusses the main other design challenges. Finally, section 2.4 analyzes the direct and indirect properties of the PIT.

PIT Description

The operations performed by the NDN forwarding plane have been described in the Sec. The PIT records per-Interest state in the data-plane. The PIT state is also per-hop, that is, it is only local to a certain router. Therefore, if a router crashes, only its state gets lost and this does not directly aect any state in neighbor routers. The PIT state is cardinal to Data being delivered over the reverse path to consumers, yet it may also be used to dynamically perform real-time adaptation of the forwarding behavior to the network conditions. Although the soft state in PIT can be leveraged to design an adaptive forwarding plane, e.g., for robust packet delivery [START_REF] Yi | A case for stateful forwarding plane[END_REF] and simplied routing algorithms [START_REF] Yi | On the role of routing in named data networking[END_REF], NDN does not mandate any specic forwarding behavior per-se. The design choice of generality on the functions of the data-plane state was driven by past experiences with IP networks. In fact, there had been several previous attempts to introduce some state in the network, however, their coarse granularity did not make the state reusable for dierent purposes. For example, state stored to perform congestion control (e.g., the state needed by the eXplicit Congestion Protocol) was not compatible with the one required by a DDoS defense mechanism (e.g., the state needed by the Pushback mechanism for IP traceback) [START_REF] Yi | Adaptive forwarding in named data networking[END_REF]. Conversely, NDN stores datagram state, so achieving the nest possible granularity. Storing datagram state requires more resources yet gives the exibility to implement more functions.

Among the three main functional blocks of an NDN router, the PIT is the one which has the most stringent and critical update requirements. The FIB is updated with coarser frequency by routing protocols running in the slow path. Thus, modications to the FIB can tolerate a certain delay before becoming eective. The CS is updated by the forwarding plane. However, if any insertion or removal of content from the local cache is deferred, the consequences are either unnecessary upstream forwarding of a few Interests or replies containing outdated content. Conversely, PIT state changes must be performed almost instantaneously at line-rate since the processing of the next received Interest or Data packet may depend upon the updated state. Therefore, the design of the PIT is not trivial. Beyond the per-packet state update at line rate, the design also requires determining the size of the table according to dierent link loads and trac distributions.

Data structure

The key issue in the design of a data-structure for the PIT is the "exact string matching with fast updates" [START_REF] Yuan | Scalable NDN forwarding: Concepts, issues and principles[END_REF]. This problem refers to a membership verication for a string, the Interest name, in a set of strings, the names of the existing PIT entries. Further, the problem denition includes also i) insertions, when no PIT entries match incoming Interests, ii) removals, when Data packets consume existing PIT entries, iii) updates, when new nonce or interface or lifetime values have to be recorded in existing PIT entries.

High-speed exact matching on strings has been thoroughly investigated by the research on intrusion detection and ltering systems in IP networks. However, those systems do not consider the requirement of possible per-packet update. On the contrary, per-packet updates at line-rate are fundamental for the correctness of the NDN forwarding plane. Furthermore, content names may be very long and so require a lot of storage to be recorded together with additional forwarding information. For all the aforementioned reasons, some research has been done to address the more stringent requirements of exact string matching for the PIT in the NDN data-plane.

In summary, the design of a data-structure for the PIT is challenging because of the three following requirements:

• fast exact-match on variable length names: this has required a re-engineering of the stateof-the-art techniques which were mostly designed to deal with xed-length IP addresses.

Instead, NDN uses hierarchical human-readable names (HRNs) (see Sec. 1.1.2 of chapter 1 for a recap of this naming scheme). HRNs have variable length with no upper bound.

Those factors could cause a lookup time linear to the name length which could easily not meet the requirements of the NDN forwarding-plane for certain link speeds (several tens or hundredths of Gbps).

• per-packet lookup, insertion or update: all of these operations have to be performed with almost no delay since the processing of a next packet could be aected by the state change caused by the current one.

• per-content state information: a PIT table may require a considerable amount of memory to be stored. If URLs are considered in analogy to NDN names, today's URLs require several tens of bytes of storage per name. In addition to that, as detailed in Sec. 2.1 each entry records additional information about interfaces, nonces and performance measurements. Furthermore, the PIT size increases with the data-rate since more packets may be received on faster links. For example, at 100 Gbps, packets may have an arrival rate of a few nanoseconds. Those tight packet inter-arrival times mandate PIT designs to target data-structure which all or partially reside in small on-chip memories, like SRAM or RL-DRAM. Those high-speed memories are overly expensive and so space-limited.

Generally, a PIT design aims at two main improvements: i) shrinking the data-structure size and ii) reducing the average access time by also determining exactly the worst case one. PIT design should be guided by some additional observations as seminally outlined in [START_REF] Yuan | Scalable NDN forwarding: Concepts, issues and principles[END_REF]. First, the structure of NDN names can be leveraged in the design. Names are made of components and matches are dened at the component-level rather than at the character-level. This point can guide the renement of existing techniques which were originally meant to work at the character granularity. Second, even though there is no theoretic limit to the number of components in a name, it is foreseeable that in real networks there would be such an upper bound. Therefore, the maximum number of components for most names (for example, some related works report that most URLs have less than 30 name components) can be used to dene heuristics which achieve constant times with certain name distributions. Third, it is better to consider simple data-structures because of the requirement of the possible very fast per-packet update. A very little time from one packet to the other seems to preclude the utilization of any complex highlynested data-structure. Fourth, the role and position of a forwarding device in the network can be used to relax the PIT requirements. In fact, while backbone routers must sustain higher loads than edge routers, the former ones can perform more aggregation without risking to break the Data packet delivery [START_REF] Yuan | Scalable pending interest table design: From principles to practice[END_REF]. Three dierent kind of data-structures have been so far proposed in the state-of-the-art works: name prex trie based, bloom-lter based, hash table based. The classication reported in [START_REF] Piro | Understanding the social impact of icn: between myth and reality[END_REF] has been hereby extended.

Name Prex Trie (NPT) based

The Name Prex Trie (NPT) is a data-structure inspired by the binary trie for IP prex lookup, which capitalizes the hierarchical structure of names and the component-level granularity of the longest prex matching in NDN. The design of a PIT based on an NPT data-structure was rst proposed in [START_REF] Dai | On pending interest table in named data networking[END_REF] as further renement of an encoding technique for Name Prex Trie previously proposed in [START_REF] Wang | Scalable name lookup in NDN using eective name component encoding[END_REF].

The main idea of NPT is to represent NDN names through trees like the one in Fig. 2.2a. Every edge represents a component and every node represents a lookup state. The reader could be wondering about the rationale to use a data-structure giving visibility of the full name structure when only an exact match is required to lookup the PIT. Indeed, NPTs have been proposed as solution to implement a single index for the three main functional blocks of the NDN data-plane, i.e., CS, PIT and FIB. In fact, Fig. 2.2a shows that a non-empty lookup state may correspond to either a FIB entry or a CS one or a PIT one. The advantage is a reduction of the memory space to store a single index rather than three. The downside is the additional complexity of the data-structure required to support dierent kinds of read/write operations.

An NPT can be represented with a name character trie (NCT) [START_REF] Fredkin | [END_REF]. Nevertheless, character tries require a lot of memory to store states and transitions. Besides, they have an O(mn) computation for the LPM lookup in average (where m and n are the average number respectively of children per node and name length). Compression techniques can be applied at the name-component level to reduce the space needed to store the prex trie. Encoding rather than hashing techniques are preferred for compression by existing literature since the latter ones aect the correctness of routing because of collisions. Thus, for example, the prex trie in Fig. 2.2a could be encoded in a new trie showed in Fig. 2.2b, called Encoded Name Prex Trie (ENPT), where codes are assigned to name components. The representation with codes is already more compact than the one storing the characters. However, it can be further improved as detailed in [START_REF] Dai | On pending interest table in named data networking[END_REF][START_REF] Wang | Scalable name lookup in NDN using eective name component encoding[END_REF] where a Name Component Encoding (NCE) is proposed. Improvements of an NCE relate to the code allocation mechanism which aims to reduce the total number of codes, to the trie representation which is implemented by means of State Transition Arrays (STAs), to the algorithm to perform components' code lookup and to the management of the STAs for the insertion/removal/update operations.

In terms of complexity analysis, the NCE reduces the memory space to store an NPT and speeds up the lookup in the average case compared to the NCT. Experiments reported by [START_REF] Wang | Scalable name lookup in NDN using eective name component encoding[END_REF] compare the two data-structures on three data sets built using domain information from the D-MOZ, ALEXA and Blacklist public websites. For the biggest data set composed of around 3 million names, the average name length in bits is reduced by 75% after encoding the names with NCE.

The complete NCE representation through STAs saves around 20% over the NCT one. NCE memory requirements also grow more slowly compared to the NCT one. Thus, NCE turns to be more memory ecient on both small and large data-sets. In a followup work [START_REF] Dai | On pending interest table in named data networking[END_REF], a mapping method to infer size and access frequency required by a PIT on a 20Gbps link is proposed. The trace translation suggests some requirements in terms of number of entries and lookup/insertion/deletion frequencies which are all met by the NCE.

Despite the high compression rate and the lookup performance, the NPT has not been leveraged in any complete design of an NDN router yet. In fact, related work features either Bloom Filter based or Hash-based PIT designs whose characteristics are illustrated in the rest of this section.

0 00 00000000000000000000000000000000000000

Interest name insertion

I 1 = ndn.net/videos/talk1.mpg h 1 (I 1 )
BF of size m, initially all 0s 0 10 00010000000101000100000100001000010010 After inserting I 1 in the BF

h 2 (I 1 ) h 3 (I 1 )

Interest name check

Negative check, item not in the set

h 3 (I 2 ) h 2 (I 2 ) h 1 (I 2 ) 0 10 00010000000101000100000100001000010010 1 1 1 1 1 1 1 1 1 Figure 2.

Bloom Filter-based (BF-based)

A bloom lter (BF) [START_REF] Bloom | Space/time trade-os in hash coding with allowable errors[END_REF] is a memory-ecient data-structure for membership queries which suers from false positives. A standard or binary BF is represented by an array of m bits initially all set to 0. The BF uses k independent hash functions to map items of a set to the array m. An item is inserted in the lter by hashing it k times and setting the resulting 1 bits of every hash in the array m. To check if an item is in the lter, the item must be hashed k times and every time the 1 bit locations in the computed hashes must correspond to the ones in the array m. If at least one 1 bit position in any of the hashes corresponds to a 0 in the lter, then the item is surely not part of the lter. If all the 1 bits in the hashes correspond to the 1 bits in the lter, then either the item is in the set or it is a false positive. The false positive probability of a BF depends on the size m of the lter, the number n of elements in the set and the number k of hashing functions, so it can be tuned.

BFs If the second check is again positive, then the Interest is considered duplicate and so dropped.

If not, the Interest is regularly forwarded and later added to the shared bloom lter. Instead, the forwarding of Data only goes through the per-face lters. Data packets are supposed to be checked against all the per-face BFs except the one those are received at. The design includes an additional control-plane triggered mechanism to update the shared BF, which being a binary lter does not feature an automatic deletion mechanism.

Despite the positive evaluation results reported in [START_REF] You | Dipit: A distributed bloomlter based pit table for ccn nodes[END_REF], the DiPIT design fails to address some other PIT requirements which would make impossible to apply it without further renements.

For example, the DiPIT approach assumes PIT entries only store names and incoming interfaces when, as outlined in the list of general requirements for a BF-based design, there is additional information about nonces, outgoing interfaces and lifetime timers to be stored too.

Another BF-based PIT design, called MaPIT, is proposed in [START_REF] Li | Mapit: an enhanced pending interest table for NDN with mapping bloom lter[END_REF]. MaPIT mainly aims to reduce the on-chip and o-chip memory cost while keeping up with line-speed processing without incurring in high false positive rates. MaPIT is based on a data-structure, called Mapping Bloom

Filter (MBF), made of two main components: an on-chip Index Table and an o-chip Packet

Store. The index table records the presence and the address of entries in the set respectively through a BF and a Mapping Array. The packet store records information about the entry except the name, which is omitted. MaPIT achieves higher compression rates for tested data-set compared to hash table-based designs and to the trie-based NCE of [START_REF] Dai | On pending interest table in named data networking[END_REF]. Nevertheless, the description of the design presented in [START_REF] Li | Mapit: an enhanced pending interest table for NDN with mapping bloom lter[END_REF] does not detail how the critical issues above described in points (A) and (B) are addressed.

Overall, BF-based PIT designs pose some constraints on the placement of this data-structure on a device's line-cards, a design issue which is explained in Sec. 2.3. Moreover, any BF-based design must be complemented by subsidiary data-structures. In fact, nonces and timers must be stored in each entry to guarantee loop detection and entry expiration.

Hash Table based (HT-based)

Since more than a decade HT-based systems and algorithms have been extensively investigated for wire speed network processing. The reasons for such an increasing research interest are some of the promising conclusions drawn by related theoretical research. A foremost theoretical nding is that there exist simple hash functions which perform similarly to theoretical fully random hash functions and that can be implemented eciently. That and other theoretical results have nally led to ecient software and hardware implementations for practical applications in areas like packet forwarding, load balancing and network monitoring.

In hash tables, the time to lookup a particular item is expected to be constant on average. However, hash tables suer from collisions, i.e., multiple items can be assigned to the same bucket.

Hence, some lookup performance may dier from average till a certain worst case time. In what follows three dierent HT-based PIT designs are presented with the aim of giving an overview of the state of the art. Those designs had been driven by slightly dierent goals. On the one hand, the schema proposed in [START_REF] Varvello | On the design and implementation of a wire-speed pending interest table[END_REF] by Perino et al. targets an hardware implementation of the single PIT component. On the other hand, the schema in [START_REF] So | Named data networking on a router: Fast and dos-resistant forwarding with hash tables[END_REF] targets a software design for a full NDN data-plane. Finally, the schema proposed in [START_REF] Yuan | Scalable pending interest table design: From principles to practice[END_REF] targets an Internet scalable design, which is motivated by the infeasibility of state-of-the-art pure HT-based PIT designs for core router speeds.

In [START_REF] Varvello | On the design and implementation of a wire-speed pending interest table[END_REF], the authors analyzed two HT-based solutions to implement the PIT: linear chaining hash-table (LHT) and open-addressed d-left hash-table (DHT). Both solutions store full PIT entries and can support deletions. The space needed by each kind of data-structure is illustrated in Fig. 2.4. In particular, under the assumption to allocate 48 bits to store an entry's subsidiary information, LHT requires 112+l bit per entry, while DHT requires 80+l bits, where l is the content name length in bits. The additional 32 bits required by the LHT schema are due to the pointer needed to implement the chains as linked lists. In [START_REF] Varvello | On the design and implementation of a wire-speed pending interest table[END_REF], the two HT-based designs are compared in terms of memory footprint under some assumptions about the length of the content names and the number of PIT entries. The number of entries is theoretically computed for 10 and 5 . As a further result, DHT seems to be more resilient to the trac load growth. While, other data-structures degrade the more the load approaches the worst case. The bottom line in [START_REF] Varvello | On the design and implementation of a wire-speed pending interest table[END_REF] is that DHT seems to be the more promising solution among the data-structures compared to (CBF, DHT, LHT, ENPT). Moreover, DHT suits to dierent placements on a device's line-card while sustaining trac up to 10 Gbps as conrmed by a prototype implementations on a Cavium network processor.

In [START_REF] So | Named data networking on a router: Fast and dos-resistant forwarding with hash tables[END_REF], a software design for a complete NDN forwarding engine is proposed and tested on a target platform. The proposed HT-based design has been optimized to perform operations for all the main data-plane functional blocks, i.e., CS, PIT and FIB. This design is based on a compact representation of a chained hash table. Further, it only uses a single hash function because that must be computed on all the prexes of each name for forwarding purposes. An illustration of that schema is shown in Fig. 2.5. The chaining hash table is implemented as a compact array of buckets rather than as regular linked list. The objective of this representation is to minimize data cache misses during lookup since those introduce memory stall cycles. Every bucket contains seven compact entries, made of the hash of an entry name and the pointer to the full entry.

The name hash is stored instead of the full name in the bucket so to avoid string comparison to all the entry in a bucket. String comparison to the full name is only done when the stored hash matches the content name one. Moreover, some pre-fetching of the HT buckets is done to further reduce the number of data cache misses. This design envisions further optimization of the PIT lookup operation. In fact, the PIT can be partitioned and partitions can be assigned to dierent cores/threads so for those do not conict on resources and fully exploit the parallelism on multi-core/multi-threaded systems. For the second optimization to work, Interests and Data related to the same entry must be assigned to the same PIT partition. This last requirement is met by assigning packets to a partition based on full-name hashes. From the reported evaluation, the throughput of the NDN forwarding engine is minimally aected by dierent PIT sizes, yet its performance drops when the HT load factor (#entries/#buckets) is greater or equal to 8.

The full router design of [START_REF] So | Named data networking on a router: Fast and dos-resistant forwarding with hash tables[END_REF], which is implemented on the Integrated Service Module (ISM) of a Cisco ASR 9000 router, achieves an average throughput of 8 Mpps when running on multiple cores (The reader should be aware that some of the latest NDN router designs proposed [START_REF] Kirchner | Augustus: a ccn router for programmable networks[END_REF][START_REF] Takemasa | Toward an ideal NDN router on a commercial o-the-shelf computer[END_REF] can achieve higher throughput respectively of 10 and 40 Mpps on o-the-shelf hardware).

Another HT-based schema is proposed in [START_REF] Yuan | Scalable pending interest table design: From principles to practice[END_REF], where the PIT is implemented as a d-left hash The list of faces is a bit vector of the same size of the number of available interfaces on a certain device.

The analysis of the memory size of this PIT design is highly dependent on the ngerprint distribution. In particular, it is important to derive an upper bound on the number of duplicate Interests since those will increase the lifetime of the relative PIT entries. Such an upper bound is computed in [START_REF] Yuan | Scalable pending interest table design: From principles to practice[END_REF] and is used to perform a worst case analysis on the memory size for this PIT design. According to the analysis in [START_REF] Yuan | Scalable pending interest table design: From principles to practice[END_REF], the dlCBF design's size seems to be of the order of 40MiB in the ideal case, which would t in on-chip SRAM memories, while it seems to be around 250 MiB in the worst case, which would instead mandate the use of RLDRAM memories.

Nevertheless, storing ngerprints instead of full names in PIT entries compromises the basic services at NDN routers, that is, Interest aggregation and multi-cast Data delivery (see Sec.

2.1). Therefore, any ngerprints-based PIT design should be complemented with additional mechanisms so as to guarantee the correctness of the above basic PIT services.

Design challenges

Beyond the choice of a data-structure, there are other factors which must be considered when designing a PIT:

1. First and foremost, the appropriate PIT size should be determined since insucient PIT space leads to Interests to be dropped. A PIT has to be large enough to sustain the trac rate carried on the device's links across static and dynamic cases in dierent network settings. Because of the tight resource constraints in the design of architectures for NDNcompliant network equipment, overprovisioning PIT space is not considered a viable option.

Further, PIT has preferably to reside on fast memory to cope with certain link speeds. This problem is usually referred to sizing or dimensioning.

2. Second, although NDN is a clean-slate proposal, it has not been assumed yet to redesign current routers architecture. By consequence, the NDN data-plane must be implemented on existing routing/switching architectures. The abstract NDN data-plane assumes the existence of globally accessible tables which, however, are not present in the majority of current routing/switching architectures. In fact, most routers have several line-cards, usually connected through a high-speed crossbar switch-fabric, containing the interface logic for a data link. Then, every line card has a forwarding engine CPU with non-shared memory resources leading to the question of where to store information about the PIT so that it can be accessed consistently by several line-cards' CPUs. This problem is usually referred to placement.

3. Third, assessing the scalability of a certain PIT design could become critical when NDN has to be deployed either at Internet scale or in resource-constrained networks. At a rst glance, this issue could be considered analogous to the PIT sizing. However, dimensioning the PIT does not yield any universal design, rather it provides general guidelines and resource bounds. Once boundaries are known, moving "from principles to practice" [START_REF] Yuan | Scalable pending interest table design: From principles to practice[END_REF] could require additional design trade-os, e.g., the choice of a certain data-structure over another and/or changes to the normal data-plane operations to achieve packet processing at a certain line-speed.

4. Last but not least, security of any proposed PIT design must be thoroughly assessed since the PIT constitutes a functional block of core network elements. In NDN, normal user's requests create and modify PIT entries in routers. Unfortunately, user's misconducts can be really disruptive. They cannot be predicted a priori and can be achieved via legitimate means. Thus, the possible attack surface has to be limited at design time.

Sizing

Compared to literature on the design of a data-structure for the PIT, the understanding of the required PIT size as a function of the system parameters has received much less attention. Theoretically, such size could be estimated as a function of two components, the data-rate of the router's links and the average time entries last in the PIT. assertion in [START_REF] Wählisch | Backscatter from the data plane threats to stability and security in information-centric network infrastructure[END_REF] is that the estimated lower bound for the number of PIT entries should hold for any router where it is only a function of its interface capacities and of the average time an entry remains in the table (similar assumptions were held in [START_REF] Perino | A reality check for content centric networking[END_REF] which, however, led to a dierent estimate of the number of entries).

A more empirical analysis is presented in [START_REF] Dai | On pending interest table in named data networking[END_REF], where a one-hour trace of a 20Gbps link is used to estimate PIT size and access frequency. That work details a method to map TCP/UDP connections for a common set of Internet applications (e.g., HTTP, FTP, P2P applications, email services) to NDN Interest/Data exchanges. The mapping method is used to identify and group ows in the trace, which are related to the same applicative data exchange, and then to convert them to PIT operations. In terms of size, the proposed mapping method produces 1.5 M PIT entries for the main applications (that is, excluding network management protocols and domain name resolution messages). Furthermore, read, insertion and deletion frequencies are estimated through ows behavior too. So, for example, the emergence of a new ow is considered as a PIT insertion, while the disappearance is considered as a PIT deletion. The computed lookup, insert and delete frequencies account respectively for 1.4 M/s, 0.9 M/s and 0.9 M/s (Million per second). Although the work lacks a theoretical model and the mapping method is highly arguable, it still makes a valid point about the dierent nature of Internet services which generate dierent PIT access patterns.

Finally, the work in [START_REF] Caroglio | Pending interest table sizing in named data networking[END_REF] Hereby some of the main ndings of [START_REF] Caroglio | Pending interest table sizing in named data networking[END_REF] are reported:

• in the static case (constant number of parallel ows), there is a strong correlation between the status of the queue on a bottlenecked link and the PIT sizes on the nodes downstream it.

• the PIT size in routers downstream a bottlenecked link does not depend on the bottlenecked capacity rather on the number of parallel ows.

• experiments suggest that proper settings in a congestion control algorithm can be used to reduce the PIT size while fully exploiting the link capacity. In the dynamic case (number of ows dynamically changing during the experiment), correlation between queues at bottlenecked links and PIT size in routers is still present. Moreover, the PIT size at a certain router grows as a function of the load on the upstream bottlenecked link.

In a realistic ISP topology, the model is used to estimate the PIT size for three network equipment with very dierent links fan-out in dierent networks: an optical line terminator (OLT) in the access network, an IP edge router in the backhaul network and a router of the backbone.

Overall, the estimated PIT size never seems to make the design of the component unfeasible.

OLT's PIT stays very small (less than one thousand entries in the very worst case where all the ows are bottlenecked upstream the OLT) and depends on the ows bottlenecked upstream. More importantly, the latest state-of-the-art work on PIT sizing [START_REF] Caroglio | Pending interest table sizing in named data networking[END_REF] has generally dismantled concerns and estimates raised by previous related works. Further, that work has undoubtedly advanced the general understanding of the memory requirements for this NDN data-plane component. Nevertheless, for the sake of simplicity, the derived analytical model is based on assumptions that may not be necessarily true in every network scenario and, so, whose impact should be better studied too. For example, client requests are expressed assuming there is an optimal congestion control mechanism regulating them, or, no other management schemas, e.g., to mitigate DoS attacks, are considered either.

Placement

The work in [START_REF] Varvello | On the design and implementation of a wire-speed pending interest table[END_REF] provides a good overview of the dierent PIT placement options on router's linecards. Therein, an analysis of the pros and cons of each approach is presented and, moreover, a novel placement schema is conjectured to address issues with the state-of-the-art solutions.

Hereby those options are recapitulated assuming, for the sake of simplicity, that device linecards can be logically separated in two categories: input and output.

Input-only placement [START_REF] Li | Compression of pending interest table with bloom lter in content centric network[END_REF][START_REF] You | Dipit: A distributed bloomlter based pit table for ccn nodes[END_REF] Output-only placement [START_REF] Dai | On pending interest table in named data networking[END_REF] PIT tables are only placed on each output-line card. Interests do not create PIT entries at input line-cards where those are just looked up to the FIB. Rather PIT tables are stored on output-line cards. This approach xes issues with Interest aggregation and loop detection the input-only placement is aected with. However, it requires a FIB lookup per-Interest and it shows limitations in case of multi-path. The former issue matters since it may introduce unnecessary FIB lookup when a PIT entry is already present on some output card.

The latter issue is present if there exist multi-path FIB entries. In fact, those routing entries create separate entries on dierent output line-cards which then will possibly receive and switch internally multiple times the same Data packets. This latter issue can be further worsened by cases where a forwarding strategy module decides upon the available forwarding options and may alternate output cards leading to much more inconsistency among the PITs on dierent output cards. This last scenario aects the ability to detect loops and retransmissions since dierent nonces may be stored in dierent output line-cards' PITs.

Input-Output placement [START_REF] Dai | On pending interest table in named data networking[END_REF]: this placement suggests PIT entries should be created on both input and output line-cards for every forwarded Interest. This placement does not create any unnecessary FIB lookup. However, it suers from a multi-path Data replication issue analogous to the one described for the output-only placement. Thus, multiple Data packets may be internally switched through the input line-cards if PIT entries were previously created at dierent output line-cards. Furthermore, this placement increases of a factor of two the required number of PIT lookup operations.

Third-party placement [START_REF] Varvello | On the design and implementation of a wire-speed pending interest table[END_REF]: this placement steers every received Interest to a dedicated linecard based on the content name hash. The selected line-card holds the PIT for all the received Interests. At Data reception, the output-line card identies the related line-card by using the same hash function on the Data name. The Data is forwarded to the designated card. On the one hand, this placement introduces additional in-router switching operations both at Interest and Data reception. On the other hand, it does not experience the issues with loop detection and multicast delivery the other placements do.

Scalability

The deployment at the Internet scale of NDN requires routers being able to operate NDN packet processing at high line-speeds. Above certain link speeds, the inter-arrival packet translates to a very few nanoseconds to process a single packet. As known in routers, memory access aects the packet processing more than combinatorial logic. Thus, tight execution times make the number of allowed memory accesses very limited. This imposes additional constraints to the PIT design too.

As evidence of this issue, the work in [START_REF] Yuan | Scalable pending interest table design: From principles to practice[END_REF] shows how the state-of-the-art HT-based PIT implementations may not meet the requirements of backbone routers. In fact, the required memory to sustain tens of interfaces at 100 Gbps is estimated to be around 500MiB, which would oblige to implement HT-based PIT on o-chip DRAM memory. However, the required packet processing speed would not tolerate multiple read/write operations on o-chip memories. Storing compressed lters on small SRAM chips has been showed by the related work on high speed packet processing to be a valuable resource to save DRAM accesses. Along the same line, the work in [START_REF] Yuan | Scalable pending interest table design: From principles to practice[END_REF] proposes a PIT design which stores ngerprints instead of full content names at core routers and reduces the number of required DRAM accesses per PIT operation. However, storing ngerprints incurs two main issues, namely, collisions and duplicates. Collisions happen when two dierent Interest names produce the same ngerprint and hash bucket index. Interest duplicates are a normal phenomenon, which, however, become dicult to detect since those are 2.4. Properties identical to collisions. The colliding Interest should be forwarded, while the duplicate one should be dropped. So, as can be guessed, this design needs some renements to deal with those two side eects. For example, the work in [START_REF] Yuan | Scalable pending interest table design: From principles to practice[END_REF] describes as the aggregation of requests for popular contents in edge routers, caching and adaptive forwarding behaviors can be leveraged to address and/or limit the aforementioned issues. Further, it identies the consequences in terms of network and memory overhead generated by those collateral eects and measures via simulation the ngerprint collision rates.

Security: security in PIT design entails many aspects. First, the PIT is subject to userdriven modications. So, in theory, PIT designs should be resilient to any possible users' misbehavior. However, in practice, the PIT design can already be driven by some well-known security threats. For example, a DDoS aiming to overload PIT resources has already been identied and characterized by some related research [START_REF] Afanasyev | Interest ooding attack and countermeasures in named data networking[END_REF][START_REF] Wählisch | Backscatter from the data plane threats to stability and security in Information-Centric Networking[END_REF][START_REF] Compagno | NDN interest ooding attacks and countermeasures[END_REF], so resilience to those existing threats should be considered at design time. Second, with regard to the data-structure, HT-based PIT implementations seem to be the mainstream choice. Therefore, a careful choice of the hashing function is vital to reduce the hash computation and bucket lookup time. Otherwise, certain hash functions could expose routers to hash ooding attacks aiming to generate many collisions so as to degrade the average lookup performance. Finally, the PIT represents the status of the requests processed by a certain router at anytime. Thus, snapshots of the PIT state can be misused for censorship or monitoring purposes. This naturally raises questions about the information revealed through this component and the degree of privacy which should be guaranteed.

The above-discussed four issues and the choice of the data-structure covered in Sec. 2.2 account for some mainstream problems in the PIT design space. Additional secondary requirements, e.g., the PIT entry timeout and the Interest retransmission policies, may further inuence the design of this component.

Properties

The previous section has outlined challenges in the design of a Pending Interest The multi-path ability enabled by the PIT enables probing multiple interfaces in parallel and possibly discovering new "best" paths. Further, ooading loop-detection mechanism in the dataplane also relaxes complexity in the design of routing algorithms leading to the exploration of solutions considerable unfeasible before [START_REF] Yi | On the role of routing in named data networking[END_REF].

Hop-by-Hop ow balancing: the PIT guarantees that on each link one Interest brings back no more than one Data. This strict 1-to-1 Interest-Data mapping naturally allows the routers to control the load over their links. Furthermore, this ow balance guarantee can be leveraged to design in-network congestion control mechanisms [START_REF] Mahdian | Mircc: Multipath-aware icn rate-based congestion control[END_REF] by assuming the content/interest size ratio on a certain link can be estimated (as done by the Interest shaper mechanism in [START_REF] Wang | An improved hop-by-hop interest shaper for congestion control in named data networking[END_REF]).

Adaptive forwarding capabilities: the presence of per-packet state in the NDN data-plane can be leveraged to implement adaptive forwarding behaviors as forwarding strategies (see Sec. 1.2.2 of Chapter 1) at the network layer. In IP, routing protocols exchange information about available routes and compute best paths from sources to destinations according to link costs and policies.

The routing information is later made available as table entries that the data-plane forwarding logic dumbly follows. Whenever path changes happen because of planned routing updates or unexpected network failures, routing protocols converge to a new set of valid paths by exchanging update messages and adapt to the topological network changes. However, routing convergence takes a certain time and may yield to some side eects like routes oscillation and destination unreachability, particularly in the presence of short-term connectivity losses [111]. Instead, the NDN architecture leaves the semantics of the PIT state undened. The granularity of the for- [START_REF] Afanasyev | Interest ooding attack and countermeasures in named data networking[END_REF][START_REF] Wählisch | Backscatter from the data plane threats to stability and security in Information-Centric Networking[END_REF][START_REF] Gasti | DoS and DDoS in named-data networking[END_REF]. The severity of IFAs for NDN-like networks and the questionable ecacy of the proposed solutions threaten the stateful forwarding plane existence in ICNs [START_REF] Ghali | Living in a pit-less world: A case against stateful forwarding in content-centric networking[END_REF].

The aim of the work presented in this chapter was to avoid premature conclusions on the ecacy of the state-of-the-art countermeasures against IFAs. In fact, while several countermeasures had been proposed to mitigate this kind of attack, overall, simplistic assumptions widely used in the evaluated attack scenarios risked to provide erroneous, either promising or deceptive, ndings.

First, the quasi-totality of the existing countermeasures are reactive, i.e., the mitigation of an attack inevitably starts after a time interval in which routers collect statistics about the processed trac. Second, the evaluation scenarios for those countermeasures often assume malicious and legitimate Interests belong to trivial disjoint prex sets and/or use randomly-generated content identiers to generate requests for non-existent contents. The former makes these countermea-

IFA in NDN networks

The NDN data-plane makes the architecture resilient to many of the DoS attacks aecting the current Internet [START_REF] Gasti | DoS and DDoS in named data networking[END_REF][START_REF] Yi | A case for stateful forwarding plane[END_REF]. NDN packets do not contain physical addresses yet content names. Therefore, attackers can not aim to exhaust specic endpoints' resources like in today's application-level ooding attacks. Further, routers accept Data only when solicited by previous related Interests. Thus, prospective attackers can hardly ood unsolicited Data through the network like in today's reection attacks in IP-networks.

Meanwhile, the NDN has been shown to be vulnerable to some totally new attacks which capitalize on architecture-specic features [START_REF] Gasti | DoS and DDoS in named data networking[END_REF]. Among other features, the presence of per-Interest PIT state in NDN introduces some security threats. In fact, since PIT modications are packet driven, tailor-made packets and packet generation frequencies may be misused to overload routers and content providers with unnecessary processing or to exhaust their resources, e.g., tables memory or CPU cycles. As consequence, regular trac will suer from a degradation of performance at best or from a denial of service at worst.

An Interest Flooding Attack (IFA) consists of a large number of closely time-spaced Interests emitted by a pool of nodes to overload the network infrastructure and/or content providers. It is generally an attack which capitalizes on the possibility of raising computation at providers and consuming resources at routers by emitting a large amount of content requests.

Attack Genealogy

Preliminary evidence of the IFA vulnerability, as well as of the possibility to easily exploit it, was shown in [START_REF] Wählisch | Backscatter from the data plane threats to stability and security in Information-Centric Networking[END_REF]. Among several vulnerabilities identied therein, the authors showed that resource exhaustion on routers can be achieved by issuing a large number of Interests for nonexistent content. However, the term Interest ooding was coined for the rst time in [START_REF] Zhang | Named Data Networking Tech Report 001[END_REF] to identify an attack mirroring traditional DoS attacks by sending large numbers of Interests hard to aggregate and be served by caches. A more precise denition was later given in [START_REF] Gasti | DoS and DDoS in named-data networking[END_REF], where the attack goal to overow routers' PIT is also clearly stated. Finally, the rst seminal proof that IFAs can severely disrupt network services was proven empirically in [START_REF] Compagno | NDN interest ooding attacks and countermeasures[END_REF] where a modest number of attacking nodes sharply decreased the throughput delivered to legitimate consumers.

General Characteristics and IFA types

The kind of Interests used to generate an attack can be used to characterize an IFA in terms of attacker's goals and consequences for consumers, producers and network infrastructure. A preliminary tentative taxonomy was presented in [START_REF] Gasti | DoS and DDoS in named data networking[END_REF] and then resumed in [START_REF] Signorello | Advanced interest ooding attacks in named-data networking[END_REF] Interests, while collusive producers delay at maximum the delivery of the corresponding Data packets [START_REF] Salah | Evaluating and mitigating a collusive version of the interest ooding attack in NDN[END_REF]; iii) IFAs performed by a botnet of malicious users issuing malicious yet valid interests for dynamic content, called DoS-signing attack in [START_REF] Alston | Neutralizing interest ooding attacks in named data networks using cryptographic route tokens[END_REF], so to overload content producers with an excessive generation of content signatures.

Attacker model

This work introduces a robust attack model with attacker capabilities and goals described in the following. Furthermore, Table 3.1 summarizes the attack impact on dierent targets and the Interest type that can be used to achieve it. The summary also outlines that an attacker may decide to shape the attack with dierent Interest types in order to achieve dierent results.

Attacker capabilities -Interests are regular requests expressed by users without any specic privilege. Hence, controlled end-hosts are sucient to launch an IFA and no control over the network infrastructure is required. However, according to [START_REF] Compagno | Poseidon: Mitigating interest ooding DDoS attacks in named data networking[END_REF], a botnet of infected enddevices generating FIs can maximize the attack ecacy. Wherein, no router is compromised nor misused to intensify or make more ecient the attack.

In general, IFA attackers have the following capabilities:

• ability to produce Interests for existent and non-existent content,

• some knowledge about detection techniques operated in routers,

• ability to aect multiple targets at the same time by means of certain Interest types and dierent prex names,

• ability to inuence trac metrics monitored by routers.

Attacker goals -IFAs may be targeting either content providers or the network infrastructure or both. So far it has appeared that they can achieve the following eects: 7 As outlined in [START_REF] Gasti | DoS and DDoS in named-data networking[END_REF], some Interest packet header elds can also be used to create MIs. For example, dierent

Nonces can be misused to refresh the expiration time of the same PIT entry; while the PublisherPublicKeyLocator eld can be used not to fetch cached contents and direct all the requests to target content sources. However, the analysis of the feasibility and the ecacy of IFAs based on the above packet elds has not been investigated in literature yet.

Interest Name

R3

FIs dropped Aected routers are across the path to the content provider. Thus, as a result, Legitimate Interests (LIs) may be frequently dropped by some router whose PIT is full (e.g., routers R4 and R5).

• the exhaustion of routers' resources. Especially, they tend to fully occupy the PIT space causing further Interests to be dropped.

• the overload of requests on target providers. In order to be more ecient, such requests should ask for existent contents since those require more computation from the provider, e.g., signatures generation. Instead, FIs can be more easily ltered out by content producers.

• the saturation of network links due to a certain asymmetry in size between Interests and Data packets. Although this requires colluding parties performing the attack or asking for many dierent existent contents, ooding with Interests upstream links may cause Data packets received downstream to saturate the bandwidth.

IFA countermeasures and good practices

Since the identication of the IFA, a considerable amount of research has been devoted to the assessment of the severity of the attack and to the design of countermeasures to prevent it. The majority of the countermeasures against IFAs feature a two-phase, detection and mitigation, defense mechanism. The detection phase aims to identify the attack source (generally, a specic interface) and/or target prex names. While the reaction, which is triggered by a successful

IFA detection

The detection of an attack is based on the periodic observation of some metrics that can suggest anomalous trac patterns. Although, the metric denition and the granularity of the monitored time window may vary from a countermeasure to another, the construction of the attack indicators is based on roughly the same set of information. In fact, so far, none of the previous works on IFAs fetches information from the Content Store (CS) to monitor the router's status, a few of them [START_REF] Wang | Detecting and mitigating interest ooding attacks in content-centric network[END_REF] propose to use modied FIB entries, but most of them analyze PIT activities for the same purpose.

Both percentage of expired Interests and PIT usage may be periodically observed to detect IFAs.

On one hand, routers know precisely whether every forwarded Interest is satised by a Data or expired after a timeout because of the strict NDN ow balance principle ("in absence of packet losses, one Interest packet results in one Data packet on each link" [START_REF] Zhang | Named data networking[END_REF]). Therefore, an unusual number of expired Interests over forwarded ones along a certain time window certainly indicates the presence of anomalies on certain paths in the network. In fact, metrics like the Interest Satisfaction Ratio (ISR) in [START_REF] Afanasyev | Interest ooding attack and countermeasures in named data networking[END_REF], which is dened as the ratio between expired Interests over satised ones, or the ratio of incoming Interests over outgoing Data in [START_REF] Tang | Identifying interest ooding in named data networking[END_REF] are monitored to detect an IFA. Less precisely, counters on expired Interests can work as similar indicators [START_REF] Wang | Detecting and mitigating interest ooding attacks in content-centric network[END_REF][START_REF] Wang | Decoupling malicious interests from pending interest table to mitigate interest ooding attacks[END_REF]. On the other hand, information about the PIT usage provides an indication of the trac load managed by a router at a certain time. Therefore, abnormal utilization of the PIT space is also employed to detect network anomalies. For example, PIT size in bytes is monitored in [START_REF] Dai | Mitigate DDoS attacks in NDN by interest traceback[END_REF][START_REF] Compagno | Poseidon: Mitigating interest ooding DDoS attacks in named data networking[END_REF], while, PIT utilization rate over the entire PIT or per prex name are monitored respectively in [START_REF] Wang | Cooperative-lter: countering interest ooding attacks in named data networking[END_REF] and in [START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF][START_REF] Salah | Evaluating and mitigating a collusive version of the interest ooding attack in NDN[END_REF].

Overall, both ISR-oriented and PIT-oriented metrics are good indicators of anomalies in the network, yet assuming the related ratios are computed over meaningful time windows and interpreted conjunctly. Nevertheless, both detection metrics require to dene threshold values to trigger alarms when exceeded. Ideally, thresholds are dynamically adjusted to reect the net-work status like in [START_REF] Compagno | Poseidon: Mitigating interest ooding DDoS attacks in named data networking[END_REF]. In reality, most of the times threshold values are based on empirical observations which are inevitably biased by a very few topologies and trac distributions used in the evaluation settings [START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF].

Lastly, a very dierent approach is taken in [START_REF] Nguyen | An optimal statistical test for robust detection against interest ooding attacks in ccn[END_REF][START_REF] Nguyen | Detection of interest ooding attacks in named data networking using hypothesis testing[END_REF] where strong assumptions (i.e., Interest/-Data arrival rates on the router's interfaces and packet-loss rate) on the trac distributions of Interest and Data packets are made to build a statistical framework based on the hypothesis testing theory. Although those results seem promising, since they would allow to have a detector whose precision would only depend on the number of samples and the desired probability of false alarms, those assumptions seem to make that approach unsuitable for any real deployment.

IFA mitigation

With regard to the mitigation mechanisms, dierent reactions can be performed locally at each router:

• rate limits of accepted Interests can be enforced on interfaces based on dierent parameters, e.g, expired Interests per FIB-record [START_REF] Wang | Detecting and mitigating interest ooding attacks in content-centric network[END_REF], at access routers [START_REF] Dai | Mitigate DDoS attacks in NDN by interest traceback[END_REF], explicit alerts received on neighbor routers [START_REF] Compagno | Poseidon: Mitigating interest ooding DDoS attacks in named data networking[END_REF][START_REF] Afanasyev | Interest ooding attack and countermeasures in named data networking[END_REF], physical link capacity [START_REF] Afanasyev | Interest ooding attack and countermeasures in named data networking[END_REF].

• detection and mitigation can be consolidated in a single phase, e.g., the satisfaction-based mechanisms of [START_REF] Afanasyev | Interest ooding attack and countermeasures in named data networking[END_REF] use the ISR as the probability to forward or drop Interests.

• those prex names, which are detected as target of an attack, can be processed dierently to prevent them from generating state in the PIT, as done, for example, in [START_REF] Wang | Decoupling malicious interests from pending interest table to mitigate interest ooding attacks[END_REF].

Nevertheless, forwarding decisions taken independently at every router suer from two issues as empirically proven by related work in [START_REF] Afanasyev | Interest ooding attack and countermeasures in named data networking[END_REF][START_REF] Compagno | Poseidon: Mitigating interest ooding DDoS attacks in named data networking[END_REF]. First, they cause overreaction [START_REF] Afanasyev | Interest ooding attack and countermeasures in named data networking[END_REF], that is, Interests are unnecessarily checked multiple times by the same defense mechanism on all the routers along the path from a consumer to any producer (for example, in Fig. 3.1, the routers R3-R4-R5 along the path from the user to the wikipedia content provider may independently apply their own defense mechanism). Overreaction increases the probability of dropping malicious Interests over a certain network path, meanwhile it lowers the probability of forwarding legitimate Interests from one source to a destination [START_REF] Afanasyev | Interest ooding attack and countermeasures in named data networking[END_REF]. Second, a decision local to a router does not necessarily detect or mitigate the attack globally. In fact, the eect of the attack is expected to be stronger in the proximity of producers of contents for a targeted prex name (see the diameter of the circles around routers R4 and R5 in Fig. 3.1). While, routers which are more distant from those target producers (e.g., router R1 in Fig. 3.1) may carry malicious trac as well but not be able to detect it properly.

For the above reasons, collaborative 8 defense mechanisms [START_REF] Dai | Mitigate DDoS attacks in NDN by interest traceback[END_REF][START_REF] Compagno | Poseidon: Mitigating interest ooding DDoS attacks in named data networking[END_REF][START_REF] Wang | Cooperative-lter: countering interest ooding attacks in named data networking[END_REF][START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF][START_REF] Afanasyev | Interest ooding attack and countermeasures in named data networking[END_REF] result to be more ecient. In fact, in collaborative techniques, the dissemination of routers' local status allows defense mechanisms to be triggered even where the attack eect is not suciently strong to be detected (e.g., in Fig. 3 alert messages produced by router R4 may trigger mitigation at R1).

Three dierent collaborative techniques are hereby briey described, while a summary of their characteristics and dierences is provided in Table 3 In Distributed Poseidon (DP) [START_REF] Compagno | Poseidon: Mitigating interest ooding DDoS attacks in named data networking[END_REF], routers monitor the PIT usage and ISR values per incoming interface and issue alarms to their downstream neighbors when observed values exceed their respective thresholds. DP aims to propagate downstream information about a possible attack as close as possible to its source. An alarm message announces a new rate limit on a certain interface and an aected namespace. Propagated alerts are used by traversed routers to lower their respective detection thresholds. The idea of pushing back notications, which is also leveraged by the TraceBack countermeasure proposed in [START_REF] Dai | Mitigate DDoS attacks in NDN by interest traceback[END_REF], is inspired by previous work on DDoS detection in IP routers [START_REF] Mahajan | Controlling high bandwidth aggregates in the network[END_REF][START_REF] Ioannidis | Implementing pushback: Router-based defense against ddos attacks[END_REF].

Coordination Monitoring (CNMR) 9 [1] envisions the deployment of specialized routers which are meant to closely monitor the forwarding of Interest packets within the same Autonomous System. Those monitoring routers may either detect an attack through the analysis of local statistics or rely on explicit indications provided by a centralized controller, which collects reports about suspicious activities from all the monitoring routers. At each monitoring router, detection is triggered by anomalous PIT usage and ISR values per-prex name, while reaction is implemented as a probabilistic forwarding based on the related local ISR values.

Moreover, the monitoring routers avoid overreaction issues by agging previously monitored Interests for no further inspection. Globally, a ratio of expired Interests is computed over all the monitoring nodes by the controller per every reported prex name. If the overall ratio exceeds a certain threshold, then the controller alerts the monitoring routers that certain prex names could be the target of an ongoing attack.

Evaluation

Evaluation metrics -The metrics commonly observed to validate both the impact of an attack and the ecacy of a countermeasure are the amount of resources consumed in routers and the average quality of service perceived by nal consumers. The former usually relates to PIT space and computation resources like CPU cycles. The latter usually relates to both download time and number of contents retrieved. A successful attack increases sharply the load on routers and degrades clients experience. While, an eective countermeasure shields routers from being overloaded and guarantees a certain quality of service to clients.

An indicator of the quality of service perceived by nal consumers can be obtained by looking at the percentage of satised Interests over the expressed ones. Among the existing literature works, this metric seems to be considered more than the average download time. As regards the routers, both consumed resources as PIT space, and throughput as number of content packets forwarded in the unit of time, are measured.

Content names -Legitimate consumers and attackers issue Interests with specic content names which, however, either are sporadically reported in or whose importance is underestimated by related literature. The name sets used for the evaluation of countermeasures in previous works are reported in Table 3.3. Those works are classied in three dierent categories. The largest portion of the previous works, which are listed in the row "unreported", provide no information about the content names. A further division in two subcategories is applied to the works which report about used content names, either in their publications or in the related publicly available implementations. On one hand, the subcategory "disjoint sets" lists the works using dierent prex names for attackers and legitimate consumers. On the other hand, the subcategory "nondisjoint" lists the works assuming malicious Interests and legitimate ones may be expressed with the same prex name.

As for the content name composition, in the vast majority of works, where reported, content names consist of only two name segments, one segment for the routable prex name and one for the content identier. The prex name is usually a short string, whether mimicking some original domain name, like "/google.com/", or aiming to be self-explanatory, like "/good/" to indicate that Interests with that prex are legitimate. As regards to the content identier, the consumer applications provided by the widely used ndnSim simulator [128] use integers. Unreported [START_REF] Nguyen | An optimal statistical test for robust detection against interest ooding attacks in ccn[END_REF][START_REF] Nguyen | Detection of interest ooding attacks in named data networking using hypothesis testing[END_REF][START_REF] Compagno | Poseidon: Mitigating interest ooding DDoS attacks in named data networking[END_REF][START_REF] Compagno | NDN interest ooding attacks and countermeasures[END_REF][START_REF] Dai | Mitigate DDoS attacks in NDN by interest traceback[END_REF][START_REF] Salah | Evaluating and mitigating a collusive version of the interest ooding attack in NDN[END_REF] Reported disjoint [START_REF] Afanasyev | Interest ooding attack and countermeasures in named data networking[END_REF][START_REF] Wang | Detecting and mitigating interest ooding attacks in content-centric network[END_REF][START_REF] Wang | Decoupling malicious interests from pending interest table to mitigate interest ooding attacks[END_REF] non-disjoint [START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF] Simulation Environment -Throughout the literature on IFAs, several network topologies have been used to evaluate the proposed countermeasures on a network simulator (for the sake of completeness, it must be said that there are also some techniques which have been evaluated

on real network topologies [START_REF] Compagno | NDN interest ooding attacks and countermeasures[END_REF]). Among the simulated topologies, there are simple ones and more realistic ones. On one hand, testing on a simple topology constitutes a canonical rst step towards a more complete evaluation and can help convey general ideas about the characteristics of a proposed approach. Instead, larger and more complex topologies explore more realistic network scenarios. Countermeasures against IFAs have been often evaluated on a set of topologies inferred by the [START_REF] Spring | Measuring isp topologies with rocketfuel[END_REF] work which can be imported in the ndnSim network simulator environment [128].

Pitfalls

Some of the design aws in the state-of-the-art defense mechanisms, which are outlined in this section, inspired the design of more eective IFAs which are described in Sec. 3.3. Most importantly, the here-reported ndings constitute a general handbook of good practices for the design and evaluation of future countermeasures.

Detection -As explained in Sec. 3.2.1, the presence of FIs has so far been identied by monitoring the ISR and/or PIT usage in routers, yet both detection metrics present some downsides: • abnormal PIT usage values may be also caused by network conditions where the load grows more easily, e.g., bursts of Interests or congestion; therefore, an overloaded PIT itself does not provide any indication about the kind of Interests which populate the PIT.

The above issues might be overcome by conjunctively analyze both metrics. For example, in [START_REF] Compagno | Poseidon: Mitigating interest ooding DDoS attacks in named data networking[END_REF] routers assume low ISR values may avoid false alarms when trac peaks generate a high, yet legitimate, PIT usage. However, attackers can still inuence the ISR-based metrics and stay undetected even under heavy PIT load conditions, as achieved, for example, by the rst IFA variant of Sec. 3.3.3.

Finally, detection metrics are observed over a certain time window and, beyond that, should be ideally applied to a prex name granularity to penalize less legitimate trac. This implies respectively that i) any reaction happens with a certain delay, ii) specic prex names have to be rst identied as infected. Both conditions can be potentially exploited by attackers to remain undetected. For example, attackers in the second attack variant presented in Sec. • they often require reserved prex names and ad-hoc data-plane modications (e.g., see the column "Protocol changes" of Tab. 3.2). For example, routers in [START_REF] Compagno | Poseidon: Mitigating interest ooding DDoS attacks in named data networking[END_REF] exchange unsolicited Data packets or routers in [START_REF] Dai | Mitigate DDoS attacks in NDN by interest traceback[END_REF] generate spoofed Data to trace an attack back to its closest source. Those practical requirements limit any straightforward deployment of proposed solutions and impede their interoperability.

• they introduce overhead, e.g., for inter-router communication, in-router storage and analysis of detection metrics, which is not always considered and reported in the evaluation of the countermeasures.

• they may counter-productively disseminate wrong information when detection metrics are purposely polluted by the attackers.

Evaluation -The evaluation of works in the subcategory "disjoint sets" of Tab. Moreover, using simplistic names as content identiers in the simulation environment represents a risk of underestimation of several operations done for packet processing [START_REF] Yuan | Scalable NDN forwarding: Concepts, issues and principles[END_REF]. In fact, although the size of the PIT entries, which will be eventually determined by a specic PIT implementation, could be independent of the Interest name size, longer content names are denitely going to inuence many other processing tasks performed in routers and by content providers. Overall, at the time being the precise implications of the content name composition on the evaluation of countermeasures against IFAs stay unexplored. Nevertheless, the IFA using Wikipedia page titles, which is presented in Sec. 3.2.3, has shown to be more ecient compared to the more simplistic models previously adopted by the related literature.

Flooding an imaginary NDN-based wikipedia

Flooding an imaginary NDN-based wikipedia

NDN content names for Wikipedia pages

As outlined in Sec. 3.2.4, related works on IFAs have so far neglected the importance of the name sets used for the evaluation of their proposed countermeasures. In contrast, more realistic sets of content names are important for two reasons. First, those allow research to better quantify the resources needed by routers and the impact of an attack whose main purpose is to abuse them.

Second, they help simulate and test more realistic attack scenarios where attackers produce dicult-to-detect fake Interests (FIs) to dissimulate their attack.

In the attack model presented in Sec.

IFA on an NDN-based Wikipedia server

A novel Interest Flooding Attack targeting a specic NDN content provider has been proposed in [START_REF] Signorello | Advanced interest ooding attacks in named-data networking[END_REF]. The attack is named pure IFA (pIFA) and some more ecient attack variants (described in 3.3.3) can be also easily mounted by slightly varying the attackers behavior. The pIFA attack assumes NDN contents holding similar naming property of DNS names. Namely, content names from the same content provider follow a naming scheme which make them semantically related, as shown in [START_REF] Marchal | Semantic exploration of dns[END_REF]. A pIFA models the structure of content names for a targeted provider using the available related set of existent content names. The model is later used to generate new and non-existent content names following the provider naming scheme.

By choosing Wikipedia as target content provider, pIFA attackers can download the full list of existent contents since that is publicly available. Wikipedia page titles are composed as follows: "word 1 _word 2 _..._word n " with n ∈ [1, x] where word i is meaningful. New names for Wikipedia pages can be created via DISCO [START_REF] Kolb | DISCO: A Multilingual Database of Distributionally Similar Words[END_REF], which is a generator of semantically related words. Given an input word w and a number m, DISCO returns a maximum of m most related words to w. Using an existing seed content name w, attackers generate the list l 1 of 200 most related words to w, e.g., the words "computing, hardware, desktop, etc." are generated from the existing Wikipedia content name "computer". The word generation process is launched a second time on each word obtained in l 1 with parameter m = 200 to produce a second word list l 2 . Each obtained word in l 1 and l 2 can be used as content name for a malicious Interest by the attacking nodes in a pIFA. For sake of completeness, it must be said that this generation process produces less than 200 + 200 × 200 = 40, 200 new words since seed names and duplicates are deleted from l 1 and l 2 and only unique words are considered.

The pIFA in [START_REF] Signorello | Advanced interest ooding attacks in named-data networking[END_REF] uses a xed number of attacking nodes holding each a list of 5,000 seed Wikipedia content names. Each node generates o-line content names for malicious interests using the above-described generation technique. Generated existent content names are discarded since the full list of existent contents is publicly available for the Wikipedia use-case. The o-line generation process produced 180,800 new content names per node on average, from which 50.3%

were non-existent. to remain undetected and/or lower the probability for their malicious Interests to be dropped.

Attack variants

The chameleonic IFA (cIFA) includes attackers which change the target valid prex name after a certain time window. The decision about the change of a target prex name may be probabilistic or driven by the observation of the content retrieval latency. The goal of a cIFA is to avoid prex name based mitigation which is generally applied by countermeasures after an observation window where certain name prexes are marked as infected.

Evaluation

This section reports results obtained from the evaluation of three collaborative state-of-the-art countermeasures against the IFAs introduced in Sec. The simulation settings reported in Sec. 6B of the work in [START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF], which are briey summarized in Sec. 3.4.1, have been replicated for the sake of comparison to related work. In particular, the experiments in [START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF] have been taken as reference since the CNMR countermeasure, therein proposed, happens to be the latest defense mechanism overperforming previous state-of-the-art countermeasures. The countermeasures have been evaluated against the pIFA, the bIFA and the cIFA of Sec.

Set-up and Metrics Set-up

The network topology simulated is the same as in [START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF], that is, the Exodus ISP (AS 3967) inferred by the Rocketfuel project [START_REF] Spring | Measuring isp topologies with rocketfuel[END_REF]. In every simulation scenario, 25% of the total number of client [1] and [START_REF] Compagno | Poseidon: Mitigating interest ooding DDoS attacks in named data networking[END_REF] respectively on.

Metrics

The impact of the novel IFAs of Sec. 3.3.2 and 3.3.3 is evaluated on two metrics which have been widely used in the related works (the rationale behind the evaluation metrics for IFAs was already introduced in Sec. 3.2.3). First, the Interest Satisfaction Ratio (ISR) at clients, which is computed as the ratio between satised Interests and issued ones over a time window, gives an indication of the quality of service perceived by end-users while the network is under attack. Second, the PIT utilization ratio (PUR) reports about the available capacity on routers to process legitimate trac during an attack. The PUR is computed as the ratio between the number of PIT entries and the maximum PIT size in entries over a time window.

State-of-the-art (SoA) results

As rst evaluation step, the experiments presented in [START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF] have been replicated, where only the countermeasures CNMR and SBP were evaluated The ISR values for the ND and the CNMR scenarios, plotted in Fig. 3.2a, are 10 to 20% higher than the ones in [START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF]. Fig. 3.2a also shows that SBP and DP worsen the ISR compared to the baseline. This last behavior was only reported in [START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF] for higher attack frequencies. Indeed, this result was expected since SBP and DP apply rate limits of accepted interests on interfaces detected as infected independently from the aected prex name. Meaning that, when multiple prex names are used in the evaluation, as done for the experiments in [START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF], SBP and DP may accidentally drop many Legitimate Interests. CNMR, dierently, mitigates only the prex names which are detected as infected. Therefore, CNMR overperforms SBP and DP in this evaluation scenario because the former never drops legitimate Interests with other prex names except the one under attack 11 .

With regards to the PUR plotted in Fig. 3.2b, none of the countermeasures alleviates the average PIT consumption in routers contrary to what reported in [START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF]. This would be expected for SBP and DP, which would allow more malicious Interests to occupy PIT space across the network since they do not mitigate the attack eciently as already shown in Fig. 3.2a (low eciency of SBP in large network topologies with many attackers was already reported in [START_REF] Afanasyev | Interest ooding attack and countermeasures in named data networking[END_REF]). Nevertheless, as additional outcome of an aggressive dropping policy which highly aects the ISR perceived by clients, SBP/DP also reduces the number of Interests gaining PIT space in the network. As can been seen in Fig. 3.2b, SBP/DP curves only slightly increase the PUR compared to the baseline.

As regards CNMR, the average global PIT usage is slightly higher (less than 5% more) than the one measured in the ND scenario. It must be said that results in [START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF] reported a lower average PUR compared to the baseline under attack when the countermeasure is on. The thereby-reported behavior was not seen in any simulated scenario by this work nor the authors of [START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF] were able to provide the correct information to replicate those results when contacted about this. A consistent behavior of CNMR with regard to the PUR has been observed by this work with all the tested attack frequencies (e.g., the plot in Fig. 3.3a shows PUR values for 500, 1k and 10k ipps with 11 Almost all the curves reported in this section present a periodic artifact occurring at around 100, 200 and 300 seconds of the simulation time. It is extremely dicult to precisely pinpoint the root cause of this eect because of the many variables involved in the simulation scenario. Nevertheless, we have measured a strong correlation between the total number of duplicate Interests produced and this periodic variation of the ISR and PUR curves. Although the content identiers for the Interests are generated by using random functions in the network simulator fed with dierent seeds, there is an overall decrease rst and increase after of the total number of duplicates around those time windows. and w/o defense mechanism on). The same pattern holds if only monitoring routers' PITs are considered, as shown in Fig. 3.3b. Indeed, it must be said that an increase of the average PIT utilization ratio through the activation of the CNMR defense mechanism is not unexpected. Yet, the higher PIT usage is due to a notable path stretch increment introduced by CNMR's ad-hoc forwarding strategy. In fact, CNMR steers every Interest rst towards the closest monitoring router in order to maximize trac coverage (see description of the MR-Aware Routing in Sec.

V-B of [START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF]).

The plots in Fig. 3.3, as well as all the other PUR plots of this section, report the PUR average values. This was meant to ease the comparison to the results reported by the CNMR work in [START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF]. Nevertheless, the average PUR values computed over either all routers of the topology or all the CNMR's monitoring routers may not visualize clearly an attack's impact. In fact, the PIT usage of the reported experiments oscillates between 0.2 and 0.6. That is, the attacks seem to never saturate any router's PIT, yet the attacks are able to aect the ISR measured by the clients. Indeed, the tested attacks saturate several routers' PITs and this can be seen more easily by observing the PIT load of the monitoring routers under attack in the following plots.

The plots in Fig. 3.4 show the impact of an IFA with 1000 ipps on the PIT load of the monitoring nodes in a single experiment (not average reported this time, since every round of simulation corresponds to dierent positions in the network for both clients and attackers). The 1000 ipps attack frequency is already sucient to saturate the PIT of some of the monitoring routers as better shown by Fig. 3.4c and 3.4d (see red and yellow curves) where the network is under a pIFA. Further, the monitoring routers are often some hops away from the clients. So, those clients' Interests may need to traverse rst other routers before reaching any monitoring router.

Those routers' PITs could be already heavily aected by the attack. Similarly, this is observed also with the state-of-the-art experiments in [START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF], as reported in Fig. 3.4a and 3.4b, where, however, the measured impact is lower.

Attack results

Pure IFA -pIFA

In the evaluated pIFAs, attackers generate Interests only for non-existent contents by fetching invalid content identiers from o-line generated lists of spoofed names. Meanwhile, legitimate users only produce Interests for existent contents referring to the original Wikipedia page titles list. Furthermore, all the content consumers, legitimate and malicious ones, use the same single routable prex name. Both above conditions did not hold in the SoA experiments of [START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF].

The measured ISR values are reported in Fig. 3.5a (for the sake of clarity, from now on the DP curves are omitted since the relative values are very similar to the SBP ones). As in the SoA experiments, SBP poorly mitigates the attack, while CNMR improves this metric compared to the baseline. It also important to see how the SBP countermeasure (blue curve) worsens the attack eect compared to the baseline (green curve). The low ISR average value caused by SBP is due to its aggressive dropping policy applied to the aected interfaces. Comparing the SoA results in Fig. 3.2a to the ones in Fig. 3.5a, the pIFA introduces a 17% decrease of the ISR values for both the baseline scenario and the CNMR one. This result conrms that the novel attacker model leads to more eective attacks compared to the ones used in the evaluation of the related works.

Blended IFA -bIFA

The ISR values of the bIFA scenario are reported in Fig. 3.6a. In bIFAs, attackers also generate Interests for existing contents (a xed percentage of the attack frequency per second, called purity level ) with the aim to reduce the number of expired Interests monitored by routers. Fig. 3.6a

shows a 22% ISR decrease of the SoA results and a 5% decrease of the pIFA ones for CNMR.

Moreover, pIFA attackers' behavior totally neutralizes this countermeasure. In fact, the CNMR curve always lays above the baseline in Fig. 3.6a. The eciency of the SBP technique is reduced too in case of bIFA, since the detection metric monitored by the routers is polluted and allows more fake interests to create entries in the PITs. In Fig. 3.6b the PUR values for CNMR are plot, the attack succeeds at occupying more space across monitoring routers' PITs, as a consequence of the poor detection achieved by the applied countermeasure.

It is also important to see how the ecacy of a bIFA increases with the increment of the number of legitimate Interests used by the attackers. Fig. 3.7a shows a decrease of the ISR for CNMR when the bIFA's purity level increases, while Fig. 3.7b shows a small increment of the PUR values when the attack's purity level is increased.

The ecacy of a bIFA is a consequence of the forwarding decisions taken independently at each monitoring router. In fact, although the successful detection made by the CNMR controller node, the monitoring routers' local statistics (see denition in Sec. 3.2.1) are used as probability to either forward or drop every Interest with the detected prex name. Therefore, the legitimate Interests issued by pIFA attackers improve routers' local statistics and, by consequence, the probability for Fake Interests to occupy PIT space and be forwarded to the next hops.

Chameleonic IFA -cIFA

In cIFAs, the attackers either know or guess (e.g., by emitting and measuring the RTTs of some legitimate Interests) the observation time window used by detection techniques in routers. The attackers' goal is to avoid prex name-based mitigation techniques (e.g., the CNMR of [START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF]). For that purpose, attackers switch the target prex name at every observation window.

The impact of cIFAs has been evaluated in scenarios where content producers serve several prex As regard to the PUR of CNMR's monitoring routers, shown in Fig. 3.8b, the values are consistent with the ISR ones, showing an increase of the former metric when the latter one is reduced.

Nevertheless, cIFA generates a PIT increment of the baseline which is smaller than the one caused by the bIFA reported in Fig. 3.6b. The impact on the average PIT utilization of monitoring routers under the dierent attack scenarios is summarized in Fig. 3.9b. Table 3.4 recapitulates the impact achieved by the dierent attacks on both the evaluation metrics considered. Overall, the cIFA causes the worst ISR at clients as reported in the rst two columns of Tab. 3.4. However, the cIFA is not the attack variant which generates the highest load on routers for all the countermeasures. In fact, the bIFA variant causes higher PUR when CNMR is on, as reported in the third column of Tab 3.4. Therefore, the ultimate choice between bIFA and cIFA could be driven by knowledge available to the attackers (e.g., ability to guess observation windows used by routers' defense mechanisms) and desired targets (either clients or network infrastructure or both). The state-of-the-art IFA countermeasures have been dissected. Flaws in the current mainstream defense approach and in the evaluation settings have been outlined. The proposed attacker model and the analysis of the state-of-the-art countermeasures have been used to build new stealthy IFA attacks. These attacks have revealed the inecacy of the state-of-the-art countermeasures 3.5. Summary to protect the clients and the network infrastructure under more realistic attack scenarios.

The ndings reported in this chapter show the limitation of the existing IFA defense mechanisms against a novel set of steadier IFAs. Therefore, these results call for dierent and more robust countermeasures to be designed in order to protect the NDN architecture from this attack. For that reason, a novel approach to the defense against IFAs is presented in the next chapter.

Chapter 4

Proactive defense against Interest Flooding Attacks

Interest Flooding Attacks (IFAs) represent a major open security threat to the Named-Data Networking architecture. In IFAs, loosely coordinated botnets of attackers may exhaust routers' resources and deny service to legitimate users. Countermeasures may be applied to mitigate this attack, yet those suer from several drawbacks making their potential deployment either nonecient or unfeasible. First, most of the proposed countermeasures introduce ad-hoc protocol changes and/or make unrealistic assumptions about the control of the network infrastructure so impeding any seamless integration in existing deployments. Second, the best state-of-theart countermeasures introduce monitoring overhead and perform a delayed reaction because of their intrinsic reactive nature. The reactive nature of a countermeasure can be exploited by the stealthy attacks proposed in Chapter 3 to circumvent defense mechanisms active in routers and achieve the attacker's goal. Finally, all the state-of-the art countermeasures are not designed to discern between legitimate and malicious Interests, so they inevitably penalize legitimate trac too. This latter issue is usually underestimated by the related literature which only considers the average performance at clients achieved with the application of a certain countermeasure.

Though an improvement of the average quality of service perceived by clients could not be sufcient for a certain class of applications which do not tolerate too many closely spaced packet losses, e.g., the stream of multimedia content.

The design of existing countermeasures against IFAs is based on the assumption that an Interest packet itself does not contain the necessary information to distinguish between legitimate and malicious Interests. Therefore, other factors have to be analyzed to determine the nature of an Interest. For example, the NDN ow balance principle ("one Interest packet results in one Data packet on each link" [START_REF] Zhang | Named data networking[END_REF]) is used to detect anomalous percentages of unsatised Interests [START_REF] Afanasyev | Interest ooding attack and countermeasures in named data networking[END_REF].

Or yet, assumptions about the trac distribution are used by statistical models to dene the conditions for an ongoing attack [START_REF] Nguyen | Detection of interest ooding attacks in named data networking using hypothesis testing[END_REF]. Instead, this chapter shows that under some circumstances an Interest name is sucient to determine its either malicious or benign nature. This assumption, though restricted to a certain case, eliminates the vulnerability exposed by reactive countermeasures since no monitoring of previous trac is required to make forwarding decisions.

Further, this work also shows that a specic proactive design is able to preserve legitimate trac from being erroneously dropped. In fact, this specic design leverages bloom lter-based content summaries which generate no false negative, that is, no legitimate Interests can be mistaken for a malicious one and so dropped. Both factors are showed by extensive simulations against the latest steady attacks proposed in [START_REF] Signorello | Advanced interest ooding attacks in named-data networking[END_REF] which neutralize previously proposed IFA countermeasures.

Issues with Reactive Countermeasures

Chapter 3 has already discussed the state of the art on countermeasures against the IFA. The main aim of that rst survey was to highlight pitfalls in existing defense mechanisms which could be leveraged to build stealthy attacks. The survey presented this time in Sec. 4.1.2 outlines an intrinsic characteristic, the reactiveness, of all the most eective state-of-the-art countermeasures since that is indeed the root cause of the pitfalls identied in those defense mechanisms. Before, Sec. 4.1.1 describes the main Interest type used by attackers in IFAs, which has oriented the design of the related countermeasures.

A core strength of IFAs: Fake Interests

An eective IFA DoS consists of ooding the network with a large amount of Interests with the aim to overload routers and content sources with unnecessary processing. Attackers' means and goals may vary as clearly summarized in [START_REF] Signorello | Advanced interest ooding attacks in named-data networking[END_REF] and reported in the previous chapter. A botnet of loosely coordinated clients generating requests hard to be aggregated and served by caches can be used to maximize the attack's ecacy. For that purpose, attackers mainly generate Fake Interests (FIs). A FI is a unsatisable Interest since it does not corresponds to any existent content. FIs names can be easily generated by appending random identiers to valid routable prex names as shown in Fig.

A novel Taxonomy for IFA countermeasures

The classication of approaches to defend against IFAs presented in Sec. 3.2 of Chapter 3 mainly focuses on a certain class of countermeasures which, in reality, represent a subset of all the existing defense mechanisms. A more comprehensive classication of the countermeasures against the IFA DoS has been proposed by [START_REF] Tourani | Security, privacy, and access control in information-centric networking: A survey[END_REF]. The hereby presented taxonomy leverages some terminology from the work in [START_REF] Tourani | Security, privacy, and access control in information-centric networking: A survey[END_REF], but proposes a dierent classication of the existing approaches.

More specically, two main sub-root categories are introduced in the taxonomy of Fig. 4.2 to classify existing IFA countermeasures: reactive and proactive. The adjective reactive is used to identify countermeasures which respond to attacks only after those have already taken place.

Potential symptoms of an IFA are an excessive load on PITs, an anomalous number of expired Interests, an unexpected increase of the number of incoming Interests. Therefore, monitoring of any or all of these factors is required by reactive countermeasures to detect potential ongoing attacks. While, the adjective proactive is used to identify countermeasures which anticipate an attack. The nature of every Interest, either legitimate or malicious, has to be determined before forwarding it to anticipate an attack. So, forwarding decisions have to be taken only by looking at the Interest packet elds.

As it can be seen in Fig. 4.2, among the related works the above-denition of proactiviness cannot be applied to any existing countermeasure. In fact, the majority of the existing countermeasures rely on the observation of some previous trac and so those are considered reactive according to the above-dened classication criteria. There exist a few other approaches which are not considered reactive since they do not perform any monitoring: i) alternative forwarding mechanisms, ii) client's proof-of-work ones. The "client's proof-of-work" category identies

Root

Reactive Others Statistical modeling [START_REF] Mahajan | Controlling high bandwidth aggregates in the network[END_REF][START_REF] Ioannidis | Implementing pushback: Router-based defense against ddos attacks[END_REF] Rate Limiting Collaborative [START_REF] Afanasyev | Interest ooding attack and countermeasures in named data networking[END_REF][START_REF] Compagno | Poseidon: Mitigating interest ooding DDoS attacks in named data networking[END_REF][START_REF] Dai | Mitigate DDoS attacks in NDN by interest traceback[END_REF][START_REF] Wang | Cooperative-lter: countering interest ooding attacks in named data networking[END_REF][START_REF] Nguyen | An optimal statistical test for robust detection against interest ooding attacks in ccn[END_REF] Independent [START_REF] Gasti | DoS and DDoS in named data networking[END_REF][START_REF] Wang | Detecting and mitigating interest ooding attacks in content-centric network[END_REF][START_REF] Tang | Identifying interest ooding in named data networking[END_REF] Client's Proof of Work [START_REF] Li | Interest cash: an application-based countermeasure against interest ooding for dynamic content in named data networking[END_REF] Alternative Forwarding [START_REF] You | Dipit: A distributed bloomlter based pit table for ccn nodes[END_REF][START_REF] Tsilopoulos | Reducing forwarding state in contentcentric networks with semi-stateless forwarding[END_REF][START_REF] Wang | Reducing the size of pending interest table for content-centric networks with hybrid forwarding[END_REF][START_REF] Ghali | Closing the oodgate with stateless content-centric networking[END_REF][START_REF] Detti | Conet: a content centric internetworking architecture[END_REF][START_REF] Jokela | Lipsin: line speed publish/subscribe inter-networking[END_REF] PIT Modifications [START_REF] Wang | Decoupling malicious interests from pending interest table to mitigate interest ooding attacks[END_REF] Proactive = works proposing application-based solutions to defend against IFAs. That is, clients are required to insert subsidiary information in their Interests, so as their nature can be assessed by other network entities, e.g., routers and/or content providers. For example, the InterestCash schema of [START_REF] Li | Interest cash: an application-based countermeasure against interest ooding for dynamic content in named data networking[END_REF] requires consumers to solve puzzles to generate Interests for dynamic contents checked at the reception by content providers. Overall, InterestCash reduces the amount of eective malicious trac that single attackers can generate in the unit time. However, the nature of an Interest is determined at the content producer side. Hence, this schema does not prevent malicious Interests to occupy PIT space across the network and so does not protect the network infrastructure. A proactive variant of this mechanism could be designed assuming the information inserted by consumers in their Interests would be validated in routers. Though, no such work has been proposed yet. The category "alternative forwarding" refers to work addressing the IFA security threat by proposing alternative PIT designs. Some propose stateless designs just in order to avoid the vulnerability of the PIT stateful forwarding plane [START_REF] Ghali | Living in a pit-less world: A case against stateful forwarding in content-centric networking[END_REF]. These alternative forwarding mechanisms outline insightful and promising research directions for the design of less vulnerable NDN/CCN networks. Thus, the related works are covered in depth in the Chapter 5.

The majority of the IFA countermeasures proposed so far is reactive. Reactive countermeasures feature a canonical two-phase, detection and mitigation, defense mechanism. In the detection phase, either interfaces or prex names are identied as infected. The methodology used to perform the detection can be either an analysis of trac metrics observed over certain time windows [START_REF] Afanasyev | Interest ooding attack and countermeasures in named data networking[END_REF][START_REF] Compagno | Poseidon: Mitigating interest ooding DDoS attacks in named data networking[END_REF][START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF] or a statistical guess [START_REF] Nguyen | Detection of interest ooding attacks in named data networking using hypothesis testing[END_REF][START_REF] Nguyen | An optimal statistical test for robust detection against interest ooding attacks in ccn[END_REF]. Then, in the mitigation phase, a strategy is adopted to reduce the attack's impact. A further characterization can be applied based on the mitigation technique in two main subcategories: PIT-modications approaches and rate-limiting ones.

There are very few works proposing PIT-modications to the data-plane operations to block IFAs from saturating the PIT. For example, the Disable PIT Exhaustion (DPE) approach in [START_REF] Wang | Decoupling malicious interests from pending interest table to mitigate interest ooding attacks[END_REF] detects an attack by monitoring some PIT-based metrics, but it applies a dierent packet processing to the trac detected as suspicious. The DPE approach proposes not to record Interests in PIT when their prex name is detected under attack. Instead, the reverse path is appended hop-by-hop to suspicious Interest packets when those are forwarded upstream for eventual Data to be forwarded downstream.

Applying a rate limit to input/output routers interfaces is a widely adopted mitigation mechanism by IFA countermeasures. Those countermeasures are classied under the "rate limiting" category and are subject to a further distinction between collaborative and independent. Independent countermeasures are applied at each router by leveraging only local detection information. In collaborative countermeasures, routers communicate to exchange information about their respective states. Communication between routers is of foremost importance to both avoid overreaction on the same Interests and rate-limit an attack far from the nal targets, where it may be harder to detect. The form of collaboration among routers vary from IP-traceback inspired techniques [START_REF] Compagno | Poseidon: Mitigating interest ooding DDoS attacks in named data networking[END_REF][START_REF] Dai | Mitigate DDoS attacks in NDN by interest traceback[END_REF][START_REF] Afanasyev | Interest ooding attack and countermeasures in named data networking[END_REF], which push-back downstream notications asking routers closer to the attack sources to scale down their rates, to ad-hoc deployed specialized nodes [START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF], which through a global network view can localize and mitigate more precisely ongoing attacks.

Until very recently, the works under the reactive/rate-limiting/collaborative category had been showed to be the more eective defense mechanisms against IFAs. However, the canonical reactive approaches have been shown by recent literature to be susceptible to stealthy attacks [START_REF] Signorello | Advanced interest ooding attacks in named-data networking[END_REF] and their ecacy to be highly-variable with network topologies [START_REF] Al-Sheikh | Revisiting countermeasures against ndn interest ooding[END_REF]. In particular, the latest attacker model proposed in [START_REF] Signorello | Advanced interest ooding attacks in named-data networking[END_REF] capitalizes on the reactive nature of those existing countermeasures. In fact, two intrinsic characteristics of these state-of-the-art reactive countermeasures are to react after an observation time window and to rely on collected metrics. Both factors can be easily exploited by potential attackers to stay undetected, in particular when the attackers have the necessary knowledge to dose with precision the kind of generated Interests.

The pitfalls of reactive countermeasures are not present in proactive countermeasures as the latter are conjectured by this work. Thereby, it is worth to investigate the conception of a novel class of countermeasures exhibiting intrinsically dierent characteristics since those have the potential to improve the state of the art. The cryptographic route token approach of [START_REF] Alston | Neutralizing interest ooding attacks in named data networks using cryptographic route tokens[END_REF] introduces the notion of proactive defense and postulates novel evaluation metrics, similar to the ones dened in this work, for the rst time in literature. However, in [START_REF] Alston | Neutralizing interest ooding attacks in named data networks using cryptographic route tokens[END_REF] no precise denition of proactiveness is given. Therein, the adjective proactive is rather used to dierentiate an in-packet cryptographic mechanism proposed in opposition to the reactive nature of existing countermeasures.

Conversely, this work precisely conjectures this novel class of defense mechanisms, delineates general characteristics and proposes concrete implementation options for the rst time.

Proactive Countermeasures

A proactive IFA countermeasure is here dened as a defense mechanism aiming to make routers able to detect an IFA without monitoring any prior trac. Thereby, proactiveness eliminates the need for routers to collect and analyze trac statistics to infer detectors of possible attacks.

Attack detectors are aected by network conditions and attacker strategies, so their absence reduces the risk of unnecessary reaction to regular trac peaks and of manipulation of routers' decisions by misleading attacker's behaviors. Moreover, proactiveness does not introduce any delay in the reaction to ongoing attacks at the price of some additional delay in the Interest processing.

Proactive countermeasures rely on no additional information except the one contained in the Interest packet to determine the either benign or malicious nature of an Interest. Mainly this revolves around the analysis of the Interest name. How this latter task is performed and the kind of delay introduced in the Interest processing further characterize the proactive technique. First, a list of generic requirements for the design of IFA countermeasures is presented in Sec. 4.2.1. The framework is used in Sec. 4.2.2 to showcase the advantages of an ideal proactive countermeasure over the existing reactive ones. Finally, a possible declination of the ideal proactive model, named Charon, is concretely explored is Sec. 4.2.3, 4.2.4 and 4.2.5.

Requirements for IFA countermeasures

To clarify pros and cons of the dierent kinds of defense mechanisms, this work sets out a list of ideal goals for IFA countermeasures. This list aims to be a common framework, missing at the time being, for a fair comparison of existing and future defense mechanisms. It would be desirable for IFA countermeasures to exhibit the following characteristics:

• G1 -low overhead: refers to packet processing operations and resources, computation and storage.

• G2 -high protocol compatibility: refers to avoiding possible required ad-hoc protocol changes, e.g., the introduction of new packet elds or a change in the packet processing workow.

• G3 -low infrastructure deployment: refers to the deployment of ad-hoc infrastructure, e.g., nodes with additional monitoring capability. • G4 -high ecacy: refers to the performance which is usually measured in terms of the average quality of service given to clients and the amount of resources, network bandwidth and/or routers' resources, consumed by the attack in the network.

• G5 -low impact on legitimate trac: refers to the percentage of legitimate trac aected by the application of the countermeasures itself.

Certainly, priority among the above goals is not absolute rather driven by design requirements.

For example, the design of a countermeasure to be deployed at Internet scale would require to introduce a few or almost no overhead because of the high link-speeds, nor infrastructure deployment and the highest protocol compatibility because of the possibly involved dierent administrative network entities. In that case, the requirements G1, G2 and G3 are targeted, while the requirements G4 and G5 may be relaxed. Conversely, a countermeasure operational in an ICN-island at the network edge aims to block malicious trac mainly to guarantee a good experience to the clients (goals G4 and G5) accessing the mainstream network via that edgenetwork segment. At the network edge, low overhead is not of foremost importance since an edge-router handles slower network links, infrastructure deployment neither since the interested infrastructure could be all part of the same network operator. Therefore, the requirements G4 and G5 may be prioritized over the G1, G2, G3 ones.

In Table 4.1 three of the most eective reactive state-of-the-art IFA countermeasures have been classied according to the above-dened target Gx requirements: the Satisfaction-Based Pushback (SBP) of [START_REF] Afanasyev | Interest ooding attack and countermeasures in named data networking[END_REF], the Distributed Poseidon of [START_REF] Compagno | Poseidon: Mitigating interest ooding DDoS attacks in named data networking[END_REF], the CoordiNation MonitoRing (CNMR)

of [START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF]. • all the existing reactive techniques introduce considerable monitoring overhead. Monitoring overhead is also highly proportional to the ecacy, since a more ne-grained observation guarantees a more precise detection.

• the techniques showing higher protocol compatibility and requiring no infrastructure deployment (e.g., SBP [START_REF] Afanasyev | Interest ooding attack and countermeasures in named data networking[END_REF] and DP [START_REF] Compagno | Poseidon: Mitigating interest ooding DDoS attacks in named data networking[END_REF]) exhibit mid ecacy and highly impact legitimate trac.

• reactive countermeasures can be improved with regard to ecacy and impact on legitimate trac at the price of largely increasing the overhead, the protocol compatibility and the infrastructure deployment. This is exactly what is achieved by the CNMR [START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF] technique.

CNMR employs additional ad-hoc monitoring nodes and a centralized controller (infrastracture deployment), it performs a very ne-grained monitoring per each prex name on each interface (overhead), it introduces Interest labeling to mark monitored Interests as well as a protocol to communicate reports to the centralized controller unit (protocol compatibility).

• the impact of the mitigation applied by a countermeasure on legitimate trac has never been estimated by the related work. However, all the three countermeasures are very susceptible to the issue of dropping legitimate trac if that either is issued with the prex names identied as detected or comes from the same infected interface or both.

Overall, a reactive countermeasure seems to have several downsides. First, it introduces overhead for monitoring, protocol changes and infrastructure deployment proportionally to the desired efcacy. Second, despite the invested resources, it aects considerably legitimate trac too since it cannot discern Legitimate and Fake Interests issued under the same prex name. Third, this kind of countermeasure can still be circumvented with moderate attack capabilities.

Ideal Proactive Countermeasure

The last row of Table 4.1 shows how an ideal Proactive Countermeasure (PC) sets with respect to the Gx target requirements. First, an ideal proactive countermeasure does not require collecting and analyzing any trac metric. Therefore, it is expected to introduce very low overhead. Per-Interest analysis must be done to distinguish between Fake and Legitimate Interests. However, this task can be accomplished by looking at the Interest packet elds and at a few more resources built o-line. Second, an ideal proactive defense mechanism exhibits full protocol compatibility.

Forwarding decisions are made locally at each router and can be implemented in the form of an NDN forwarding strategy module. Third, such a countermeasure requires no infrastructure deployment since i) forwarding decisions are taken independently by each router, ii) no communication between routers is required. With regard to the requirements G4 and G5, those highly depend on the attacker model and on the Interest packet analysis technique applied by the proactive countermeasure. In general, assuming an attacker model where attackers are able to precisely generate both forged content identiers and valid ones, a proactive countermeasure could leverage the attacker's same knowledge (e.g., publicly available content lists for a certain provider as shown in Chapter 3) to eectively discern those (i.e., factors which lead to very high ecacy and no impact on legitimate trac). Conversely, proactiveness is ineective when it is not possible to establish a priori the validity of content identier (e.g., providers dynamically generating content identiers for multimedia streaming content). In this last case, neither the attacker nor the router could precisely ascertain a priori the validity of a content identier (i.e.

factors which lead to low ecacy and high impact on legitimate trac).

From Principles to Practice

The ideal behavior described in Sec. 4.2.2 faces additional constraints in realistic settings. First, pure proactive countermeasures cannot detect valid Interests yet generated by attackers. So, they are totally inecient against attacks where collusive consumers and producers collaborate to delay the delivery of valid Data packets [START_REF] Salah | Evaluating and mitigating a collusive version of the interest ooding attack in NDN[END_REF]. Second, proactive countermeasures assume routers are able to distinguish spoofed content identiers from valid ones. This can be achieved either by knowing all the valid content identiers or by learning them through prior trac observation.

The former method applies for static contents whose lists are made available by the respective producers. The latter method applies for both dynamically generated contents or contents whose lists are not available. In the former case, several possibly very large lists of content identiers must be stored by routers and checked at run-time. In the latter, learning models must be built and maintained on-line. The former case is of notable interest because of the latest disruptive IFA attacks [START_REF] Signorello | Advanced interest ooding attacks in named-data networking[END_REF] using large providers' publicly available content lists. The latter case requires trac to be monitored rst in order to build a model, hence, it exhibits the same issues seen with existing reactive countermeasures.

The Gx requirements framework has been introduced to guide the design of future countermeasures. Therefore, the design of a proactive countermeasure starts from sorting the target Gx requirements. With that aim, the design is assumed to address at rst the main issues raised by the latest attacks with respect to the state-of-the-art reactive countermeasures [START_REF] Signorello | Advanced interest ooding attacks in named-data networking[END_REF]. That is, to avoid using a countermeasure which performs uneciently and penalizes legitimate consumers despite a large monitoring overhead and the deployment of an ad-hoc infrastucture to ne tune the monitoring operation. Hence, low overhead (G1), high ecacy (G2) and no impact on legitimate trac (G3) are the main target requirements. While, the requirements of high protocol compatibility (G2) and low infrastructure deployment have lower priority.

Content summaries

Traditionally, Legitimate Interests and Fake ones have been considered indistinguishable at routers. In fact, those only dier in content identiers and routers are not supposed to have any notion about valid and spoofed ones. Indeed, the assumption that routers do not have any knowledge about valid content identiers is not always true and so it may be relaxed in some scenarios. For example, in the steady attack model proposed in [START_REF] Signorello | Advanced interest ooding attacks in named-data networking[END_REF], attackers have access to public lists of valid identiers for target prex names, so routers do too.

Assuming lists of valid content identiers are available, those could be stored and checked by routers at the Interest reception. Such a scenario imposes three main requirements for the design of a proactive countermeasure which should not:

• alter the correctness of the Interest forwarding operation, that is, the countermeasures should aect neither the forwarding of legitimate Interests upstream nor the forwarding of the respective Data downstream.

• introduce large memory requirements to store the lists of contents.

• introduce intolerable additional latency in the Interest processing since the validity check of Interest names is expected to be done at line-rate per every Interest.

Bloom lters (BFs) [START_REF] Bloom | Space/time trade-os in hash coding with allowable errors[END_REF]

Addressing Scalability

The basic design of Charon assumes routers always hold the content summary for a certain prex under attack. However, this may be unlikely to scale in real settings for several reasons. First, routers would need to store content summaries for a large number of content providers, e.g., all the prex names available in the router's FIB. Still, this would be reasonable, assuming those were mostly stored on secondary memory and moved to main memory at run-time accordingly.

Second, those summaries may need to be updated by content providers or new summaries may be needed due to routing updates. For the above reasons, it seems reasonable to foresee a way for routers to occasionally fetch and/or regularly update content summaries. The basic design of Charon enforces no specic solution for that purpose rather highlights a few possibilities.

Content summaries could be made available to routers via either a trusted centralized authority (as it happens for today's public key certicates) or could be directly asked to the respective content producers. In the latter case, encryption should be used to avoid prospective attackers to fetch the content summaries and generate set of forged content identiers which generate false positives. Furthermore, once the summaries are issued by the content providers, they would be cached in the network as ordinary Data packets. Therefore, the latency necessary to retrieve the summaries is reduced and the risk of relying on a single centralized point of failure too. In both cases, a secure communication channel between the router and the source of the summaries should exist to prevent attackers from getting the information required to obtain a clear version of a summary. The architecture envisioned by Charon is illustrated in Fig. 4.3.

With regard to the scalability of the countermeasure, Charon oers a considerable advantage over existing reactive countermeasures. In fact, while reactive countermeasures must be deployed in several network areas and orchestrated so for the attacks to be properly detected, the check performed by a proactive countermeasure like Charon is independent from the position in the network where that is deployed. In fact, Charon can be selectively deployed in a few specic points of network without compromising its overall ecacy. In particular, edge-routers are perfect candidates since they block the fake Interests as soon as those enter the mainstream network.

Additional deployment of the countermeasure in inner network tiers would not bring any tangible benet assuming the content summaries are mostly identical, that is, having the same false error probability. The deployment at the edge also reliefs core network routers to perform additional per-packet processing which could not be sustained at certain link speeds.

Evaluation

The evaluation reported in this section concerns two main factors. First, it shows that the proactive Charon design is more robust than the best state-of-the-art countermeasures against all the latest stealthy attacks proposed in [START_REF] Signorello | Advanced interest ooding attacks in named-data networking[END_REF]. In fact, Charon entirely preserves the quality of service perceived by clients when the network is under those attacks. Moreover, Charon shields the network infrastructure from the overload of state in PITs created by the attackers ooding with malicious Interests. Second, it outlines the importance of evaluating the impact of the application of the IFA countermeasures on legitimate trac. Indeed, by precisely tracking the forwarding decisions taken on both malicious and legitimate interests in the network simulations, it is possible to see two dierent concerning behaviors: i) a considerable amount of legitimate trac is always dropped as a consequence of the mitigation and the eect of this behavior on some kind of trac, e.g., video streaming, stays unclear, ii) the portion of legitimate trac dropped does not necessarily depend on the router load rather on whether or not Malicious Interests and Legitimate ones enter the router from the same downstream interface.

The rest of the section is organized as follows. The evaluation settings and metrics are summarized in Sec.

Evaluation Environment and Metrics

For the sake of a fair comparison to the related work, the ecacy of the basic Charon design has been assessed by replicating the experiments in [START_REF] Signorello | Advanced interest ooding attacks in named-data networking[END_REF]. Therein, three state-of-the-art coun-

Interest Drop Ratio

In IFAs, attackers generally strive for generating Malicious Interests with popular prex names.

By that, attackers have two main objectives: i) to masquerade an attack in-between legitimate trac, ii) to cause mitigation techniques to also penalize legitimate trac too, so to further degrade the service provided to other normal users. This assumption about the attacker model has been proved to be eective for building stealthy IFAs in [START_REF] Signorello | Advanced interest ooding attacks in named-data networking[END_REF]. Those attacks have a higher impact on both clients and the network infrastructure. However, at the time being there exists no evaluation metric in the literature on IFAs to quantify precisely the impact on legitimate trac neither of this kind of attack nor of the countermeasures applied in defense to it. Indeed, a precise understanding of this eect could be benecial to improve existing defense mechanisms.

This work introduces the Interest Drop Ratio (IDR) as evaluation metric to quantify the impact of the application of a certain IFA countermeasure on the legitimate trac in the network. The IDR is dened as the ratio of forwarded Interests over the received ones across a certain time window because of the countermeasure's forwarding decisions. The motivation behind the introduction of a new evaluation metric for IFAs is mainly to show that proactive countermeasures bring the additional advantage of not aecting any legitimate trac over the existing reactive countermeasures. This hypothesis was conrmed by measuring the IDR in scenarios where

Charon was applied as defense mechanisms to counteract ongoing attacks. In fact, Charon never drops any Legitimate Interest by design. On the contrary, both SBP [START_REF] Afanasyev | Interest ooding attack and countermeasures in named data networking[END_REF] and CNMR [START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF] drop some legitimate trac as eect of their mitigation techniques.

Besides, even at an early stage of the adoption of this metric, the evaluation of IDR in other

Charon performance

The proactive countermeasure Charon has been compared to the most ecient state-of-the-art reactive countermeasures in scenarios where the latter ones fail to counteract ecaciously stealthy IFAs. The evaluated reactive countermeasures are the Satisfaction-Based Pushback (SBP) [START_REF] Afanasyev | Interest ooding attack and countermeasures in named data networking[END_REF] and the CoordiNation MonitoRing (CNMR) [START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF]. Both SBP and CNMR are collaborative countermeasures which monitor trac metrics over observation time windows to detect attacks. On one hand, SBP applies a probabilistic forwarding to each Interest where the forwarding decision is based on locally measured ISR values and rate-limits announced by upstream neighbors. On the other hand, CNMR relies on an ad-hoc set of monitoring routers coordinated by a centralized controller to identify prex names potentially under attack. Then, each CNMR router mitigates the attack according to the locally measured ISR. Overall, both defense mechanisms suer from some weaknesses which can be exploited by attackers to remain undetected. More precisely, metrics collected at routers can be tainted by dosing dierent Interest types and by periodically varying target prex names, as done respectively by the blended IFA and the chamaleonic IFA variants proposed in [START_REF] Signorello | Advanced interest ooding attacks in named-data networking[END_REF]. ), then the mitigation is applied to a prex name which does not carry anymore malicious trac. Among the attacks proposed in [START_REF] Signorello | Advanced interest ooding attacks in named-data networking[END_REF], the cIFA is the one degrading the most the performance of the tested reactive countermeasures. Conversely, Charon is also immune to this IFA variant since its forwarding decisions are not driven by any detection threshold. Therefore, Charon keeps average ISR and PUR values close the baseline even during the attack.

In summary, the attack variants proposed in [START_REF] Signorello | Advanced interest ooding attacks in named-data networking[END_REF] revealed the inecacy of existing defense mechanisms to neutralize a certain type of stealthy IFAs. Charon, instead, neutralizes those attacks as soon as they enter the network, so it preserves the quality of service perceived by legitimate clients and ooads the rest of the network infrastructure from dealing with loads of unsatisable requests.

4.4 Charon: size of the summary, optimizations and future work

This section introduces some design aspects of Charon which deserve immediate attention to assess the feasibility of the proposed approach and target specic improvements as subject of any future work.

First, it is important to estimate the size of a BF-based content summary since that could be queried by routers at link-speed per every Interest packet. For that purpose, a BF-based content summary is required to be stored on a memory technology fast enough to sustain the necessary network throughput (the reader should remember that Charon is supposed to be deployed at the edge of network whose throughput requirements can be read in [START_REF] Yuan | Scalable pending interest table design: From principles to practice[END_REF]). The size m of a BF-based content summary may be tuned according to the desired false probability rate p and the number of hash functions k, where the number of elements n in the set is known. Considering a content list of one million elements (this is not uncommon since, for example, the wikipedia page titles content list used for the evaluations presented in Sec. 3.2.3 of chapter 3 and in Sec. 4.3.3 of this chapter holds almost 13 million of dierent content identiers), a false positive probability of 0.01 and using between 2 and 5 hash functions would require a bloom lter of a few MB [START_REF]Bloom lter calculator[END_REF].

A lter of that size could be easily stored on today's SRAM memory technology (whose today's maximum capacity is 210MB [START_REF] Zhang | Adaptive compression trie based bloom lter: Request lter for NDN content store[END_REF]). Hence, multiple lters could be contemporaneously stored in fast on-chip memory.

Second, even though large size BF-based content summaries can be stored in fast main memories and meet the packet processing speed requirements, the architectural framework of Charon in Fig. 4.3 envisions the content summaries to be fetched by routers and potentially cached in the network as Data packets. Concerning the implementation of these system features, it is also important to understand whether bloom lter compression techniques [START_REF] Mitzenmacher | [END_REF] could be used to shrink the size of a summary and ease its transmission over and caching in the network.

Third, even if a pure Charon design turned to be prohibitive because of the impossibility of storing all the lters in a router's main memory, content summaries could still be loaded and queried only when under attack. This would translate into a hybrid proactive/reactive design where the detection of an attack still relies on the monitoring of trac statistics, while the mitigation loads in main memory and queries the content summaries. The mitigation based on content summaries has the advantage of never dropping any legitimate trac compared to the canonical reactive rate-limiting applied to name prexes and/or interfaces. By design, this hybrid technique is expected to respond ecaciously to a pIFA but not to the bIFA and cIFA attacks which circumvent the classical detection metrics. However, in those latter cases the detection could be simply triggered by an unusual load on the router since loading and querying the lter would not introduce the same overhead as the canonical monitoring techniques.

Summary

This chapter has introduced a novel approach to the defense against Interest Flooding Attacks (IFAs) in NDN. This new approach stems from the observation of certain pitfalls in the state-ofthe-art countermeasures, which can be exploited by potential attackers to mount very eective IFAs as shown in Chapter 3. The reactive nature of the existing defense mechanisms is the root cause of the inecacy to defend against stealthy IFAs. Thus, the here-proposed defense approach departs from the usual reactive defense approach and proposes a proactive strategy to identify and counteract an IFA instead. Proactiveness is based only on the analysis of an Interest packet elds to determine its either malicious or benign nature. Therefore, an ideal proactive defense requires no monitoring of previous trac to be performed to make forwarding decisions.

The absence of monitoring, typically used across reactive defense mechanisms, eliminates the vulnerabilities which are exploited by the stealthy attacks introduced in Chapter 3.

This chapter has also designed a specic proactive defense schema, called Charon, and shown its ecacy against the latest stealthy IFAs. Nevertheless, Charon, specically, and proactive defense, in general, are only applicable under certain attack scenarios. Thus, the IFA threat persists in the NDN. Therefore, the next chapter advocates for the investigation of dierent forwarding mechanisms for the NDN with the aim to preserve the main PIT properties without exposing the IFA-related security issue.

Chapter 5

Alternative "defense" mechanisms behaviors. Further, the PIT has been leveraged to detect network problems [START_REF] Yi | A case for stateful forwarding plane[END_REF] and has inuenced the design of routing protocols for the NDN architecture [START_REF] Yi | On the role of routing in named data networking[END_REF]. Or yet, the PIT has been used for the design of hop-by-hop Interest shapers to achieve congestion control [START_REF] Caroglio | Optimal multipath congestion control and request forwarding in information-centric networks: Protocol design and experimentation[END_REF] and for tracking producers in mobility schemas [START_REF] Zhang | Kite: a mobility support scheme for NDN[END_REF].

Moreover, the lack of a common easy-to-access platform for testing and comparing alternative forwarding plane designs makes hard to get a solid understanding of pros and cons of the dierent available approaches. For the above reasons, this chapter's contribution is two-fold. First, a taxonomy of the main alternative forwarding mechanisms for CCN/NDNs is presented in Section 5.1. The presented taxonomy classies the existing dierent approaches with respect to a set of PIT's cardinal properties here identied. Second, by acknowledging that the current state of aairs does not contribute to compare and evaluate alternative forwarding mechanisms, emerging technologies for programming the data-plane have also been explored in the context of this work. Thus, Sec. 5.2 introduces the P4 language, a novel high-level programming language for packet processors, which has been used to implement the high-level description of an NDN data-plane, NDN.p4, which is presented in Sec. 5.3.

Alternative PIT designs

The PIT is a core component of the NDN data-plane.

Summary of the cardinal PIT properties

The main goal of the NDN's stateful data-plane design is that Data can be routed back to the origins of the requests from any point in the network without the notion of the source address in Interest packets. This mechanism is often referred to as Reverse Path or Breadcrumb Forwarding. Other properties, like the multicast data delivery, the interest aggregation and the adaptive forwarding, can be considered the outcome of the NDN-specic stateful forwarding design. Most of the time those properties are stated dierently in the related works which seek for PIT replacements. Thus, the terminology is hereby claried before the state-of-the-art alternative PIT designs can be compared.

Reverse Path Forwarding: Interests dynamically generate or update forwarding state in traversed routers for Data to follow the trails back to the origins of the Interests. Thus, the presence of PIT state allows Interests to be issued without source address. Further, PIT entries allow routers to detect those Interests which are possibly looping because of the multipath feature oered by FIBs. However, the NDN's reverse path forwarding assumes path symmetry dwells in the network, which is in sharp contrast with the path asymmetry observed in the Internet backbone [START_REF] John | Estimating routing symmetry on single links by passive ow measurements[END_REF].

Interest aggregation: at the rst common router, Interests for the same content are aggregated in the same PIT entry. Interest aggregation has been promoted in NDN to reduce network and server loads in combination with in-network caching. There have been so far few works analyzing the likelihood of Interest aggregation in CCN/NDN networks. Further, the related ndings are contradictory. In fact, the theoretical models derived in [START_REF] Ghali | Living in a pit-less world: A case against stateful forwarding in content-centric networking[END_REF][START_REF] Dabirmoghaddam | Characterizing interest aggregation in content-centric networks[END_REF] suggest that indeed aggregation may appear at the network edge with very low probability for popular contents. Meanwhile, the latest large trace-driven study in [START_REF] Shannigrahi | Request aggregation, caching, and forwarding strategies for improving large climate data distribution with NDN: a case study[END_REF] reports that there could have been a considerable reduction of server hits with Interest aggregation in the network for the analyzed trac trace.

Multicast Data delivery: Interests for a content traveling from origins to content sources build a temporary multicast forwarding tree which is made of the PIT entries left in the network. Different consumers may join the "multicast group" at any time and their requests are aggregated at the rst router where a similar Interest has already been received and forwarded. Data packets are delivered downstream by following the tree and get multicasted where the tree branches.

Data consume related PIT entries. The multicast tree construction and deletion happens entirely in the data-plane without any support from the control-plane. • aggregation techniques [START_REF] You | Dipit: A distributed bloomlter based pit table for ccn nodes[END_REF]: these techniques aim to consolidate multiple PIT entries in one single record as to reduce the maximum amount of forwarding state in the PIT. However, since the compression is not loss-less, some forwarding information is lost.

• hybrid techniques [START_REF] Tsilopoulos | Reducing forwarding state in contentcentric networks with semi-stateless forwarding[END_REF][START_REF] Wang | Reducing the size of pending interest table for content-centric networks with hybrid forwarding[END_REF]: this refers to techniques which are neither entirely stateless nor fully stateful. A portion of the Interests is generally forwarded without storing any related status in the PIT. The nature of an Interest, either stateless or stateful, may be chosen by dierent factors, e.g., content popularity [START_REF] Wang | Reducing the size of pending interest table for content-centric networks with hybrid forwarding[END_REF], probabilistic or deterministic • fully routing-based techniques [START_REF] Ghali | Closing the oodgate with stateless content-centric networking[END_REF]: this refers to stateless techniques using routing tables to forward Interest upstream and Data downstream. Additional routing information to reach the origins of Interests is needed in order to route Data packets downstream. Therefore, these methods increase the size of the FIB tables in routers to contain routes for both consumers and producers of contents. Furthermore, if the source address is a topological address, this kind of approach violates the consumer privacy by revealing the sender's identity. Nevertheless, an identier local to a router can be used to denote the source of Interests and preserve sender identity, as done with the anonymous datagrams proposed in [START_REF] Garcia-Luna-Aceves | Content-centric networking using anonymous datagrams[END_REF].

• state shifting techniques [START_REF] Detti | Conet: a content centric internetworking architecture[END_REF][START_REF] Jokela | Lipsin: line speed publish/subscribe inter-networking[END_REF]: this class refers to techniques where the state necessary for a potential further data delivery is moved to packet headers. The state may be either collected by Interests traversing the network (for example, in the CONET architecture [START_REF] Detti | Conet: a content centric internetworking architecture[END_REF]) or source-routed by the origin by means of a topology-omniscient centralized entity (like done in the LIPSIN forwarding architecture [START_REF] Jokela | Lipsin: line speed publish/subscribe inter-networking[END_REF]). Overall, all the proposed techniques introduce some modications to the forwarding plane, e.g., new packet headers [START_REF] Detti | Conet: a content centric internetworking architecture[END_REF][START_REF] Ghali | Closing the oodgate with stateless content-centric networking[END_REF], additional PIT state per entry [START_REF] Tsilopoulos | Reducing forwarding state in contentcentric networks with semi-stateless forwarding[END_REF], dierent forwarding datastructures and operations [START_REF] Tsilopoulos | Reducing forwarding state in contentcentric networks with semi-stateless forwarding[END_REF][START_REF] Ghali | Closing the oodgate with stateless content-centric networking[END_REF]. Therefore, all the current proposals may face deployment issues because of incompatibility with the existing architectures and protocols. With regard to the Reverse Path Forwarding tenet, that seems to be based on the common belief among the research community that communications ow bidirectionally across the same physical links in the Internet. This symmetry has been embedded for a long time in trac classication tools and then adopted in the design of the NDN architecture where every Data packet follows a reverse path to one or more origins of the request. Nevertheless, recent studies [START_REF] John | Estimating routing symmetry on single links by passive ow measurements[END_REF] based on data collected over dierent Internet links (e.g., dierent tiers and links between those)

show that moving from the network edge to the core Internet path symmetry is rarely observed.

A dominant cause of this asymmetry is the "hot-potato routing" [START_REF] Subramanian | Geographic properties of internet routing[END_REF] practice employed by ISPs to minimize the transit of some trac within their networks. Besides that routing policy, trac engineering techniques, e.g., load balancing, may also cause packets sent to the same destination to be forwarded over dierent paths. Therefore, taking into account today's ISPs routing policies and economic settlements, assuming path symmetry across the future Internet seems unfeasible.

As a conclusion, the reverse path forwarding is a property which should be either entirely rethinked or only enforced at the network edge where there could be the conditions to realize it.

As regards the Interest Aggregation property, some works [START_REF] Ghali | Living in a pit-less world: A case against stateful forwarding in content-centric networking[END_REF][START_REF] Dabirmoghaddam | Characterizing interest aggregation in content-centric networks[END_REF] have tried to determine the likelihood of Interest collapsing via theoretical models and network simulations. Interests are aggregated when they exhibit temporal correlation. That is, if the Interests arrive at a router within a very small time window, which is expected to be of the order of tens of milliseconds.

Further, Interest aggregation will bring the most gain when that happens the most closest to the consumer. Hence, it is important to understand how likely both conditions hold. Both the independent studies [START_REF] Ghali | Living in a pit-less world: A case against stateful forwarding in content-centric networking[END_REF][START_REF] Dabirmoghaddam | Characterizing interest aggregation in content-centric networks[END_REF] highlight the high interplay between in-network caching and Interest aggregation. According to their simulation results, it appears that the former plays a fundamental role in determining the fraction of Interests which could benet from aggregation.

To summarize the ndings therein, the percentage of aggregated Interests decreases with even a small amount of caching budget (e.g., 1% of the total number of published objects) available in the network and when consumers are less likely to ask for similar content (e.g., low temporal correlation among Interests). Moreover, most of the Interests are aggregated closer to the content sources. This last behavior would drastically aect the benets of reduced end-to-end latency and network load advocated by this structure. These ndings seem to demystify the need of Interest aggregation, since in-network caching could be applied to achieve similar benets without exposing the NDN data-plane to IFAs. It is assumed that Interest aggregation also prevents multipath routing to generate loops. In fact, PIT entries store Interest nonces and so are able to distinguish the reception of a duplicate Interest which may be looping in the network.

However, there exist conditions (for the rst time presented in [START_REF] Garcia-Luna-Aceves | A fault-tolerant forwarding strategy for interest-based information centric networks[END_REF]) where Interest aggregation in the PIT may prevent Interests loops to be detected and cause Data to never be delivered to consumers. The same work [START_REF] Garcia-Luna-Aceves | A fault-tolerant forwarding strategy for interest-based information centric networks[END_REF] proves no correct forwarding can be designed simply by uniquely identifying with a dierent Nonce each Interest. Therefore, the current NDN Interest aggregation mechanism does not guarantee correct interest forwarding. Alternative forwarding mechanisms, which are immune to the undetected loops problem, have already been proposed [START_REF]A more scalable approach to content centric networking[END_REF].

Programmable Data-planes

The rst generation of IP routers were software programs running on general purpose processors [START_REF] Aweya | On the design of ip routers part 1: Router architectures[END_REF]. The use of generic platforms eased the design and implementation of packet processing functions at a high level at a time where network throughput was not a prime requirement. In fact, general purpose chips and architectures were not designed to optimize few specic tasks, rather to be generic enough to perform a vast set of operations. Today, network functions are mostly implemented with Application Specic Integrated Circuits (ASICs) to meet strict latency and network throughput requirements imposed by higher link-speeds. Meanwhile, more versatile chips, like Network Processor Units (NPUs), can be used in less time-critical network environments where, however, changes of the network behavior may be required on the eld.

Wisely looking at the design of forwarding devices, i.e., switches and routers, over the past decades, two important facts emerge. First, new protocols have always been rst standardized and then implemented in network equipment (among them, the recent proliferation of encapsulation protocols like VxLAN, PBB, GRE). Second, today's forwarding devices oer more functionalities (QoS, security, etc.) in addition to the simple L2 and L3 forwarding. In either case, a new protocol or a new functionality may lead to the design of a new chip whether that is not supported by the latest hardware. The latter operation is a few-year long process which slows down the adoption of a technology at best, or discourages it at worst. Since the introduction of new protocols and functions seems to be more and more commonplace, several chip designs for high-speed recongurable packet processors have been proposed [START_REF] Brebner | High-speed packet processing using recongurable computing[END_REF][START_REF] Bosshart | Forwarding metamorphosis: Fast programmable match-action processing in hardware for sdn[END_REF][START_REF] Chole | drmt: Disaggregated programmable switching[END_REF]. Novel programmable packet processors come together with new programming languages to express the network behavior into an easy and reusable way [START_REF] Brebner | High-speed packet processing using recongurable computing[END_REF][START_REF] Bosshart | P4: Programming protocol-independent packet processors[END_REF]. Among those languages, the Programming Protocol-independent Packet Processors (P4) [START_REF] Bosshart | P4: Programming protocol-independent packet processors[END_REF] has gained notable traction since its inception in 2014.

As explained in detail in the previous chapters, an ICN network layer routes content requests toward nearby content sources using their content identiers rather than specic host addresses.

In NDN/CCN-like networks, routers feature the three functional blocks, namely PIT, CS, FIB, working on named data. The NDN data-plane involves new and unconventional processing to be performed at line-speed. For each NDN packet, several lookups on variable length names may be required, further, some related state has to be stored and/or updated. The design of NDNenabled routers turns to be challenging because of two main issues: i) the algorithmic challenges that still need to be solved [START_REF] Yuan | Reliably scalable name prex lookup[END_REF][START_REF] Mansilha | Hierarchical content stores in high-speed icn routers: Emulation and prototype implementation[END_REF][START_REF] Yuan | Scalable pending interest table design: From principles to practice[END_REF], ii) the evident lack of adequate hardware support to describe this data-plane behavior [START_REF] Varvello | Caesar: A content router for high speed forwarding[END_REF][START_REF] So | Named data networking on a router: Fast and dos-resistant forwarding with hash tables[END_REF]. Existing designs of an NDN router have been engineered by leveraging specic features of the target software/hardware platform. As result, those designs cannot be easily shared and leveraged for either further research or operational deployment.

We believe that the emergence of a new generation of fully programmable forwarding elements represents an opportunity to advance the research on ICN. In fact, if the next generation of programmable networking devices has the right feature set to fully describe any ICN packet processing, then there will be more chances to showcase the potential benets of ICN architectures. More broadly, we consider the advent of this technology as an inection point [START_REF] Varghese | Life in the fast lane: Viewed from the conuence lens[END_REF] for a conuence between the Software-Dened Networking stream of thought and the ICN one.

To promote the description of ICN protocols in a unied open-source way, which would made the related designs sharable and re-usable, the work NDN.p4 in [START_REF] Signorello | p4: Programming informationcentric data-planes[END_REF] has rst been conducted.

NDN.p4, which is presented in this section, has been the rst attempt to implement an ICN protocol using the P4 language for packet processors. Sec. 5.2.1 introduces the P4 language, the main syntax and the related programming model. Sec. 5.3 describes the implementation of the NDN protocol in P4. Finally, Sec. 5.3.6 recapitulates the main lessons learned during the design of the NDN.p4 solution.

The P4 language

P4 [START_REF] Bosshart | P4: Programming protocol-independent packet processors[END_REF] is a programming language to congure the data-plane of network forwarding elements.

The aim of the P4 language is to abstract how packets are processed by dierent devices in a high-level target-independent description. Then, target-specic compilers are supposed to map and optimize the high-level description in a P4 program to the low-level intricacies of the respective target architectures. The idea behind the language was rst proposed in [START_REF] Bosshart | P4: Programming protocol-independent packet processors[END_REF] Usually ve parts are needed to describe the behavior of a forwarding device in P4: the headers, the parser, the actions, the tables and the control ow. Those parts compose the yellow and red blocks in the abstract model of Fig. headers in incoming packets and then forwards those based on their IP destination addresses.

Finally, the P4 program rewrites the packet's MAC source and destination addresses based on the output port the packet is transmitted to.

The headers are the denition of protocols that the P4 target uses to parse the incoming bit stream to identify the protocols in a packet and extract the elds necessary to the processing. A P4 header contains a list of elds and eld widths in bits arranged in a C struct-like layout, as shown in the A cell of Table 5.2 where the structure of an ethernet header is specied. Headers represent types that can be instantiated and initialized once found and parsed in packets, as shown in the B cell of Table 5.2.

The parser is a nite-state machine that determines and extracts the protocols seen in a packet according to the headers denition. The parser is made of parser states whose transitions can be determined according to header eld values (e.g., the Ethernet's ethertype eld in our example).

A simple parser for the ethernet and IPv4 protocols is shown in the cells B and C of Table 5.2.

Actions are language primitives to express common packet editing tasks, like modifying header elds, selecting output ports, adding/removing headers, etc. Primitive actions can be combined in bundles to create compound user-dened functions. For example, the set_nexthop action in the D cell of includes two pipelines, one for the ingress stage and another one for the egress. The ingress pipeline contains a sequence of match-action tables to be executed sequentially and/or according to some branching conditions. The ingress pipeline produces an egress specication in terms of output ports and number of packet copies. The egress specication is later used in the egress pipeline to correctly forward the packets. The illustrative P4 program of Table 5.2 has a very simple control ow, illustrated in the H cell, which consists of the application of the two dened tables. First, the table ipv4_b_lpm is applied in the ingress pipeline to select the next-hop address. Then, the table forward selects the output port and rewrites the MAC addresses in the egress pipeline.

NDN.p4

NDN.p4 is the rst implementation of an ICN protocol in P4. The NDN.p4 contribution was two-fold: i) showcasing for the rst time how ICN protocols and the related network behaviors could be implemented and tested on the next-generation of programmable data-planes, ii) highlighting some of the limitations of the P4 language in describing non-standard packet processing operations. NDN.p4 had to face the constraints of the P4's early language specication, so it does not provide a fully functional NDN router rather a partial implementation featuring the basic NDN Interest-Data exchange. Additional features, e.g., in-router caching and Data multicasting, have not been implemented because those did not meet the two following requirements:

• a P4 program fully compliant with the language specication, that is, no new constructs have been added to the language,

• no assumptions about the existence of target-specic components. The NDN.p4 router program consists of less than ve hundred lines of code written in P4. In the following, the main components of this P4 program are described through the illustration of partial snippets of code where needed to highlight distinctive features of the implementation.

Finally, this section also presents some insightful lessons learned throughout the implementation of the NDN.p4 solution. The parser code inspects incoming packets and extracts header elds according to the header denitions. State transitions in the NDN.p4's parser occur either by : i) reading the Type value of the next TLV when the length of the current TLV block is known (as done in the The parser also includes a special state to extract the name components, which loops on a counter initialized with the total name length. After a name component is extracted, its total length is subtracted from the counter; the parser loops until all the components have been extracted.

Pending Interest Table (PIT)

PIT entries are created and updated by incoming Interest and Data packets. By consequence, PIT modications happen entirely in the data-plane. Nevertheless, P4 tables can just be edited by the control-plane (as better explained in the Subsection 5.3.5). Hence, the NDN.p4's PIT table is implemented on registers. P4 registers represent stateful memories which keep state across multiple packets and can be updated in the data-plane. The complete PIT behavior is simulated by also using three match-action tables: the hashName_table, the pit_table and the updatePit_table. The hashName_table computes the index of the PIT entry as hash of the packet name and writes that to the name_hash metadata eld. Then, the pit_table uses name_hash to read the indexed register location14 . Finally, the update_Pit either creates a new PIT entry or records a new incoming interface in the existing PIT entry. In summary, the actual PIT table is stored in registers, while the match-action tables are responsible for addressing and eventually updating that register block.

Forwarding-Information Base (FIB)

FIB entries associate prex names to one or many output interfaces. The algorithm that determines the FIB entry matching a content name is a Longest-Prex Match (LPM) on namecomponents. An LPM on name-components prioritizes the entry whose prex name has the longest-prex in common with the Interest name over the entries having smaller ones.

P4 tables feature standard match types like exact or ternary match. Of course, an LPM on name-components is not natively supported by the P4 table construct. So, NDN.p4 implements this kind of match by using some other native match types and a specic set of table entries. The designed algorithm is better explained through an example which is reported in Fig. 5.4. The FIB of the example has the two entries A="/a/b/c eth1" and B="/a/b eth4", made of three and two name components respectively. At the reception of an Interest named ndn:/a/b/c/d, the A entry must be selected.

At that stage of the control ow, the full hash of the Interest name and the hashes of all the smaller name-prexes are already available as metadata, as illustrated in the top-left box of Fig. where 'm' is the number of components in the prex and 'n' is the maximum number of name components that the target is programmed to parse. Those entries allows the program to match

Interests with a number of name components equal or greater to 'm' for that FIB entry. Since multiple table entries correspond to a single FIB entry, then a further selection mechanism has to be applied. Thus, ternary matches on the metadata elds "comp_metadata.cx" are used to match on the right hash combination for the prex-name. For example, to match against a FIB entry that is made of three name components, e.g., route A in Fig. 5.4, the fourth match-eld of the related entries in the ne-dotted green box , that is, 'h(a,b,c)&&&1', contains a full mask to perform an exact match on this eld. All the other hashes have a zero mask, so not match is performed to those. However, Interests for ndn:/a/b/c/d would match the second and the fth entry of the rule-set that correspond to route A and route B, if only the number of components and the hashes of the route prex-names were considered. Hence, these FIB entries include an additional value that species the priority with which they must be applied, i.e., the last value of each entry of the rule-set. A lower value gives higher priority to a matching entry. For example, the 2nd entry has higher priority than the 5th entry, and so route A is nally the matching entry for the Interest /a/b/c/d. Two shortcomings of this algorithm are: i) the number of records to be inserted for a single FIB entry depends on the number of name components of the related prex name, ii) the priority assignments have to be predened by a control plane logic. Flow_metadata.isInPIT bits is set to 1, the target has a pending entry for that name and does not forward this Interest upstream. If not, then the b_table is applied to lookup the next-hop.

Metadata

The b_table performs the LPM algorithm described in Sec. 5.3.3. If the LPM returns an entry for the Interest, then the updatePit_table is applied to create the related PIT entry. The PIT entry is created by marking the incoming interface in the bitmask. The so-created entry is nally stored in the register cell indexed by the hash of the full Interest name.

The execution path for a Data packet is similar to the one for an Interest except for the code executed after the conditional branch on the packet type. The action associated to the pit_table entry for Data packets reads the register value to load the interfaces out of which this Data packet must be forwarded downstream. The same action cleans the read register since the current Data packet is supposed to consume the related PIT entry. In case of a Data, the routeData_table is applied last. This table reads the downstream interfaces this Data must be forwarded to from the isInPIT metadata eld. The actions associated with the routeData_table's entries set the output interfaces on the standard metadata egress_spec that will be read by the egress pipeline to forward the packet out of the selected switch port.

Control Plane

All the tables dened and used in the NDN.p4 program are initially empty. These tables must be lled by a control plane application to perform the dened packet processing logic. In P4 targets, the control-plane communicates with the data-plane via some interfaces which are partially dened by the P4 programs too. The P4 software switch in [162] oers an application programming interface (API) to the P4-programmed data-plane for managing entries in tables.

Software tools are available at [160] to write control plane programs for the P4 switch too.

still premature and a clear direction for the language evolution had not been set yet. This latter observation was later conrmed by the release of the next language specication named P4_16

where, instead, the basic syntax has been reduced to a small core set to be complemented with libraries to express operations and components which could be more target-specic.

NDN.p4 overcomes some of the language limitations by making specic assumptions on some packet elds. For example, some assumptions about the NDN's headers length have made it possible to parse a variable-length TLV header although the language only allows one variablelength eld per header.

The P4_14 language version has turned to be very tied to the reference abstract forwarder model.

Indeed, the language was made to encompass a wide range of dierent targets, while the control ow of P4_14 programs allows developers to express execution ows by mainly stacking matchaction table calls. Although architectures featuring match-action table pipelines are widely used to implement fully-programmable line-speed switching chips, those do represent neither the only target of the language nor a generic enough architecture. As a further evidence of this language restriction, the "architecture-language separation" has become a key concept of the P4_16 language specication.

With regard to potential language extensions, NDN.p4 has taught us the importance of approaching the language design community with "compelling" use-cases for new features to be incorporated into the language. By "compelling", we refer to standard protocols implementing a behavior similar to the targeted one. This kind of example better works as incentive for the community members to discuss about and work on the design of prospective language features.

Here follow some examples:

• Parsing NDN TLVs: variable-length TLVs could be a common-place for the next-generation of network protocols, since their exibility has already been adopted for optional elds of well-established protocols, e.g., the IPv4's options [164] and the IPv6's extension headers [START_REF] Deering | Internet protocol, version 6 (ipv6) specication, Internet Requests for Comments, RFC Editor[END_REF], or yet, the optional parameters in the BGP4's open messages [START_REF] Rekhter | A border gateway protocol 4 (bgp-4), Internet Requests for Comments, RFC Editor[END_REF].

• PIT table updates: there already exist packet operations which require table updates to be performed in the data-plane because of strict latency requirements. For example, a MAC learning algorithm stores the Ethernet source address and the incoming port of a received packet in a table that the target uses to forward later incoming packets based on their destination addresses. This table update operation might not bear the delay introduced by an eventual communication with a control plane application as the current P4 specication envisages [167]. A solution for updating a tiny status in a predened table has been already raised by the work in [START_REF] Bianchi | Openstate: programming platformindependent stateful openow applications inside the switch[END_REF].

• Reading Data signature: Data packets carry signatures trailing the packet payload. Routers may optionally verify signatures. Therefore, the signature eld may need to be parsed. The latter operation would imply to skip a packet portion and move the parser pointer to the trailing signature eld. However, P4 does not allow to skip the parsing of some packet portions [169]. Analogously, this feature would be needed by the IPSEC protocol [START_REF] Kent | Security architecture for the internet protocol, Internet Requests for Comments[END_REF] in tunnel mode, which is the protocol used for the traditional widespread setup of Virtual Private Networks (VPNs).

Summary

This chapter explores two dierent subjects: alternative forwarding mechanisms, at rst, and design platforms, later, for the NDN data-plane. The need for this exploration originates from

3. 10

 10 ISR values for the baseline and with CNMR on for both the state-of-the-art experiments and for a pIFA in Fig.3.10a. ISR values for the novel IFAs compared to the state-of-the-art results in Fig.3.10b. . . . . . . . . . . . . . . . . . . . . . 4.1 Example of a Legitimate Interest in the topmost box and of a Fake Interest in the bottommost box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Taxonomy of reactive and proactive IFA countermeasures. . . . . . . . . . . . . . 4.3 An overview of the architectural components for the deployment of the proactive countermeasure Charon. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Interest Drop Ratio (IDR) for two dierent monitoring nodes, monitor1 in 4.4a and monitor3 in 4.4a, of the CNMR technique when the network is under a pIFA with attack frequency equals to 1000 ipps. The IDR is shown for both Legitimate Interests (LIs) and Fake Interests (FIs). . . . . . . . . . . . . . . . . . . . . . . .

  Among the ICN instances, the Named-Data Networking (NDN) has generated a considerable momentum since its original inception in 2006. The NDN architecture envisions to replace the Internet hourglass model's tiny waist, i.e., the Internet Protocol, with a layer working on nameddata. Name-based anycast routing and opportunistic in-network storage are included in the NDN layer-3 to nd and fetch closest replicas of the required contents in the network. NDN implements an asynchronous communication model based on the exchange of two dierent network packets, one requesting a content, Interest, and the other one carrying back the content itself, Data. Interests travel through the network without specic destination addresses rather by following name-based forwarding tables' entries to any source of the specied content. Forxi warded Interests are recorded by routers in dedicated Pending Interest Tables. Trails are left by

  Chapter 1 gives an introduction to the research on future Internet architectures. Firstly, it summarizes some of the current Internet issues and outlines the future requirements for a global inter-networking architecture. Secondly, it provides an overview of the Information-Centric Networking (ICN) research paradigm. Finally, it describes the main building blocks of the Named-Data Networking (NDN) architecture. Chapter 2 focuses on the Pending Interest Table (PIT) component of the NDN forwarding plane. Chapter 2 details the PIT component structure and operations, it explores the possible data-structures for a PIT, it discusses the main design challenges for this component and nally it analyzes its directly and indirectly enabled properties. Chapter 3 introduces the Interest Flooding Attack (IFA), an NDN-specic Denial Of Service (DoS) attack exploiting the PIT stateful forwarding mechanism. Chapter 3 identies aws in the state-of-the-art countermeasures against the IFA and leverages those to dene a steadier attacker model. Further, chapter 3 introduces a new set of IFAs built upon the novel attacker model. Finally, chapter 3 presents a re-assessment of existing IFA countermeasures against the novel IFAs. Results of the evaluation reported in chapter 3 shed a totally dierent light on the ecacy of the state-of-the-art defense mechanisms against realistic IFAs and so, call for a dierent set of countermeasures to protect the NDN against this threat. Chapter 4 denes proactive IFA countermeasures, which are novel defense mechanisms against IFAs inspired by the issues with the state-of-the-art ones outlined in Chapter 3. Chapter 4 introduces Charon, a novel proactive IFA countermeasure. Chapter 4 illustrates Charon's design and tests it against the novel IFA attacks. Chapter 4 shows Charon counteracts the latest stealthy IFAs better than the state-of-the-art reactive countermeasures. Chapter 5 explores alternative xii forwarding mechanisms for the NDN architecture and illustrates the NDN.p4 design, that is, the rst implementation of an ICN protocol written in P4. Firstly, chapter 5 classies existing alternative forwarding mechanisms with respect to a set of PIT cardinal properties. Secondly, chapter 5 proposes to leverage novel programmable-networks technologies to test and evaluate dierent NDN forwarding plane designs.

  The above observations seem to represent solid arguments for the design of a dierent Internet whose main focus is information more than communication endpoints. As the denition may suggest, the main goal of ICN is to shift the focus of the current Internet architecture from 'where' a certain information is stored to "what" the information is actually about. Hence, content 1 itself becomes the rst-class citizen of the network. This would imply a shift in the semantics of the datagram unit because that would need to convey some sort of indication about the packet payload. This shift mainly aims at more ecient content localization and distribution at the network-level. Nevertheless, decoupling contents from specic sources also opens novel promising perspectives to rethink solutions to deal with other collateral issues: mobility of terminals, IP addresses scarcity, security of data-exchanges and fast recovery mechanisms from network disruptions.

Figure 1 . 1

 11 Figure 1.1 The hourglass model of today's Internet and the IP datagram structure.

Figure 1 . 2

 12 Figure 1.2 The genealogy of the research on ICN from TRIAD to the current days.

Figure 1 . 3

 13 Figure 1.3 An example of both HRN and SCN.

  ternet has been improved by means of several content distribution mechanisms like Web caching, Content Delivery Networks, carrier network Transparent Caching. These solutions have led to the deployment of storage resources owned by dierent operators across dierent network segments. Hence, they are suboptimal in terms of required resources, management costs and further they show low or no interoperability. Instead, ICN "democratizes" the content distribution freeing the content providers from buying specic services from the CDN operators and from relying on the ad-hoc infrastructure deployed by the ISPs in order to achieve an ecient distribution of their contents. By implementing content distribution features at the network level, ICNs breaks the current monopoly of CDN operators, ISPs and big content providers. Though this scenario calls for new accounting schemes for ISPs and content providers[START_REF] Ghali | Practical accounting in content-centric networking[END_REF].New security/mobility models: by decoupling senders and receivers in space and time, ICN opens new security and mobility scenarios. With regard to the security, ICN nally untangles Internet from the authentication of every sender, receiver and channel between them. In fact, ICN delineates a security model where every content has to be secured independently of the source providing and/or storing it. The ICN content-oriented security model theoretically avoids specic nodes to be target of an attack because of the absence of addresses. With regard to the mobility, ICN applications do not necessarily need to track down mobile terminals since every data-exchange is only based on a named content. Freeing the applications from the notion of topological locators radically changes the layer in the stack where to deal with the mobility

  on content-oriented networks. The original CCN architecture has been iteratively rened over years of research on architectural challenges and applications design done by PARC and the NDN's consortium. A precise timeline of the CCN/NDN project is out of the scope of this work. Nevertheless, the rest of this section tracks the evolution of the two siblings architectures through some milestones which are illustrated in Fig. 1.4.

Figure 1 . 4

 14 Figure 1.4 Timeline of Named-Data Networking and Content-Centric Networking projects.

Figure 1 . 5

 15 Figure 1.5 Interest-Data exchange in an NDN network.

Figure 1 . 6

 16 Figure 1.6 Format of Interest and Data packets from the slides presented by A. Afanasyev at the Jan17 ICNRG Interim Meeting.

  This chapter has introduced the clean-slate research on future Internet architectures with a specic focus on the Information-Centric Networking (ICN) paradigm. The main ICN design principles, the research challenges and the opportunities in the deployment of such architectures have been presented. Among the ICN realizations, the Named-Data Networking (NDN) architecture has been described in more depth since it has been the main target of the research of this dissertation.The next chapter focuses on the description of the Pending Interest Table (PIT), a core component of the NDN's forwarding plane. The PIT enables the basic data-exchange in the NDN architecture. Yet, the PIT exposes the NDN architecture to a severe security threat this work has studied and addressed from dierent perspectives. Therefore, Chapter 2 provides the background to understand the role of the PIT in the NDN and the vulnerability it exposes.

  be many similar Data packets consuming the same PIT entry. Nevertheless, for sake of generality, the exact match lookup for both Interests and Data is mostly considered when reasoning about the logical structure of the PIT.The most common operations done by the PIT are summarized in Fig.2.1. For the sake of generality, any outcome of the Forwarding Strategy module, which indeed makes the nal forwarding decision for every Interest, is not considered. At the reception of a new Interest, a successful forwarding operation generates a new PIT entry as showed in Fig.2.1a. The generated entry records incoming and outgoing interface, the Interest nonce and the entry lifetime (e.g., respectively the values {i1}, {o4}, {bcd...a2}, {2s} of the third PIT entry generated in Fig.2.1a).Because of multipath routing protocols which do not feature loop avoidance, in NDN the same Interest could be received twice at the same router. However, a duplicate is easily detected and dropped thanks to the recorded Nonce values in the related PIT entry as shown in Fig.2.1b.When an Interest for an existing PIT entry is received at a dierent input interface, the new interface and the nonce are added to the existing entry as shown in Fig.2.1c. An Interest can also be retransmitted either by a consumer or by a router's forwarding strategy module. Nonces are used to distinguish retransmissions from the original Interests. A retransmitted Interest carries a new Nonce, so it updates an existing entry as shown in Fig.2.1d. A Data packet is said to be solicited when there exists a related PIT entry whose list of outgoing interfaces contains the interface where the Data has been received. Copies of a solicited Data packet are forwarded downstream to all the incoming interfaces recorded by the related PIT entry as shown in Fig.2.1e.A solicited Data also consumes the related PIT entry. When the interface where a Data packet is received is not in the list of the outgoing interfaces of the related PIT entry, the Data is considered unsolicited and so dropped as shown in Fig.2.1f. Unsolicited Data do not alter the related PIT entries.In summary, the PIT provides two main services: Interests aggregation at Interest reception and multicast Data delivery at Data reception. The Interests aggregation happens when a new Interest is received and a PIT entry with that name already exists (e.g., in Fig.2.1b, 2.1c, 2.1d). The outcome of the aggregation depends on whether or not a similar Interest was either previously received on a dierent interface. If so, the related PIT entry has to be updated to record the new interface (e.g., in Fig.2.1c, 2.1d). If not, the new Interest can be simply dropped without taking any further action (e.g., in Fig.2.1b). The multicast Data delivery happens when a new Data packet is received and there exists a related PIT entry. Multiple copies of the same Data packet are forwarded downstream on all the interfaces recorded in the corresponding PIT entry (as in Fig.2.1e). Overall, the PIT keeps a natural ow balance between Interests and Data since, at every router, it does neither transmit duplicate Interests nor accept duplicate Data.

Figure 2 . 1

 21 Figure 2.1 Illustrations of the dierent PIT operations at Interest and Data reception, numbers in parenthesis indicate the temporal sequence.

Figure 2 . 2

 22 Figure 2.2 Examples of the Name Prex Trie (NPT) in Fig. 2.2a and of the Encoded Name Prex Trie (ENPT) in Fig. 2.2b.

Figure 2 . 4

 24 Figure 2.4 Illustration of the data-structure and the table entry for the linear chaining hash-

Figure 2 . 6

 26 Figure 2.6 Illustration of the data-structure and of the table entry for the d-leftCBF (dlCBF) PIT design.

  sures vulnerable to attackers which may adjust their Interest generation pattern to inuence collected statistics or exploit routers' monitoring time windows. The latter makes it easy to drop malicious trac once a certain prex has been detected as infected. None of the two factors was considered by attacker models in related work. Therefore, this work proposed a stealthy attacker model where attackers would mimic real content names and vary the attack characteristics over time in order to remain undetected by routers. Sec. 3.1 introduces the IFA security threat and a novel related attacker model. Sec. 3.2 provides an overview of the state-of-the-art IFA countermeasures by outlining weak points both of the existing defense mechanisms and in the related evaluation scenarios. Sec. 3.3 proposes some new IFAs based on the novel attacker model, which capitalize on the pitfalls of existing defense mechanisms. The ecacy of those novel IFAs against the most eective state-of-the-art countermeasures has been proved by extensive experiments which are summarized in Sec 3.4. Overall, according to the results presented in this chapter, the exploration of the design space for coun-termeasures against this NDN-specic security threat is still incomplete. Therefore, alternative research directions are presented in the next chapters.

Figure 3 . 1

 31 Figure 3.1 Illustration of an IFA targeting a Wikipedia content provider on an NDN network. Malicious users produce closely-spaced Interests for non-existent contents (alias Fake Interests) which persist on routers' PITs until expiring. Aected routers are across the path to the content provider. Thus, as a result, Legitimate Interests (LIs) may be frequently dropped by some router whose PIT is full (e.g., routers R4 and R5).

  in Sec.3.4. Satisfaction-Based Pushback (SBP)[START_REF] Afanasyev | Interest ooding attack and countermeasures in named data networking[END_REF] implements a three-fold strategy to reduce the impact of an IFA. First, SBP uses the Interest Satisfaction Ratio (ISR) of an interface as probability to either forward or drop incoming Interests to penalize malicious trac. Second, SBP implements separate queues on output interfaces to establish fairness among dierent input interfaces. Third, SBP adjusts forwarding rates on interfaces according to rate limits pushed back by upstream routers.

3 . 3

 33 assumes attackers and legitimate consumers issue Interests with dierent prex names. In those conditions, mitigation techniques applied at the prex-level result extremely eective since they do not penalize any legitimate Interest. Indeed, as specied by the steadier attacker model described in Sec. 3.1.3, attackers have the ability to precisely produce Interests both for existing contents and non-existent ones. Therefore, attackers aim to masquerade their malicious Interests with the legitimate ones to remain undetected by routers. Therefore, those mitigation techniques dropping Interests with an infected prex name inevitably aect some legitimate trac too.

3 . 3 . 2 .

 332 All the experiments have been conducted on version 1.0 of the opensource ndnSIM [128] module to fairly compare to the state-of-the-art countermeasures which were implemented and evaluated on that version of the simulator. The ndnSIM extensions implementing the novel attacks and all the tools developed for the sake of this work have been made available at [133] in order to reproduce the reported experiments.

Figure 3 . 2

 32 Figure 3.2 Interest Satisfaction Ratio (ISR) in 3.2a and PIT Utilization Ratio (PUR) in 3.2b for the experiments presented in [1] and reproduced by this work.

10 .

 10 Figure 3.3 PIT Utilization Ratio (PUR) average values for all the routers in Fig. 3.3a with dierent attack frequencies and for monitoring routers in Fig. 3.3b in the SoA experiments.

  Figure 3.4 PIT Utilization Ratio (PUR) values for all the CNMR's monitoring routers under an the attack mounted in [1] and the pIFA introduced by our work. Results for the 1000 ipps attack frequency are plotted. The simulation scenario includes 8 monitoring routers whose PURs are reported on 8 dierent colored curves. The curve in black plots the average values.

Fig. 3 .

 3 Fig.3.5b also shows a 10% increment of the PUR in CNMR's monitoring routers compared to the SoA results for both the baseline and the CNMR scenario, consistently with the observed ISR decrease. It is worth noticing that SBP achieves lower PUR values compared to CNMR because of the higher amount of Interests dropped to mitigate the attack.

Figure 3 . 5 Figure 3 . 6

 3536 Figure 3.5 Interest Satisfaction Ratio (ISR) and PIT Utilization Ratio (PUR) under the pure IFA (pIFA). The PUR is computed over all the routers in the network.

Figure 3 . 7 Figure 3 . 8

 3738 Figure 3.7 Interest Satisfaction Ratio (ISR) and PIT Utilization Ratio (PUR) for dierent bIFA's purity levels.

  Figure 3.10 ISR values for the baseline and with CNMR on for both the state-of-the-art experiments and for a pIFA in Fig. 3.10a. ISR values for the novel IFAs compared to the state-of-the-art results in Fig. 3.10b.

4 . 1 .

 41 A valid globally routable prex name allows FIs to traverse the network towards content sources and create state in routers' PITs. The spoofed content identiers are easily discarded by the content providers which however do not notify network about those invalid requests (at the time being the denitive role and adoption of negative acknowledgments in CCN/NDN-like networks stays unclear[START_REF] Compagno | To nack or not to nack? negative acknowledgments in information-centric networking[END_REF]). Nevertheless, FIs create long-lived state in PITs since the related entries last until the PIT entry expiration time.FIs' strength resides in being easy to generate and hard to detect. In fact, endless dierent invalid content identiers can be trailed to valid routable prex name. A valid prex name is the only information looked up by routers to decide about an Interest forwarding. While no check is done on the content identier.

Figure 4 . 1

 41 Figure 4.1 Example of a Legitimate Interest in the topmost box and of a Fake Interest in the bottommost box.

Figure 4 . 2

 42 Figure 4.2 Taxonomy of reactive and proactive IFA countermeasures.

3 Figure 4 . 4

 344 Figure 4.4 Interest Drop Ratio (IDR) for two dierent monitoring nodes, monitor1 in 4.4a and monitor3 in 4.4a, of the CNMR technique when the network is under a pIFA with attack frequency equals to 1000 ipps. The IDR is shown for both Legitimate Interests (LIs) and Fake Interests (FIs).

  simulation scenarios has already revealed unknown behaviors of other defense mechanisms. For example, Fig.4.4 plots the IDR measured at dierent CNMR's monitoring nodes for both Legitimate and Fake Interests. The plots in Fig.4.4a and in Fig.4.4b show that the portion of legitimate trac aected by a monitoring node in CNMR is not proportional to the load of received Fake Interests. In fact, while the monitoring node in Fig.4.4a and the monitoring node in Fig.4.4b hold the same load of Fake Interests (the IDR represented by the red curve), the amount of legitimate trac they aect (the IDR represented by the green curve) is dierent. This result suggests that indeed monitoring nodes exhibiting a lower IDR for Legitimate Interests receive part of those Interests on interfaces which are not subject to any mitigation.

  (a) Average ISR of legitimate clients under pIFA (b) Average PUR of all the routers under pIFA

Figure 4 . 5

 45 Figure 4.5 Interest Satisfaction Ratio (ISR) in 4.5a and PIT Utilization Ratio (PUR) in 4.5b under a pIFA with attack frequency of 1000 ipps.

Fig. 4 .

 4 Fig. 4.5a and Fig. 4.5b illustrate respectively the average ISR and PUR values in a scenario where the network is under a pure Interest Flooding Attack (pIFA) (see Sec. 3.3.2 of chapter 3for a description of the attack). In a pIFA, attackers use o-line generated list of spoofed content identiers to precisely issue only Fake Interests, that is, Interests for non-existent contents.

Fig. 4 .

 4 Fig.[START_REF] Saltzer | End-to-end arguments in system design[END_REF].5a shows that SBP performs closely to the baseline ND (which is the scenario where no defense mechanism is on). In the same plot, CNMR improves compared to the baseline yet still suers from around a 30% loss of the original ISR measured at clients. In the same scenario, Charon totally preserves legitimate trac from any degradation of service since it easily detects Fake Interests by querying the BF-based content summary held by every router. With regard to the load on the network generated by a pIFA, Fig.4.5b shows Charon blocks the attackers to generate any additional load on routers since their Fake Interests are almost (except a few false positives whose eect is negligible) never forwarded farther than the rst network hop.

Fig. 4 .

 4 Fig. 4.6a and Fig. 4.6b illustrate respectively the average ISR and PUR values in the same evaluation scenario where the network is under a blended Interest Flooding Attack (bIFA). The

Figure 4 . 6

 46 Figure 4.6 Interest Satisfaction Ratio (ISR) in 4.6a and PIT Utilization Ratio (PUR) in 4.6b under a bIFA with attack frequency of 1000 ipps.

Figure 4 . 7

 47 Figure 4.7 Interest Satisfaction Ratio (ISR) in 4.5a and PIT Utilization Ratio (PUR) in 4.5b under a cIFA with attack frequency of 1000 ipps.

Fig. 4 .

 4 Fig. 4.7a and Fig. 4.7b illustrate respectively the average ISR and PUR values in the same evaluation scenario where the network is under a chamaleonic Interest Flooding Attack (cIFA).In cIFAs, attackers periodically change target prex name to avoid prex name-based mitigation techniques activated after a certain observation time window. The change of the target prex name nullies the rate-limit which is applied to that prex name after the detection. If attackers

  simply a target. The P4_14 13 language specication is based on a specic abstract model of a forwarding element. The forwarding model is composed of a programmable parser, a buer for packet headers and metadata, an ingress and an egress pipelines of match-action tables as shown in Fig.5.2.1 (the processing pipeline of this model mimics the commonplace design of some of the latest fully-programmable forwarding devices[START_REF] Bosshart | Forwarding metamorphosis: Fast programmable match-action processing in hardware for sdn[END_REF] 161]).

Figure 5 . 1

 51 Figure 5.1 The abstract forwarding model for the P4_14 language specication [2].

5. 3 . 1 Figure 5 . 2

 3152 Figure 5.2 Interest for ndn:/named-data.net/publications/ndn_ccr/le.pdf

Figure 5 . 3

 53 Figure 5.3 Some parser states and header denitions in NDN.p4

5. 4 .

 4 The b_table (in the top-right box in Fig.5.4) includes the total number of name components, the full hash of the name and the hashes of the shorter prexes as matching elds. The route A for the prex "/a/b/c" is made of a number of table entries equals to n -m + 1 m ∈ [0, n],

Figure 5 . 5

 55 Figure 5.5 Illustration of the control ow of the ingress pipeline of the NDN.p4 program.

5. 4 .

 4 Summarythe conclusions drawn by the contributions presented in Chapters 3 and 4. Those ndings about IFA countermeasures exacerbate the fear about the impossibility to protect eectively the NDN architecture from all the possible variants of this attack. Therefore, it is worth exploring, as already witnessed by several recently-emerged related works, the design of dierent forwarding planes for the NDN. For that purpose, it is of foremost importance to establish both the cardinal PIT properties to be kept by such an alternative forwarding plane and the ones that can be relaxed or lost instead. Along this line, this chapter has introduced a proper evaluation framework and classied existing alternative forwarding proposals according to it.Nevertheless, the comparison of alternative NDN data-plane designs is made dicult by the lack of open-source NDN router designs. In fact, existing NDN designs are tailored to specic software/hardware platforms and sometimes closed, hence, dicult to share, evaluate and modify. Hence, this work seminally has proposed to leverage the latest advances in the eld of programmable data-planes to produce high-level and portable NDN router designs. Although the NDN.p4 data-plane design was constrained by the P4 technology's infancy at the time it was proposed, it has in any case outlined the potential of those emerging technologies to be leveraged to ease the deployment and test of ICN solutions. As better explained in the last section of this manuscript that presents the opportunities for future work, today's languages and platforms for packet processors can be leveraged to improve the NDN.p4 design and nally transform that in the originally envisioned platform meant for researchers to experiment with dierent data-plane designs for the NDN. Résumé Ce travail illustre comment les tendances actuelles d'utilisation dominant sur Internet motivent la recherche sur des architectures futures de réseau plus orientées vers le contenu. Parmi les architectures émergentes pour l'Internet du futur, le paradigme du Information-Centric Networking (ICN) est présenté. ICN vise à redénir les protocoles de base d'Internet an d'y introduire un changement sémantique des hôtes vers les contenus. Parmi les architectures ICN, le Named-Data Networking (NDN) prévoit que les demandes nommées de contenus des utilisateurs soient transmises par leur nom dans les routeurs le long du chemin d'un consommateur à une ou plusieurs sources de contenus. Ces demandes de contenus laissent des traces dans les routeurs traversés qui sont ensuite suivis par les paquets de contenus demandés. La table d'intérêt en attente (PIT) est le composant du plan de données de l'NDN qui enregistre temporaraiment les demandes de contenus acheminés dans les routeurs. D'une part, ce travail explique que le mécanisme d'acheminement à états de la PIT permet des propriétés comme l'agrégation de requêtes, le multicast de réponses et le contrôle natif de ux hop-by-hop. D'autre part, ce travail illustre comment l'acheminement à états de la PIT peut facilement être mal utilisé par des attaquants pour monter des attaques de déni de service distribué (DDoS) disruptives, appelées Interest Flooding Attacks (IFAs). Dans les IFAs, des botnets vaguement coordonnés peuvent inonder le réseau d'une grande quantité de demandes diciles à satisfaire dans le but de surcharger soit l'infrastructure du réseau soit les producteurs de contenus. Ce travail de thèse prouve que bien que des contre-mesures contre les IFAs aient été proposées, il manque une compréhension complète de leur ecacité réelle puisque celles-ci ont été testées sous des hypothèses simplistes sur les scénarios d'évaluation. Dans l'ensemble, le travail présenté dans ce manuscript permet de mieux comprendre les implications des IFAs et les opportunités d'ameliorer les mécanismes de défense existants contre ces attaques. Les principales contributions de ce travail de thèse tournent autour d'une analyse de sécurité du plan d'acheminement dans l'architecture NDN. En particulier, ce travail dénit un modèle d'attaquant plus robuste pour les IFAs à travers l'identication des failles dans les contre-mesures IFA existantes. Ce travail introduit un nouvel ensemble d'IFAs basé sur le modèle d'attaquant proposé. Les nouveaux IFAs sont utilisés pour réévaluer les plus ecaces contre-mesures IFA existantes. Les résultats de cette évaluation réfutent l'ecacité universelle des mécanismes de défense existants contre l'IFA et, par conséquent, appellent à différentes contre-mesures pour protéger le NDN contre cette menace de sécurité. Pour surmonter le problème révélé, ce travail dénit également des contre-mesures proactives contre l'IFA, qui sont de nouveaux mécanismes de défense contre les IFA inspirés par les problèmes rencontrés dans l'état de l'art. Ce travail présente Charon, une nouvelle contre-mesure proactive contre l'IFA, et là teste contre les nouvelles IFAs. Ce travail montre que Charon est plus ecace que les contre-mesures IFA réactives existantes. Enn, ce travail illustre la conception NDN.p4, c'est-àdire la première implémentation d'un protocole ICN écrit dans le langage de haut niveau pour les processeurs de paquets P4. Le travail NDN.p4 est la première tentative dans la littérature visant à tirer parti des nouveaux techniques de réseaux programmables pour tester et évaluer diérentes conceptions de plan de données NDN. Cette dernière contribution classe également les mécanismes alternatifs d'acheminement par rapport à un ensemble de propriétés cardinales de la PIT. Le travail souligne qu'il vaut la peine d'explorer d'autres mécanismes d'acheminement visant à concevoir un plan de données NDN moins vulnerable à la menace IFA. Mots-clés: Information-Centric Networking, Named-Data Networking, securité, déni de service, Interest Flooding Attack Abstract This work illustrates how today's Internet dominant usage trends motivate research on more content-oriented future network architectures. Among the emerging future Internet proposals, the promising Information-Centric Networking (ICN) research paradigm is presented. ICN aims to redesign Internet's core protocols to promote a shift in focus from hosts to contents. Among the ICN architectures, the Named-Data Networking (NDN) envisions users' named content requests to be forwarded by their names in routers along the path from one consumer to 1-or-many sources. NDN's requests leave trails in traversed routers which are then followed backwards by the requested contents. The Pending Interest Table (PIT) is the NDN's data-plane component which temporarily records forwarded content requests in routers. On one hand, this work explains that the PIT stateful mechanism enables properties like requests aggregation, multicast responses delivery and native hop-by-hop control ow. On the other hand, this work illustrates how the PIT stateful forwarding behavior can be easily abused by malicious users to mount disruptive distributed denial of service attacks (DDoS), named Interest Flooding Attacks (IFAs). In IFAs, loosely coordinated botnets can ood the network with a large amount of hard to satisfy requests with the aim to overload both the network infrastructure and the content producers. This work proves that although countermeasures against IFAs have been proposed, a fair understanding of their real ecacy is missing since those have been tested under simplistic assumptions about the evaluation scenarios. Overall, the work presented in this manuscript shapes a better understanding of both the implications of IFAs and the possibilities of improving the state-ofthe-art defense mechanisms against these attacks. The main contributions of this work revolves around a security analysis of the NDN's forwarding plane. In particular, this work denes a more robust attacker model for IFAs by identifying aws in the state-of-the-art IFA countermeasures. This work introduces a new set of IFAs built upon the proposed attacker model. The novel IFAs are used to re-assess the most eective existing IFA countermeasures. Results of this evaluation disproves the universal ecacy of the state-of-the-art IFA defense mechanisms and so, call for dierent countermeasures to protect the NDN against this threat. To overcome the revealed issue, this work also denes proactive IFA countermeasures, which are novel defense mechanisms against IFAs inspired by the issues with the state-of-the-art ones. This work introduces Charon, a novel proactive IFA countermeasure, and tests it against the novel IFA attacks. This work shows Charon counteracts latest stealthy IFAs better than the state-of-the-art reactive countermeasures. Finally, this work illustrates the NDN.p4 design, that is, the rst implementation of an ICN protocol written in the high-level language for packet processors P4. The NDN.p4 work is the rst attempt in the related literature to leverage novel programmable-networks technologies to test and evaluate dierent NDN forwarding plane designs. This last contribution also classies existing alternative forwarding mechanisms with respect to a set of PIT cardinal properties. The work outlines that it is worth to explore alternative forwarding mechanisms aiming to design an NDN forwarding plane less vulnerable to the IFA threat. Keywords: Information-Centric Networking, Named-Data Networking, security, Denial of Service, Interest Flooding Attack.

  and the pIFA introduced by our work. Results for the 1000 ipps attack frequency are plotted. The simulation scenario includes 8 monitoring routers whose PURs are reported on 8 dierent colored curves. The curve in black plots the average values. . . . . . . . . . . . . . . . . . . . . . . . . bIFA). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7 Interest Satisfaction Ratio (ISR) and PIT Utilization Ratio (PUR) for dierent bIFA's purity levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8 Interest Satisfaction Ratio (ISR) and PIT Utilization Ratio (PUR) under the chameleonic IFA (cIFA). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

	3.5	Interest Satisfaction Ratio (ISR) and PIT Utilization Ratio (PUR) under the pure
		IFA (pIFA). The PUR is computed over all the routers in the network. . . . . . .
	3.6	Interest Satisfaction Ratio (ISR) and PIT Utilization Ratio (PUR) under the
		blended IFA (

Table 1 .

 1 [START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF] The ancestors' problem denition and goals.

	Project	Main targets	Main challenges
	TRIAD	to scale content delivery	ecient	content
			routing
	CCNx	to improve current network scalability, secu-	naming and content-
		rity and performance	based security
	DONA	to achieve persistence of names, availability	naming and name-
		and authentication of data	based network prim-
			itives
	CBN	to support the services of a publish/subscribe	ecient routing and
		middleware with a new communication in-	forwarding on novel
		frastructure

datagrams is often achieved via content-oriented publish/subscribe middleware which, however, does not scale well on large communication infrastructures

  by content providers and can be queried to get routes to contents.Finally, no precise naming schema has been dened in CURLING which is the ICN architecture proposed by the COMET project[START_REF]The comet project, content mediator architecture for content-aware networks[END_REF]. In CURLING, names are provided by a Content Resolution System (CRS) where publishers previously registered this information. With regard to the name resolution and data routing, COMET uses a hybrid approach. Name resolution and information localization use the CRS nodes which in turn set up the data routing path from the source of information back to the original requester.Yet, all the successors projects contributed to advancing the understanding of important technical challenges in the design of Information-Centric Networks. For example, they did research on the scalability of the routing tables with dierent naming schemas, on routing protocols and forwarding mechanisms, on security properties and trust models, on novel content-oriented net-

	work APIs.

CCN) and Convergence

[32] use a hierarchical human-readable namespace. Routing is done by names in both architectures. NDN assumes routing tables are populated with aggregated name prexes by means of name-based variants of intra-AS and inter-AS routing protocols. Convergence includes a hierarchical name resolution service, like in DONA, which registers prex names Chapter 1. Future Network Architectures advertised

  Data consumes the related PIT entry, meaning that the PIT entry is deleted after the Data packet is forwarded. Caching of the data packet may happen, however, it depends on the router's caching policy and available resources, e.g., free storage space. So, R2 will have a new cache record for the Data content and the PIT entry previously

	1.2. A primer on Content-Centric/Named-Data Networking
	On the other hand, the NDN project has so far gathered together in a consortium roughly 30
	members equally spread across founding universities, industrial partners and other academic
	institutions. Undeniably, the NDN consortium has been able to foster a vibrant ecosystem of
	research on future Internet architectures beyond the NDN architecture itself. Since 2014 the
	NDN consortium has been pursuing more research on and validation of the NDN architecture
	over the key areas of Health IT and Cyberphysical Systems under the umbrella of a next-phase
	NSF's award [37].
	1.2.2 The Named-Data Networking Architecture
	Communication in NDN is achieved asynchronously by means of two dierent packets: Interest
	and Data. An Interest represents a request from a certain consumer for the network to fetch
	some content or access some service, while a Data contains the content/service itself. Neither
	Interests nor Data carry any address, since both packets are named instead and the names are
	used to route them across the network. The communication is receiver-driven; hence, Interests
	trigger Data to be fetched and forwarded downstream to consumers. Every NDN router holds
	the three following main data-structures:
	• Content Store (CS): the router's local cache used to opportunistically store Data packets.
	• Pending Interest Table (PIT): a table recording forwarded Interests which have not been
	consumed by any Data yet.
	• Forwarding Information Base (FIB): a name-based forwarding table performing component-
	wise longest prex matching and determining output interfaces to forward Interests.
	An illustration of an Interest-Data exchange in NDN/CCN routers is depicted in Fig. 1.5 where
	the content of a router's data-structures during an Interest-Data exchange is showed too. The
	consumer Alice expresses an Interest to fetch the le "ndn-protocols.pdf" held by Bob. Alice's
	Interest traverses in sequence the routers R1-R2-R3. At each router the following operations
	take place. First, the router checks if it holds a local copy of the requested content by looking
	up its CS. If so, a copy of the content is sent downstream through the interface where the
	Interest was received. If not, the Interest is looked up to the PIT to check if there are similar
	pending requests. If a PIT entry for the same name exists, then the Interest is dropped while
	the PIT entry is updated if the interface has not been seen yet. If the router does not have
	any PIT entry, then the FIB is looked up to forward the Interest to a next hop upstream. The
	FIB lookup consists of a Longest-Prex Match (LPM) on the name components. This LPM
	selects the FIB entry with more name components over all the matching entries. The matching
	FIB entry provides one or more output interfaces out of which the Interest can be forwarded.
	If there is a matching FIB entry, the Interest is forwarded and a new PIT entry tracking the
	Interest name and the incoming interface is created. The status of R2's PIT after the Interest
	is processed is reported in Fig. 1.5 and it consists of one entry with the Interest name as key
	and the incoming interface as value. Once a Data packet is found, e.g., when Alice's Interest
	reaches Bob, that is forwarded downstream on the reverse path by following the respective PIT
	entries. At each router, processing of Data consists of checking if the Data is solicited (that is,
	corresponding to any PIT entry), possibly forwarding downstream and/or caching. Unsolicited
	Data are dropped. Solicited Data are forwarded out the interfaces recorded in the corresponding
	PIT entries. Further, a solicited

  detects possible looping ones. Between the Name and the Nonce, an Interest may include Selectors. Selectors are optional elds which can be used to either fetch or avoid to fetch specic contents. At the end of the packet, an Interest may also include two other optional elds called Guiders. Guiders indicate how far, in the Scope eld, and for how long, in the InterestLifetime eld, an Interest may propagate.

	1.2. A primer on Content-Centric/Named-Data Networking
	1.6. All the packet
	elds in Interest and Data follow the variable-length Type-Length-Value (TLV) encoding spec-
	ied in [61]. The Name eld, present in both Interest and Data, is made of a variable number
	of TLV elds each containing a single name segment (see the following "naming" subsection).
	The full name of a Data packet should also contain a nal digest component within the Implic-
	itSha256DigestComponent eld. However, this implicit digest may appear in an Interest and is
	never included in Data packet explicitly. An Interest must contain a randomly-generated 32 bit
	nonce too. In fact, the combination of the Name and a Nonce uniquely identies an Interest and

thus

  1.2.2 of the rst chapter. The PIT is the functional block responsible to record forwarded upstream Interests which wait to be consumed by potential Data downstream. Abstractly, the PIT can be seen as an associative memory binding Interest names to supplementary information about forwarded Interests. At each node, each forwarded Interest is recorded through a PIT entry.Generally, a PIT entry associates the Interest name to the following information at least: an expiration time, two lists of interfaces, and a list of nonces. The expiration time indicates the longest duration for which the entry lasts in the PIT before being deleted if no Data consumes it. A list of the interfaces where a certain Interest has been received is needed to perform a correct multicast delivery when the related Data packet is received. A PIT entry also records the outgoing interfaces, that is, where the Interest has been forwarded to. A track of outgoing

interfaces is used to i) dierentiate between solicited and unsolicited Data, ii) do performance measurements. A list of seen nonces unambiguously tracks dierent Interests.

In theory, a PIT performs a lookup through an exact match of Interest and Data names. That is, the full Interest or Data name is used to lookup the table for existing records. In practice, the NDN protocol denes two more prex name matches performed by the PIT (see Sec.

2.2 of [84]

). Further, a ner search in the PIT can be activated through optional Interest header elds. Overall, an Interest matches existing PIT records according to its name and the selectors elds (see Packet format in Sec. 1.6 of chapter 1). While, a data packet matches all the records sharing a common name prex. Thus, for example, the entry whose name is "/ndn.com/le/docs.zip" would be matched by any of the following: '/ndn.com/le/docs.zip/v1', '/ndn.com/le/docs.zip/annexes', '/ndn.com/le/docs.zip/errata'. By consequence, there could

  [START_REF] Clark | The design philosophy of the darpa internet protocols[END_REF] An example of bloom lter used to record pending Interests. The lter is initially all set to 0. At every Interest reception, the Interest name is hashed k times, with each hash producing several bit locations in the lter which are set to 1. To check if an Interest/Data is in the lter, its name is hashed k times and the corresponding bits in the lter are checked. If at least one corresponding bit in the lter is not set, then the lter does not hold this Interest/Data.

  are an excellent candidate for exact matches on Interest names. In fact, Interest names, which work as keys for PIT entries, can be added to a bloom lter and then the lter can be queried to check if a new packet, Interest or Data, corresponds to any existing set element as illustrated in Fig.2.3. Further, there exists a considerable amount of literature about the use of BFs for packet processing algorithms[START_REF] Kirsch | Hash-based techniques for high-speed packet processing[END_REF]. In fact, BFs have two appealing properties i) they An early idea to leverage BFs to compress the PIT, named United Bloom Filter (UBF), was sketched in[START_REF] Li | Compression of pending interest table with bloom lter in content centric network[END_REF]. Therein, a BF is associated to each interface and the PIT is seen as the union of all those BFs. That design accepts False positives at Interest and Data reception assuming retransmissions deal with those. UBF uses two binary BFs rather than CBFs since the latter ones cause incorrect deletion when false positives happen at Data reception. Regular deletions are implemented through a mechanism of aging between dierent epochs where the two BFs are swapped and one of them is cleared. UBF assumes all PIT entries exist for a short amount of time and so they can be deleted after that anyway.

	side or in the network, this is denitely an undesirable critical eect.
	(B) a false positive at Data reception creates two issues: i) incorrect downstream Data forward-
	ing where no related Interest had been previously received; ii) incorrect deletion since the
	BF is updated by an incorrect Data forwarding and, thus, state relative to other Interests
	is irreparably lost. The former issue is most likely naturally solved by other downstream

are compact, ii) they do not generate false negatives, that is, if the query result is negative, the element is surely not part of the set. Those properties make possible to design compact lters which can be queried quickly before performing any more cost-intensive operation. For example, BFs have been used to speed up IP longest prex matching algorithms

[START_REF] Dharmapurikar | Longest prex matching using bloom lters[END_REF]

. Therein, BFs stored in on-chip memories are used to footprint the set of IP prexes which are stored in hash tables on o-chip memories. This idea reduces drastically the number of hash table lookups with the assumption that those are slower and more costly than the BF ones.

Although bloom lters are able to compactly store sets of elements which can be queried quickly, they cannot be applied straightforwardly to represent a table of the pending Interests for three main reasons. Firstly, a PIT entry contains more information than the Interest name itself.

Interest names can be stored in a bloom lter, but the other entry's information (see Sec. 2.1) cannot. Therefore, when BFs are used to represent a PIT, a subsidiary data-structure is required to store the full entries. Secondly, traditional binary BFs do not support deletions of elements where PITs needs to be updated when either Data consume existing entries or those expire after a timeout. To overcome this second issue, a BF variant, which is called Counting Bloom Filter (CBF) and requires more space in memory, can be used. CBFs replace binary digits in BFs with integer counters. Last but not least, even though the error probability is tunable and can be kept very low, BFs can always generate false positives.

With regard to false positives, it is important to understand their consequences and take the necessary precautions in any BF-based PIT design. A BF-based PIT is queried both at Interest and Data reception. The verication process is identical, but the consequences of a false positive in those two cases are dierent:

(A) a false positive at Interest reception means that an Interest which indeed was not seen before is wrongly considered to be duplicate. As result, the Interest is dropped and not forwarded. Although there could be Interest retransmission mechanisms either at the client routers, where the Data are detected as unsolicited and so dropped. The consequence of the forwarding is some unnecessary consumption of network data rate. As for the issue with false positive at Interest reception, the latter issue can be mitigated by regular Interest retransmissions, but it is considered more critical than the former one.

DiPIT, a PIT design based on BFs, was proposed in

[START_REF] You | Dipit: A distributed bloomlter based pit table for ccn nodes[END_REF]

. The DiPIT design aims to tackle the issues generated by false positives, which aect the regular Interest and Data forwarding as detailed in points (A) and (B), by lowering the related probability. DiPIT is made of per-face counting bloom lters complemented by a single shared binary bloom lter. DiPIT features separate BFs not to explicitly keep track of Interests incoming interfaces. The single shared BF is queried when any of the CBFs generates a positive response for an Interest name. The additional BF is meant to lower the probability of the A issue as that is the product of the false probability errors of the two bloom lters. So, received Interests are checked rst against the per-face CBF. If the check is positive, then a second check is done against the shared bloom lter.

  Luckily, collisions lead to worst case lookup times whose upper bound can be known with high probability.

More in detail, collisions are usually solved by two techniques: chaining and open addressing.

Chaining hash tables store more elements per bucket usually in a linked list. Chaining avoids collisions, but it increases the number of memory accesses when a collision happens, since multiple elements within the same bucket need to be checked. There exist techniques to improve the performance of hash-table with chaining, which exhibit better probabilistic worst case lookup guarantees (for example, multiple chain hash tables are hash tables where every item is stored in a bucket according to one of several hash functions). Yet another method to resolve collision are the open-addressed hash tables whose buckets store a xed constant number of items. Usually, this number is xed so that all the items in a bucket can be read in parallel (e.g., the size of a cache line). In open-addressed hash-tables, all the items are stored in the table and there are no external lists. So, the advantage of open-addressing is that it eliminates the need for pointers and this extra memory can be used to increase the size of the table itself. The downside of open addressing is that to perform an insertion and a search, dierent slots may need to be examined.

With regard to the PIT, HT-based designs maps keys (Interest names) to values (PIT entries).

An advantage of any HT-based design over to the BF-based ones is that the former can store full information about PIT entries and so preserve PIT properties, like loop detection. Further, authors of

[START_REF] Varvello | On the design and implementation of a wire-speed pending interest table[END_REF]

also motivates why HT-based PIT designs are better amenable to dierent placements on hardware forwarding devices (see Sec. 2.3). The clear disadvantage is that HT-based designs have a bigger memory footprint than the BF-based counterparts.

table .

 . That design achieves a PIT compact representation at core routers by storing xed-length ngerprints instead of full names. Assumptions on Interest aggregation at edge routers are made to preserve the correctness of packet delivery (this design choice is driven by scalability issues in PIT design which are discussed in Sec. 2.3). The data-structure is illustrated in Fig.2.6 and is based on the d-leftCBF (dlCBF) construction proposed in[START_REF] Bonomi | An improved construction for counting bloom lters[END_REF]. A d-leftCBF is a hash table based data-structure which replicates the functionality of counting bloom lters but requires less space. In dlCBF, cells stored in d buckets contain a xed number of bits for ngerprints and counters instead of full elements. The d tables have B buckets which can contain up to E entries.The d hash functions compute the index of the bucket and the ngerprint. The design in Fig.2.6 also includes an overow table since d-left hashtables suer from overow when all the possible buckets where an element could be placed are not empty. Every PIT entry is made of ve elds.

The Occupy bit indicates if the entry is in use and enables the implementation of lazy deletion mechanisms by agging/unagging this bit. The collision bit indicates the presence of one or

  This simple formula would need, of course, to be complemented with assumptions on packet sizes for Interest and Data to estimate Related works on PIT sizing account to only three works[START_REF] Caroglio | Pending interest table sizing in named data networking[END_REF][START_REF] Dai | On pending interest table in named data networking[END_REF][START_REF] Wählisch | Backscatter from the data plane threats to stability and security in information-centric network infrastructure[END_REF] leading to contradicting ndings. Seminary, the work in[START_REF] Wählisch | Backscatter from the data plane threats to stability and security in information-centric network infrastructure[END_REF] analyzed the content state in content-centric networks mainly to identify possible attack vectors. Therein, the router's forwarding state evolution is modeled over time as a function of the link utilization and the average network Round Trip Time (RTT). Nevertheless, content-centric networks are expected to exhibit highly variable RTT measurements because of their intrinsic characteristics (e.g., in-network caching, multipath forwarding). Therefore, dierently from what has been done in the past with TCP, good estimates of average RTT values will be hardly predictable by routers in content-centric networks. By consequence, large RTT uctuations would make it dicult to provision properly resources on routers. In any case, assuming a steady-state model in the absence of retransmissions and packet loss, the lower bounds are estimated respectively as 16 * 10 4 and 16 * 10 6 for the number of PIT entries on 1Gbps and 100Gbps links (assuming maximum link capacity, an average packet size of 1000 bytes and the Internet RTT mean and standard deviation values measured by the PingER project). A further strong, yet apparently premature according to some later work[START_REF] Caroglio | Pending interest table sizing in named data networking[END_REF],

the number of packets which may create and consume PIT state. Practically, there are other factors like content popularity distributions, application request patterns, routers network position which ask for a much more dicult characterization of the resources required for a PIT.

  presents an analytical model of average and medium PIT size over time at steady-state in a single bottleneck scenario. The proposed model is validated on an ad-hoc high-speed platform by using synthetic and trace-driven trac workloads. The model applies a deterministic uid model consistently to what was done on previous well-accredited literature on buer and queue sizing in IP routers. Furthermore, a major contribution is that the model takes into account queue oscillations and dynamics, which have been neglected by previous works. PIT dimensioning is modeled in the very worst case, without in-network caching, Interest aggregation and expiration of PIT entries.

  Backbone routers are estimated to need around 2 million entries in the very worst case. The required number would account for a PIT size of 400 MB in the considered implementation (dleft HT-based PIT in[START_REF] Varvello | On the design and implementation of a wire-speed pending interest table[END_REF]). Such a PIT size would easily t on o-chip DRAM technology yet it could only sustain a few tens Gbps data-rate, which would be a bit less of the requirements for that portion of the network. No indication about PIT size at the edge router are reported, where only a statement about the absence of any concern for dimensioning the component at that stage is made.

  : PIT tables are only placed on each input-line card. By consequence, an Interest creates a PIT entry only on the card where it is received. By contrast, Data packets must be broadcasted to all the line cards except to the one those are received to in order to nd possible related PIT entries. Hence, this placement requires additional switching and multiple PIT lookups at Data reception. Even worse, this placement does not preserve Interest aggregation and loop detection since similar Interests yet received at dierent line-cards generate PIT entries on dierent tables.

  Table for NDN.Meantime, the PIT state in the data-plane establishes properties which go far beyond the original conception of the component. A PIT entry represents network state of the lowest granularity, that is, per-Interest per-hop. Further, the semantics of the PIT state is left undened by the NDN architecture design and so can be leveraged to implement very dierent features. In what follows, some of the mainstream uses of the NDN datagram state are briey illustrated. Nevertheless, for the sake of completeness, it also must be said that potential benets of the NDN stateful forwarding plane are still vividly debated among the ICN research community members.Further, there have been strong claims about "supposed benets" in face of real problems[START_REF] Ghali | Living in a pit-less world: A case against stateful forwarding in content-centric networking[END_REF]. The address-less Interest and Data packets do not carry the identity of a host or a group of hosts. This characteristic makes unfeasible to launch a large set of DoS attacks commonly used in today's IP networks, e.g., TCP ooding, replay attacks.Interest aggregation/collapsing: PIT aggregates duplicate requests for the same content by merging information about similar Interests in a single table entry and by suppressing exact duplicate ones. Merging similar Interests reduces both upstream trac and load on content providers. Overall, Interest aggregation saves network bandwidth.Multicast delivery: PIT entries record incoming interfaces of similar Interests which have been aggregated. This information is used at Data reception to multicast out on dierent downstream interfaces copies of the same Data packet.Multi-path loop-less routing: FIB entries may include multiple next-hops for the same prex name. Therefore, multiple paths can be explored seeking Data for Interests under such prex names. Multiple Data traveling downstream do not create concerns since once the rst received Data consumes the related PIT entry, all the next Data are considered unsolicited and so dropped.

	Anonymous communication: NDN packets contain neither source nor destination addresses.
	The lack of addresses enables anonymous communication between dierent parties where only
	the content is revealed. Forwarding Interests upstream is guaranteed by an anycast name-based
	routing which aims to identify nearby sources of a certain named information. Forwarding Data
	downstream is made possible only by the so-called "breadcrumbs trail" left in routers' PITs by

the related Interests. The PIT state is used to implement Reverse Path Forwarding and deliver Data to consumers who requested them.

Further, host anonymity in NDN shields specic recipients from being targets of Denial-of-service attacks.

Nevertheless, NDN Interest packets have no IP-TimeToLive analogous header eld to limit their lifespan 6 . Meaning that some Interest could loop indenitely (though an application can still specify an Interest's approximate maximum lifetime, see the description of the InterestLifetime packet eld in Sec. 1.2.2 of chapter 1). Such race conditions are avoided by means of Nonce information recorded by PIT entries. Nonces allow routers to distinguish between looped Interests and retransmissions or new requests.

  2.5. Summarywarding state in PITs enables the implementation of a very dierent range of services. Basically, storing information about each Interest enables routers to precisely measure performance of the data-plane (e.g., by measuring at each hop the RTT of every Interest-Data exchange). Those measurements can be leveraged to test forwarding paths as well as to dynamically react to sudden network problems like congested links. The related work in[START_REF] Yi | A case for stateful forwarding plane[END_REF] has already showcased how data-plane designs can leverage the PIT state to achieve robust packet delivery. The forwarding strategy designed in[START_REF] Yi | A case for stateful forwarding plane[END_REF] emits Interests retransmissions, performs proactive interface probing and implements Interest NACKs by using the information stored in the PIT. According to the evaluation, the designed forwarding strategy deals eciently with network congestion, security attacks, broken links.2.5 SummaryThis chapter has described the Pending Interest Table (PIT) component of the NDN's dataplane. The description details the PIT operations in the forwarding of Interest and Data packets across the network. The mechanics of the PIT impose certain requirements to the design of a

	Chapter 3
	Interest Flooding Attacks

data-structure for this table to operate at high link-speeds. Those requirements have been sorted and the state-of-the-art PIT designs have been analyzed. Additional design requirements about the size of table, the scalability, the placement on a hardware forwarding device, the security, have been illustrated too. Among the design requirements for a PIT, the security is the one which stays unsolved at the time being and, so, deserves immediate attention. In fact, by design, the PIT can be easily abused by malicious users to carry out very disruptive Denial-of-Service attacks. For the above reason, the next two chapters address the security of the PIT by reviewing the state of the art on this subject, reassessing existing solutions and proposing novel ones.

To conclude, this chapter also illustrates some ancillary properties enabled by the per-Interest state kept in the PIT. The importance of the PIT state is outlined since it is leveraged today by several mechanisms present in the NDN architecture. Therefore, a clear understanding of those properties is mandatory if the PIT existence has to be rethought. For example, as it is advocated in Chapter 5 where research on alternative forwarding mechanisms is pursued to address the current PIT security issues.

Interest and Data packets carry hierarchical human-readable names which are made of globallyroutable prexes and provider-specic content identiers. NDN packet names are used by a stateful forwarding plane in routers. In fact, processed Interests are temporarily stored by their names in routers' pending interest tables for homonymous Data packets to be routed on reverse paths. On one hand, such status in the network can be leveraged to implement useful features at the data-plane level like loop-free multipath forwarding, ow balance, real-time recovery from network anomalies, etc.

[START_REF] Yi | A case for stateful forwarding plane[END_REF]

. On the other hand, this state exposes NDN networks to novel Distributed Denial-of-Service (DDoS) attacks. Interest Flooding Attacks (IFAs) are NDN-specic DDoS attacks issuing a huge quantity of unsatisable Interests with the aim to exhaust network's and content providers' resources

  routable prex names, e.g., "ndn:/en.wikipedia.org/wiki/technology/media/512h3jh10u ". A valid routable prex name, e.g., "/en.wikipedia.org/ ", allows FIs to create PIT entries in routers across the paths to content sources in the network. Further, assuming there is no specic eviction policy in PITs, FIs maximize related PIT entries lifetime, since those cannot be consumed by any The attack rate (which is the number of MIs per second) is important since MIs saturate router's PIT if their frequency is greater than the one at which the Interests are erased from the PIT, either consumed by Data or expired. Before the work presented in this manuscript, the following IFA variants had been investigated in the related scientic literature: i) IFAs mounted by a weakly-coordinated botnet of consumers issuing FIs, as illustrated in Fig.

	Data packet and so last until expiration (although PIT entries persistence depends on dierent
	expiration timers set by routers, a PIT entry lifetime is supposed to last longer than the average
	Round Trip Time) 7 .
	An IFA consists of the generation of a large number of closely time-spaced MIs targeting one or
	few prex names.
	with the aim
	of classifying unambiguously the Interest types and the respective IFAs.
	Interests whose aim is to fetch Data for a legitimate purpose are commonly referred to Legitimate
	Interests (LIs). While, Interests aiming to achieve network or producers service degradation are

commonly referred to Malicious Interests (MIs). A Malicious Interest can be satisable, when it refers to an existent content or to a dynamically generated content, or Fake, when it refers to a non-existent content (FI). FIs can be easily created by trailing randomly generated strings to 3.1. IFA in NDN networks valid 3.1, which is the attack variant mainly studied by other works in literature; ii) IFAs performed by a botnet of collusive consumers and producers where consumers issue malicious yet satisable

Table 3 .

 3 1 Summary of the IFA impact on dierent targets and of the Interest types used for each purpose.

	Attack target	Attack eects	Interest Type
	Content providers	overwhelmed with requests demanding com-	M I
		putation. Some Interests may require more
		computation on the provider, e.g., for the sig-
		nature generation [117], while FIs can be l-
		tered out by lightweight mechanisms.
	Routers	suering from resources exhaustion, espe-	M I
		cially of PIT space, which causes further in-
		coming Interests to be dropped
	Network infrastructure	saturated links due to a certain size asymme-
		try between Interests and Data packets.

M I -F I = {x ∈ M I : x / ∈ F I}

identication, tries to either stop the attack or reduce the attack's impact. The rest of this section introduces the state-of-the-art IFA countermeasures with a focus respectively on detection techniques in 3.2.1, mitigation mechanisms in 3.2.2, evaluation settings in 3.2.3. Finally, Sec 3.2.4 outlines pitfalls of the presented techniques with regard to those three aspects.

  .2. These countermeasures have been tested against some novel IFAs based on the attacker model presented in 3.1.3. Related results areTable 3.2 Summary of the Collaborative IFA Countermeasures re-evaluated in this work.

	Technique Detection		Reaction	Prex name	Content	Protocol changes
								Identi-
								er
	SBP	none			Probabilistic For-	trivial	dis-	random	appending information
	[105]				warding based on	joint sets	integers	to the name of an Inter-
					ISR values adver-		est with a local scope;
					tised by neighbor		queuing and scheduling
					routers for their		mechanisms at output
					interfaces		interfaces
	DP [116]	local	ISR	rate limit on the	unreported	unreported reserved name-space for
		& PIT us-	infected interface		the communication be-
		age	values	&	dissemina-		tween neighbor routers;
		&	neigh-	tion of alerts to		processing of unsolicited
		bors' alerts	neighbors		Data packets
		reception
	CNMR	locally	at
	[1]	router: per-
		prex	ISR
		& PIT us-
		age values.

Table 3 .

 3 3 Summary of prex names used in literature.

  3.3.3 achieve this goal by changing target prex name over short time intervals. Reaction -As outlined in Sec. 3.2.2, distributed defense mechanisms have so far proved to be more ecient in the detection and mitigation of IFAs, yet they open up other issues:

  3.1.3, prospective attackers can refer to publicly available content lists to spoof content names so those look very similar to valid ones. Moreover, attackers can precisely issue Interests for existent and non-existent contents. This latter ability allows the attackers to dose the generated Interests for specic purposes, like in the attack variants presented in Sec. 3.3.3.For the purpose of the evaluation of the novel IFAs presented in this work, a specic target website has been selected, i.e., the free online encyclopedia Wikipedia (however, the attack is widely applicable to any large website whose list of contents is available). A daily updated list of Wikipedia's page titles is provided by the Wikimedia Foundation[130]. All the content names used in the evaluation of this work share the same valid routable 1-component-long prex name,

which is "/wikipedia.org/". Then, legitimate Interests include one of the English page titles as 1-component-long content identier, which is a variable-length alphanumeric string; while, malicious Interests have a 1-component-long fake content identier generated as described in Sec.

3.3.2.

  Two simple variants of the pIFA have also been proposed in this work. The blended IFA (bIFA) includes attackers generating Interest for both existent contents and non-existent ones. The percentage of Interest for existent contents is a xed portion of the attack frequency per second, called purity level. The purity level is set at a certain value at the beginning of the attack by all the attacking nodes and kept invariant for all the duration of the attack. The main aim of a bIFA is to pollute the detection metrics observed by routers, i.e., the ISR-based ones and the PIT usage. By lowering the ratio of expired Interests over forwarded ones, bIFA attackers try

Table 3 .

 3 4 Summary of the results achieved by our attacks compared to the values in the SoA results. Negative values in the ISR-related columns indicate a decrease of the average quality of service perceived by the clients. Positive values in the PIT-related columns indicate an increase of the average load on routers.

		CNMR-ISR	SBP/DP-ISR	CNMR-PUR	SBP/DP-PUR
	pIFA	-17%	-36%	+10%	+2%
	bIFA	-22%	-38%	+18%	+1%
	cIFA	-28%	-40%	+11%	+3%
	3.5 Summary
	This chapter has introduced the Interest Flooding Attack (IFA), a Denail-of-Service attack which
	capitalizes on the per-Interest PIT state created by regular Interests in the NDN. The IFA
	characteristics and goals have been illustrated before proposing a novel and steadier attack model.

Table 4 .

 4 1 Ideal proactive defense versus existing reactive countermeasures against IFA compared with respect to the Gx requirements. The rating scale includes ve values ranging from very low to very high. The score none is only applied when referring to the infrastructure deployment.

	Technique	Overhead	Protocol	Infrastructure	Ecacy	Impact on
			Compatibility	Deployment		Legitimate Trac
	Reactive -SBP	high	mid	none	mid	very high
	Reactive -DP	high	low	none	mid	very high
	Reactive -CNMR	very high	very low	very high	high	high
	Proactive	very low	very high	none	very high	very low

  The values in the columns Overhead, Protocol Compatibility, Infrastructure Deployment of the reactive techniques have been inferred by the technique descriptions in [105, 116, 1].The Ecacy column values are based both on the evaluation reported in previous related work[START_REF] Afanasyev | Interest ooding attack and countermeasures in named data networking[END_REF][START_REF] Compagno | Poseidon: Mitigating interest ooding DDoS attacks in named data networking[END_REF][START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF] and on the latest results reported in chapter 3. The Impact on Legitimate Trac column values have been measured by this work as described in Sec. 4.3. Table4.1 illustrates how:

  are a perfect candidate to create space-ecient summaries of content identiers under a certain prex name. A BF is a data-structure for membership query which can represent a set of n elements with an array of m bits where m << n (the mathematics behind the bloom lters has been summarized in Sec. 2.2.2 of Chapter 2 where the BloomFilterbased PIT designs have been illustrated). With regard to the three above requirements, rst, BFs guarantee a constant membership test time, so they introduce negligible latency in the processing of Interests. Second, BFs provide a very compact representation for a set of elements, so the related memory requirement is kept low. Third, although BFs introduce false positive (whose error probability can be nely tuned), this does not alter the correctness of the forwarding operation. In fact, a false positive leads to the router marking as valid a content identier which indeed is a spoofed one. The outcome of this error is the forwarding of a Fake Interest. Knowing this probability can be tuned, the impact on the network load will be negligible. This work proposes Charon 12 , a proactive countermeasure against IFAs where NDN routers use BF-based content summaries at run-time to check the validity of the content identier in every Interest name. Charon, except for a few false positives, is able to drop Fake Interests as close as possible those enter the network.

  4.3.1. A novel evaluation metric which measures the impact of a defense mechanism on legitimate trac is introduced in Sec. 4.3.2. Finally, the performance of Charon compared to the state-of-the art countermeasures is discussed in Sec. 4.3.3.

  The Interest Flooding Attack (IFA) represents a severe security threat to Named-Data Networks (NDNs). In fact, the state-of-the-art IFA countermeasures prove to be eective only against naive attackers. Yet, as thoroughly analyzed in chapter 3, eective IFAs built upon realistic attacker models can be easily mounted to disrupt even the most robust defense mechanism. Chapter 4 has introduced the concept of proactiveness in the design space of IFA countermeasures. Later, that theoretical framework is leveraged to instantiate a defense mechanism of that sort to counteract ecaciously the latest proposed IFAs[START_REF] Signorello | Advanced interest ooding attacks in named-data networking[END_REF]. Proactive countermeasures eliminate serious drawbacks experienced by their reactive counterparts. Neither monitoring overhead is required nor delayed reaction is introduced by proactive countermeasures. Nevertheless, proactive defense is not the panacea for IFAs, since this class of defense mechanisms applies well under certain conditions of static content names and publicly available content lists. Provisioning of dynamic contents, a very common scenario nowadays, breaks the assumptions proactive countermeasures are designed upon. Overall, the uncertainty about the ecacy of existing defense mechanisms as well as the poor understanding of the real implications of IFAs for an operational network raise the legitimate question whether or not dierent forwarding mechanisms should be considered at this early stage of design of the NDN architecture.The root cause of the IFA attack is the per-Interest state kept by the Pending Interest Table.As a consequence, both works proposing more lightweight PIT designs[START_REF] Tsilopoulos | Reducing forwarding state in contentcentric networks with semi-stateless forwarding[END_REF][START_REF] Wang | Reducing the size of pending interest table for content-centric networks with hybrid forwarding[END_REF] and works questioning the PIT existence by proposing alternative forwarding mechanisms[START_REF] Garcia-Luna-Aceves | Content-centric networking using anonymous datagrams[END_REF][START_REF] Ghali | Closing the oodgate with stateless content-centric networking[END_REF] have been recently emerging. Nevertheless, replacing the PIT forwarding mechanism in NDNs has several implications. In fact, the PIT guarantees several properties which may be inevitably lost with a dierent data-plane design. Beyond the basic Interest-Data design, the PIT enables, among others, Interest aggregation, Data multicast delivery, sender anonymity and adaptive forwarding

  As widely explained in Chapter 2, the PIT enables the basic Interest-Data packets exchange. Beyond the stateful address-less forwarding mechanism, the presence of per-packet state in the PIT has interesting implications for the role of routing protocols, the design of adaptive forwarding behaviors, the regulation of network trac. Thus, alternative forwarding mechanisms for NDN should not be only considered with respect to the basic Interest-Data exchange but rather by looking at their impact to all the secondary PIT properties. Since the inception of the NDN architecture, several alternative forwarding mechanisms have been proposed with the aim to reduce the amount of necessary state in the PIT. Those works have been mainly driven by concerns about the scalability of and the security threat introduced by the PIT. The former is investigated since the estimate of the amount of resources needed

by the PIT (see Sec. 2.3 in Chapter 2) guarantees this component can sustain certain link speeds. Therefore, a compression of the PIT size could mean the component would t into faster memories. The latter represents a serious concern since, by design, normal users can easily abuse PIT resources in the network to create denials of services. With regard to the PIT scalability, the latest work about PIT sizing [103, 86] suggested available PIT designs can be implemented in fast memories and sustain edge and core network link speeds. Instead, the uncertainty about the ecacy of existing defense mechanisms against IFAs fosters the research on alternative forwarding mechanisms immune to this Denial Of Service attack.

  Infrastructure security and robustness: the absence of end-host addresses in the NDN communication nullies some popular kinds of DDoS attack which aect today's Internet. For example, bandwidth depletion attacks, which ood the network and target victims with unsustainable trac rates, cannot be carried out in NDNs because of the absence of addresses and of the pres-Taxonomy of PIT alternatives At a rst glance, there seem to be only two viable approaches, namely stateless or stateful, to design the forwarding mechanisms in Information-Centric Networking (ICN) architectures. Indeed, several attempts have been made to either reduce the PIT size or replace the PIT component in NDN/CCN networks. Hence, the categorization is broader and includes at least the following categories:

ence of intrinsic mechanisms like Interest aggregation and in-network caching meant to smooth excessive loads. Moreover, the PIT state may be leveraged to design adaptive forwarding behaviors to react against dierent sort of anomalies, e.g., network problems like broken links and/or congestion, malicious behaviors like prex hijacking.

Sender anonymity: the absence of the source address in Interest packets guarantees consumer privacy. That is, a third party cannot determine the source of an Interest only by looking at the Interest packet elds. It is the state in routers' PITs which allows Data to track back the origin of a request. An origin could only be determined if routers collaborated, for example, as postulated in

[START_REF] Dai | Mitigate DDoS attacks in NDN by interest traceback[END_REF]

to trace back sources of an Interest Flooding Attack.

5.1.2

Table 5 .

 5 1 Alternative forwarding mechanisms in NDNs evaluated in terms of cardinal PIT properties. Those techniques generally require a mechanism to track the Interests when those travel through stateless part of the network. In general, routers encode the reverse path in the Interest header which is used to forward the Interest across network portions where no related state has been stored. If the mechanism is not fully deterministic, then the Data delivery may cause overhead since Data are forwarded downstream on unsolicited paths.

	Technique	RPF	Interest ag-	Multicast	Security	Sender
			gregation			Anonymity
	Aggregation	YES	YES	YES	YES	YES
	Hybrid	YES	Some	YES	Some	YES
	Routing-	NO	NO	NO	NO	NO
	based
	State-	YES	NO	YES	YES	YES/NO
	shifting
	functions applied by routers [140].

Table 5 .

 5 1 summarizes whether these forwarding mechanisms keep or lose the PIT properties previously described in 5.1.1.On the one hand, aggregation and hybrid techniques seem to be promising solutions since those preserve many of the original PIT design properties. For example, all the cardinal properties stay unaltered for the fraction of Interests which are forwarded statefully by hybrid techniques, since the basic PIT forwarding mechanism is neither replaced nor eliminated. However, those techniques only partially eliminate the exposure to Interest Flooding Attacks, which, by the way, is the main concern driving the research on alternative forwarding mechanism designs. In fact, those techniques bring only a reduction of the overall forwarding state in the network and do not eliminate the possibility for malicious users to generate that.On the other hand, routing-based and state-shifting techniques eliminate the issue with the state in the network, though as a consequence they lose some of the related PIT properties. Generally, those techniques completely lose the ability to perform in-network Interest aggregation. However, it is interesting to analyze the mechanisms those techniques put in place to preserve some of the other cardinal properties which are lost because of the absence of the PIT state.

  5.1.3 Questioning PIT benetsSome of the latest proposed alternative forwarding mechanisms for NDN/CCN networks[START_REF] Ghali | Closing the oodgate with stateless content-centric networking[END_REF][START_REF] Garcia-Luna-Aceves | Content-centric networking using anonymous datagrams[END_REF] present strong arguments against the cardinal PIT properties. Those works try to demonstrate that the PIT may be infeasible in practice because of actual network ISP agreements and of the unsolved security issues which are inherent to its stateful design. Moreover, many of the claimed benets, like reduced end-to-end latency via Interest aggregation and consumer privacy via sender anonymity, may either not subsist or be achieved by means of other forwarding mechanisms. If indeed the benets are overrated and the actual gain is considerably marginal, but the security issues are real and harmful, then the use of the PIT should be reconsidered.

  and since then collaboratively developed by a rich community made of academics, network equipment vendors, telco providers under the umbrella of an open non-prot consortium [160].Since the rst language specication, called P4_14, the language has considerably evolved and become mature in a new language version, called P4_16. P4_16 is not backward compatible with P4_14. Both language specications are available at[160]. However, NDN.p4 was implemented in P4_14, so the description of the language which follows refers to that early version.

A P4 program congures the supported protocols and the packet processing operations in a forwarding element. A forwarding element which can run P4 programs is called a P4 target or

Table 5 .

 5 5.2.1. A small snippet of code for each program block is illustrated in Table 5.2 where a simple P4 program is dissected. The illustrative program in 2 describes the behavior of a simplied IPv4 router which parses Ethernet and IPv4

Table 5 .

 5 2 combines the two primitive actions, modify_eld and subtract_from_eld, to perform the packet editing necessary to forward the IP packet to the nexthop and decrement the TTL count. Compound actions are meant to be linked to table entries. P4 tables are logical tables used to trigger the activation of actions for packets. The table in the F cell of Table5.2 species a longest prex match type on the IPv4 destination address to activate either the set_nexthop action or the on_miss one. The table in the G cell translates the information about a next-hop to an output port and re-writes the packet's MAC addresses based on the selected output port. Table denitions in P4 programs only specify the logical skeleton of the table. Tableentriesare then populated at run-time by a control plane logic. A run-time insertion command lls a table entry with specic values for the matching elds, an indication of the action to associate to the entry and possibly some optional parameters.

The control ow denes the program execution path. The programming model in Fig.

5

.2.1

  As a result, the NDN.p4 program can be used to program any P4_14-compliant target. For example, the P4 software switch at[162] has been the reference target to validate the NDN.p4 design. The target is programmed as a forwarding element able to perform the basic NDN Interest-Data exchange. More in detail, at the Interest reception, the programmed target parses the Interest name and forwards the Interest according to its FIB-like records. For every forwarded Interest, the target registers a pending request in a PIT-like table. At Data reception, the target parses the Data packet and extracts the name. If the PIT-like table contains any pending request for the same content name, then the Data is forwarded downstream to the registered output interface; if not, the Data is simply dropped. The correctness of the program logic has been evaluated through native NDN applications communicating over the software target programmed by the NDN.p4 code. The experiment simulates two NDN applications, ndnpeek and ndnpoke, exchanging Interest and Data packets through the P4 software-switch [162] as if it was a real NDN forwarding daemon. The ndnpeek application is a basic consumer of Data packets which can generate Interests with specic content names. The ndnpoke application is a basic producer of Data which can serve requests for contents under a specic prex name. The experiment has also been made available on the mini-NDN [163] fork of the Mininet platform for network emulation. The source code of the NDN.p4 router and the instructions to reproduce the experiments are free available at https://github.com/signorello.

  .............................................. …...............................................

			5.3. NDN.p4
	header_type hugeTL_t { fields{ tl_code : 8; tl_len_code : 8; }} tl_length : 64;	Length check	header_type mediumTL_t { fields{ }} tl_length : 16; tl_code : 8; tl_len_code : 8;
	header_type smallTL_t { fields{ tl_code : 8; tl_length : 8; }}	parser parse_ndn { return select(current(8,8)) { EN_2B : parse_medium_tlv0; EN_4B : parse_big_tlv0; EN_8B : parse_huge_tlv0; default : parse_small_tlv0; }	header_type bigTL_t { fields{ tl_code : 8; tl_len_code : 8; tl_length : 32; }}
		}
		….parser parse_afterName { return select(current(0,8)) {	Type check
		NDNTYPE_IS2 : parse_isha256;
		NDNTYPE_NON : parse_nonce;
		NDNTYPE_MTI : parse_metainfo;
		default : parse_error p4_pe_default;
		}
		}

The terms Content, Information, Data are often used as synonyms in related literature, so we do that here too.

An adaptive forwarding plane[START_REF] Yi | A case for stateful forwarding plane[END_REF] can explore multi-path routes in response to specic network conditions or as a simple probing mechanism to nd more ecient paths.

Since July 2016 the ICN research community has committed to precisely document and harmonize those dierences via the creation of an IETF-ICNRG work item[START_REF]Design choices and dierences for NDN and ccnx 1.0 implementations of information-centric networking[END_REF].

The term switch is used from now on to identify any network element performing forwarding decisions on trac.

All the information about dierent memory technologies' access time and maximum size reported in[START_REF] Varvello | On the design and implementation of a wire-speed pending interest table[END_REF] refers to the previous estimates in[START_REF] Perino | A reality check for content centric networking[END_REF].

It should be noted that since the version 0.3 of the NDN packet specication, the optional eld HopLimit has been added to the Interest packet to indicate the number of hops an Interest is allowed to be forwarded.

The terms coordinated, distributed and collaborative can all be found in literature to refer to countermeasures where routers collaborate to detect and mitigate attacks. Therefore, those terms are used as synonyms throughout this manuscript.

There is no such an acronym in[START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF], which indeed was found in the related implementation.

DP is not considered in[START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF], most likely because the implementation has never been made available since that work was published. For the sake of this work, DP has been implemented as forwarding strategy in ndnSim according to the description in the original work[START_REF] Compagno | Poseidon: Mitigating interest ooding DDoS attacks in named data networking[END_REF] and made available at[133].

In Greek mythology, Charon is the Hades' ferryman who carries souls across the rivers dividing the world of the living from the world of the dead.

For the sake of clarity, from now on until the end of this section, the abbreviation P4 is used whenever the text refers to the P4_14 language specication.

The reader should be aware that the name is produced as a hash and so the register suers from collisions. However, in this preliminary implementation, no mechanism has been designed to prevent this issue.

Summary

The IFAs, built upon the novel attack model proposed in this work, degrade the performance of the best state-of-the-art countermeasures. In particular, the attack model reduces the quality of service perceived by clients (i.e., lower ISR values mean less client requests satised) and increases the load on network's nodes (i.e., higher PUR values correspond to more computational and memory resources used in routers). Fig. 3.10b shows how the model can be leveraged to mount increasingly strong attacks which notably aect the most eective state-of-the-art countermeasure. The observed trend holds for all the tested attack frequencies and the three introduced attack variants. The main ndings are recapitulated in the following points:

• by using non-disjoint prex name sets all the tested defense mechanisms drop some legitimate trac too. In fact, no state-of-the-art countermeasure can distinguish between Fake and Legitimate Interests, rather, when either a prex name or an interface is detected as infected, all the related trac is mitigated.

• It is possible for attackers to pollute metrics collected by defense mechanisms in routers and increase the ecacy of their attacks. This was successfully achieved by the bIFA variant in our experiments.

• It is possible for attackers to circumvent detection operated by defense mechanisms in routers and stay undetected. This was successfully achieved by both bIFA and cIFA variants in our experiments.

• Under all the tested attacks, CNMR generates a higher load on routers compared to SBP.

This means that SBP better protects the network infrastructure (see the last two columns of Tab. 3.4) while CNMR better protects the clients (see the rst two columns of Tab.

3.4

). Yet, SBP performs aggressive mitigation on infected interfaces which inevitably affects many legitimate Interests; thus, overall, clients experience an ISR degradation. This behavior would be benecial to legitimate trac coming from non-infected interfaces, which would nd the necessary PIT space along the path to contents. Finally, Charon envisions the possibility for routers to ask for dierent summaries of the same content list. The reason for this feature is to allow routers to decide about the size of the lter to store and the computational overhead to sustain. The false probability error in BFs depends on three factors: the number of elements in the set n, the size of the lter m, the number of hash functions k. Thus, for example, a smaller lter could be required by a provider whether a higher false probability error would be considered acceptable. the stateful PIT behavior, some temporary metadata. In P4, an action cannot be directly called in the control ow program rather its activation goes through the application of a match-action table. Thus, some of the tables in the ingress pipeline are only meant to perform computation on the packet elds and store the results in metadata for further operations. Those tables are executed independently from any matching condition on the packet elds.

Control Flow Code

After the parsing stage, the count_table is applied to count the total number of name components in the current packet. As explained in the section describing the FIB implementation, this number is later used by the LPM algorithm to select the right FIB entry. The hashname_table is applied to compute the hash of the full packet name, i.e., h(a,b,c,d), as well as the hashes of all the shorter prexes, i.e., c1=h(a), c12 = h(a,b) and c123 = h(a,b,c). The full name hash is needed to address the PIT, while the hashes of the shorter prexes are required to perform the Longest Prex Matching (LPM) on the FIB table. In sequence, the pit_table reads a register indexed by name_hash and copies it in the isInPIT metadata eld. If the register value indexed by the full name hash equals zero, the target has no other pending Interests for this name and so a FIB lookup must be done to determine the next-hop. If the register is not empty, the Interest is dropped and eventually the register is updated. After applying the pit_table, the control ow has a conditional branch based on the packet type, that is, either Interest or Data.

In case of an Interest packet, Flow_metadata.isInPIT contains the list of the interfaces where the target has already received an Interest for this content. A PIT entry is represented as a table_set_default count_table _drop table_add count_table storeNumOfComponents 1 0 0 0 0 => 1 table_add count_table storeNumOfComponents 1 1 0 0 0 => 2 table_add count_table storeNumOfComponents 1 1 1 0 0 => 3 table_add count_table storeNumOfComponents 1 1 1 1 0 => 4 table_add count_table storeNumOfComponents 1 1 1 1 1 => 5 action storeNumOfComponents(total) { modify_field(name_metadata.components,total); }

Matching fields

Action parameters

Rule set

Figure 5.6 Denition of the count_table and related table entries

A glimpse of the syntax to modify the match-action tables in NDN.p4 is provided in Fig. 5.6

where the count_table of the ingress pipeline and the rules used to ll it are reported. The count_table counts the number of name components in a name. More precisely, the count_table counts the name component TLVs in a packet through a validity match. A validity match returns false if a header is not present, true otherwise. Therefore, the table contains as many matching elds as the maximum number of name components that a packet may have. For example, an Interest name with two name components will have the validity bit set for both the component[0] and component [START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF] headers and clear for all the other header components. In this case, the table needs a rule that translates the two valid headers in the packet to a counter value, that is, the third rule of the rule-set presented in Fig. 5.6. Further, every table needs a default rule to specify the action to be performed in case of table-miss. The default rule for the count_table is the rst rule of the rule-set in Fig. 5.6, which calls an action to drop the packets without any valid name component header.

A rule has the following syntax: command_type table_name [associated_action] [match_elds_list] [=>] [parameters_list].

The command_type indicates the kind of operation, like add, delete or modify a table entry. The associated_action indicates the name of the action bound to this table entry. The match_elds_list are the specic value of the table matching elds for this entry. Finally, an action may or may not accept parameters. When present, the action's parameters follow the symbol '=>' as parameters_list.

Lessons learned and future development

When the NDN.p4 design was rst tackled, the P4_14 language seemed to have a limited set of constructs to fully describe the NDN data-plane. This could have led to the premature conclusion that the language was not complete enough to express certain network behaviors and so language extensions were strictly required. Although enhancing the language syntax could have been easy and convenient in a rst stage, on a long term it could have hampered the program portability. Further, it would have been a worthless eort since the language specication was As second contribution, we dene proactive countermeasures against the IFA. This novel class of countermeasures includes defense mechanisms which do not perform any trac monitoring to detect an attack. At rst, we conjecture proactive defense eliminates the monitoring burden required and overcomes the vulnerabilities experienced by its reactive counterpart. Then, by designing Charon, a proactive IFA countermeasure where NDN routers rely only on the Interest name analysis to identify and drop fake Interests, we empirically prove proactive countermeasures counteract eciently the latest stealthy IFAs. Further, the introduction of Charon opens a totally new perspective on the design of new and/or renement of old IFA countermeasures.

As third contribution, we present NDN.p4, the rst information-centric data-plane written in the novel high-level language for packet processors P4. Writing highly-portable and re-usable implementations of the NDN protocols is a necessary step to advance the experimentation on the NDN architecture. The work done with NDN.p4 aims to show the foremost importance of exploring programmable network platforms in the design and test of NDN data-plane behaviors.

NDN.p4 aims to leverage P4-targets in the long term as platforms to experiment with alternative forwarding mechanisms. Research on alternatives forwarding mechanisms for the NDN is required to design an NDN data-plane preserving its original properties yet avoiding the intrinsic IFA vulnerability. Furthermore, the work in NDN.p4 has highlighted limitations of the rst P4 language version and contributed actively to the discussion about the set of features to be integrated in further language versions. With regard to the future work, the work presented in this manuscript has delineated at least three dierent directions to pursue further research on. First, the thorough analysis of the state-of-the-art IFA countermeasures has revealed a few promising options to design more robust defense mechanisms against this NDN-specic security threat. Proactiveness, as empirically proven by this work, is a characteristic which can help improve existing defense mechanisms. As purely proactive countermeasures could not be widely applicable to all the attack scenarios, those could instead be embedded in hybrid reactive/proactive designs. This work shows how the IFA mitigation strategy in Charon never aects any legitimate trac. So, Charon-like mitigation techniques could replace the rate-limiting techniques generally applied by the existing reactive countermeasures.

Second, among the so far proposed countermeasures against IFAs, the collaborative ones seem to be the most ecient according to the results reported in literature works [START_REF] Afanasyev | Interest ooding attack and countermeasures in named data networking[END_REF][START_REF] Compagno | Poseidon: Mitigating interest ooding DDoS attacks in named data networking[END_REF][START_REF] Salah | Coordination supports security: A new defence mechanism against interest ooding in NDN[END_REF]. Nevertheless, the coordination of routers to apply collaborative defense mechanisms is achieved by means of slowly converging message exchanges that may even require data-plane or packet format changes. At the time being, there exist no standard interfaces between control and data-planes in NDN. Yet a standard interface to the NDN data-plane could be used to design centralized at the control-plane applications to mitigate IFAs. The denition of such an interface would eliminate the need for ad-hoc protocol modications required by the existing collaborative countermeasures. Further, the need for an NDN monitoring plane has been advocated by several other works [START_REF] Pesavento | A network measurement framework for named data networks[END_REF][START_REF] Mai | Towards a security monitoring plane for named data networking and its application against content poisoning attack[END_REF], so there could be the opportunity to partially leverage existing solutions.

Third, the P4 language has considerably evolved since the work in NDN.p4 was proposed. The NDN.p4 design was in some parts constrained by the limitations of the P4 early language specication. Similarly, a study of the performance of the NDN.p4 solution was not done because of the lack of hardware/software support for the P4 language at the time of its conception. Today, the original P4 language specication [START_REF]The P4_14 Language Specication[END_REF] has been improved and features a more exible programming model in a new language version [START_REF]The P4_16 Language Specication[END_REF]. Several P4 hardware/software targets have also appeared, so oering the possibility to conduct a performance evaluation of NDN.p4. The NDN.p4 design can denitely benet from the new P4 language's feature-set and the related hardware/software ecosystem. Indeed, NDN.p4 has already been leveraged for further work in [START_REF] Ramos | Named data networking with programmable switches[END_REF] with the aim to improve its design with regard to certain components (e.g., the parser, the forwarding table) and measure achievable performance on real P4 hardware targets. It is to be ascertained yet whether or not improved versions of NDN.p4 will be able to achieve the same performance of platform-tailored NDN data-plane designs. Nevertheless, in our opinion, this open question should not limit further research on this subject since future NDN.p4 versions will oer immediate portability on multiple targets and a simplied open-source design, benets which no other state-of-the-art design so far features.

Appendix A

Dierences between CCN and NDN

This appendix reports some of the main dierences between the CCN and NDN protocols at the time of writing this manuscript. The main criterion for the selection of the presented dierences is their relevance to the topics covered in this manuscript.

Packet format:

The CCNx and NDN protocols follow a dierent encoding and packet format. CCNx uses a 16bit Type and a 16-bit Length TLV structure. The length eld contains the length of the Value eld in octets. Instead, NDN uses a variable length Type and Length TLV structure, where the value contained in the rst byte of the Type and Length eld determines their bit length. The CCNx's packet format is made of a xed header followed by optional TLV headers and then by the body of the message. Instead, the NDN's packet format does not contain any xed header rather it contains a variable number of TLVs.

Matching:

Since version 1.0, CCNx only supports exact match on Interest names. Meaning that if a content with name /a/b/c.zip is required, only a Data packet with the same identical name can consume that Interest. Dierently in NDN, contents like /a/b/c.zip/v1/s100 or /a/b/c.zip/manifest.txt are valid Data for the /a/b/c.zip Interest. Exact matches achieve faster forwarding and are deterministic, that is, they always bring back the same content. Further, they avoid inspection of caches by means of generic queries.

Selectors:

NDN and CCNx contain additional, sometimes optional, elds in the Interest packet header which can be used to narrow the search to specic contents. NDN oers a wider range of such elds, called selectors. Their purpose ranges from limiting or excluding components beyond the Interest prex to specifying a specic publisher via a reference to its public key or asking routers not to provide stale Contents. Conversely, CCNx has removed this feature in its 1.0 version to achieve faster and more deterministic forwarding with exact match on the Interest name.

Nevertheless, CCNx has preserved two of those options, now called restrictions. CCNx Interests can carry a keyIdRestriction eld to identify a specic publisher and/or a contentObjectHash to guarantee the network delivers the right packet.

Fragmentation:

Contents may be bigger than the Maximum Transmission Unit (MTU) on certain links, so a Appendix A. Dierences between CCN and NDN mechanism may be needed to fragment and reassemble packets across the network. Fragmentation and reassembly of packets can be performed either in the network or at end-hosts. CCNx performs end-to-end fragmentation, while NDN performs hop-by-hop fragmentation through a link-layer protocol mechanism [START_REF] Shi | NDNLP: A Link Protocol for NDN, the NDN project team[END_REF].

Negative Acknowledgments: Special packets reporting feedback about packet transmission are widely used mechanisms to generate error notications in network protocols. An analysis, with a strong focus on security, of pros and cons of Negative Acknowledgments (NACKs) in NDN/CCN networks is provided in [START_REF] Compagno | To nack or not to nack? negative acknowledgments in information-centric networking[END_REF]. Therein, the authors dene two kind of NACK packets for ICNs: content NACK (cNACK) and forwarding NACK (fNACK). A cNACK is a negative acknowledgment generated by a producer to indicate that a requested content does not exist. A fNACK is generated by a router to notify downstream routers that it cannot forward an Interest packet because of congestion or absence of route for that name. The work in [START_REF] Compagno | To nack or not to nack? negative acknowledgments in information-centric networking[END_REF] presents in detail the security implications of NACKs concluding that network-layer NACKs are better avoided for security reasons. In fact, the CCNx protocol provides NACKs only as special type of Content Type and the NDN architecture delegates the NACK mechanism to a link-layer protocol (the NDNLP [START_REF] Shi | NDNLP: A Link Protocol for NDN, the NDN project team[END_REF]).