RFC 7945

Information-Centric Networking: Evaluation and Security Considerations

📅 published September 2016, from ietf

Internet Research Task Force (IRTF) 💖 Request for Comments: 7945 ✨

Okay bestie, the title block is the first thing you see, so here's the tea 🎀

  • Series: Internet Research Task Force (IRTF) 🦋
  • RFC number: 7945 🌸
  • Authors: K. Pentikousis (Ed.) from Travelping, B. Ohlman from Ericsson, E. Davies from Trinity College Dublin, S. Spirou from Intracom Telecom, and G. Boggia from Politecnico di Bari 💅
  • Category: Informational 💜. This is NOT a standards track thing, so no implementers are being told what to do 🙈
  • ISSN: 2070-1721
  • Date: September 2016 🍓
  • Title: Information-Centric Networking: Evaluation and Security Considerations ✨
  • Obsoletes / Updates: The original text doesn't list any, so there's nothing here to obsolete or update 🫶

Abstract 🌈

Okay so this doc is all about evaluating Information-Centric Networking (ICN) and it's giving a good look at how ICN affects network security 🔥. It also goes through the evaluation tools researchers in the ICN area can actually use right now, and it drops some suggestions about methodology and metrics 💅.

Status of This Memo ✨

Okay this part is serious bestie 🎀. This document is NOT an Internet Standards Track spec. It's published just for information 🦋.

It's a product of the Internet Research Task Force (IRTF) 🌸, which publishes the results of Internet-related research and development. Those results might not be suitable for deployment 💀. This RFC represents the consensus of the <insert_name> Research Group of the IRTF 💜. Documents approved by the IRSG are not a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the details 🧚.

Info about the current status, any errata, and how to give feedback lives at:

http://www.rfc-editor.org/info/rfc7945

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved 🌈.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the publication date. Please read these carefully, bestie, because they describe your rights and restrictions for this document 🫶.

Table of Contents 🦋

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
2.  Evaluation Considerations  . . . . . . . . . . . . . . . . . .  4
  2.1.  Topology Selection . . . . . . . . . . . . . . . . . . . .  5
  2.2.  Traffic Load . . . . . . . . . . . . . . . . . . . . . . .  6
  2.3.  Choosing Relevant Metrics  . . . . . . . . . . . . . . . . 10
    2.3.1.  Traffic Metrics  . . . . . . . . . . . . . . . . . . . 13
    2.3.2.  System Metrics . . . . . . . . . . . . . . . . . . . . 14
  2.4.  Resource Equivalence and Trade-Offs  . . . . . . . . . . . 16
3.  ICN Security Aspects . . . . . . . . . . . . . . . . . . . . . 16
  3.1. Authentication  . . . . . . . . . . . . . . . . . . . . . . 17
  3.2. Authorization, Access Control, and Logging  . . . . . . . . 18
  3.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 19
  3.4. Changes to the Network Security Threat Model  . . . . . . . 20
4.  Evaluation Tools . . . . . . . . . . . . . . . . . . . . . . . 21
  4.1.  Open-Source Implementations  . . . . . . . . . . . . . . . 21
  4.2.  Simulators and Emulators . . . . . . . . . . . . . . . . . 22
    4.2.1.  ndnSIM . . . . . . . . . . . . . . . . . . . . . . . . 22
    4.2.2.  ccnSIM . . . . . . . . . . . . . . . . . . . . . . . . 23
    4.2.3.  Icarus Simulator . . . . . . . . . . . . . . . . . . . 23
  4.3.  Experimental Facilities  . . . . . . . . . . . . . . . . . 24
    4.3.1.  Open Network Lab (ONL) . . . . . . . . . . . . . . . . 24
    4.3.2.  POINT Testbed  . . . . . . . . . . . . . . . . . . . . 25
    4.3.3.  CUTEi: Container-Based ICN Testbed . . . . . . . . . . 25
5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
6.  Informative References . . . . . . . . . . . . . . . . . . . . 26
Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38

1. Introduction 🌸

Information-Centric Networking (ICN) is a networking concept that came from wanting the way a network works to match the way it's actually used 💅. For TCP/IP networks, that means changing how data is accessed and transported, going from a host-to-host model to a user-to-information model ✨. The premise is that all the effort spent changing models will be offset, or even beaten, by the potential of a "better" network 🔥. But that claim can only be validated if it's quantified 🧚.

Different ICN approaches get evaluated in peer-reviewed literature using a mix of theoretical analysis, simulation and emulation, and empirical (testbed) measurements 🦋. The methodology can depend on the experiment goal, like whether you want to check scalability, quantify resource utilization, or analyze economic incentives 💜. We also notice that how easy and convenient it is to set up and run experiments can sometimes shape published evaluations 🙈. As discussed in [RFC7476], ICN is still in its development phase with tons of approaches tackling the hardest problems 💖. That makes it a super active and growing research area, but on the flip side, it's harder to compare different proposals on an equal footing 😭.

Performance evaluation with actual network deployments has the advantage of realistic workloads, and it reflects the environment where the service or protocol will be deployed 🌈. With ICN, though, it isn't clear yet what counts as a "realistic workload" 💀. Trace-based analysis of ICN is in its infancy, so more work is needed to define characteristic workloads for ICN evaluation studies 🫶. The experimental process and the evaluation methodology itself are actively being researched for different ICN architectures ✨. Lots of factors affect experimental results, including the topology selected; the background traffic an application is subjected to; network conditions like available link capacities, link delays, and loss-rate characteristics across the selected topology; failure and disruption patterns; node mobility; and the diversity of devices used 🎀.

The goal of this document is to sum up evaluation guidelines and tools, along with suggested data sets and high-level approaches 🍓. We expect it to be of interest to the whole ICN community, since it can help researchers and practitioners compare and contrast different ICN designs, as well as the state of the art in host-centric solutions, and figure out their respective strengths and weaknesses 👑. Apart from the technical evaluation of an ICN architecture's functionality, the future success of ICN will be largely driven by its deployability and economic viability 💅. So ICN evaluations should assess incremental deployability in the existing network environment, together with a view of how the technical functions will incentivize deployers to invest in the capabilities that let the architecture spread across the network 🌸.

This document was produced by the IRTF Information-Centric Networking Research Group (ICNRG) 🧚. The main objective of the ICNRG is to couple ongoing ICN research in the above areas with solutions relevant for evolving the Internet at large 🌈. The ICNRG produces documents that give guidelines for experimental activities in the ICN area, so different alternative solutions can be compared consistently, and information can be shared for experimental deployments ✨. This document incorporates input from ICNRG participants and their text contributions, and it has been reviewed by several active ICNRG participants (see the Acknowledgments). It represents the consensus of the research group 💖. That said, this document is NOT an IETF standard, so see also [RFC5743] 🙈.

The rest of this document is organized like this: Section 2 covers various techniques and considerations for evaluating different ICN architectures 🦋. Section 3 discusses the impact of ICN on network security 🔥. Section 4 surveys the tools currently available to ICN researchers 💜.

2. Evaluation Considerations 💅

It's clear that the way we evaluate IP networks won't directly apply to evaluating ICN 😭. With IP, the focus is on the performance and characteristics of end-to-end connections between a source and a destination 🌸. With ICN, the "source" responding to a request can be any ICN node in the network, and it may change from request to request 🙈. That makes concepts like delay and throughput hard to use the traditional way 💀. Evaluating resource usage in ICN is also more complicated, because memory used for caching affects delays and the use of transmission resources 🔥. See the discussion on resource equivalents in Section 2.4 🧚.

There are two major types of evaluation of ICN that we see a need for 🦋. One type compares ICN to traditional networking, and the other compares different ICN implementations and approaches against each other 💖.

In this section, we go through some of the functional components needed when evaluating different ICN implementations and approaches ✨.

Part 1 of 9 is done bestie, more parts are coming so stay tuned! 🎀💜

2.1. Topology Selection 🗺️

okay so there's a WHOLE pile of earlier work on topology selection for simulating and evaluating host-centric networks 📚. The classic dumbbell topology is considered inappropriate for ICN 🙅‍♀️, but most ICN studies so far have still built on that older host-centric work [RFC7476]. ngl, there is no single topology that can easily evaluate every aspect of ICN 💀. So you gotta pick from a range of topologies based on what your evaluation is focusing on 🎯.

For scalability and resilience studies, there's a wide range of synthetic topologies, like the Barabasi-Albert model [Barabasi99] and the Watts-Strogatz small-world topology [Watts98] 🌐. These let you run experiments while controlling key parameters (e.g., node degree) 🎛️. Synthetic topologies are appropriate in the general case, because there are no practical assurances that a future information-centric network will have the same topology as any of today's networks 🔮. not me being chaotic about the future internet 😭.

When studies look at cost (e.g., transit cost) or migration to ICN, realistic topologies should be used 💸. These can be inferred from Internet traces, such as the CAIDA Macroscopic Internet Topology Data Kit (http://www.caida.org/data/active/internet-topology-data-kit) and Rocketfuel (http://www.cs.washington.edu/research/networking/rocketfuel) 🛰️. The catch is that these topologies are HUGE (approximately 45K Autonomous Systems, close to 200K links) 🫠, which may limit the scalability of the evaluation tool you're using. Katsaros et al. [Katsaros15] tackle this by using scaled down topologies created following the methodology described in [Dimitropoulos09] 🧠✨ iconic problem-solving, honestly.

Studies that focus on node or content mobility can benefit from topologies and their dynamic aspects as used in the Delay-Tolerant Networking (DTN) community 🦋. As mentioned in [RFC7476], DTN traces are available to be used in such ICN evaluations 🎀.

As with host-centric topologies, just defining a node graph won't be enough for most ICN studies 🙈. The experimenter should also clearly define and list the respective matrices that correspond to the network, storage, and computation capacities available at each node, as well as the delay characteristics of each link [Montage] 📋. Real values for these parameters can be taken from existing platforms such as iPlane (http://iplane.cs.washington.edu) 💜. Synthetic values could be produced with specific tools [Kaune09] 🧪.

2.2. Traffic Load 🚦

in this subsection, we give you a set of common guidelines, which we'll call a content catalog for different scenarios 📖💖. This catalog is based on previously published work, and it can be used to evaluate different ICN proposals, for instance on routing, congestion control, and performance 🔥. It can also be extended as other kinds of ICN contributions emerge 🌈. Real talk, we're still lacking ICN-specific traffic workloads, so for now we can only extrapolate from today's workloads 😤. A big challenge is figuring out which applications are contributing to the observed traffic (e.g., Web or peer-to-peer), plus the exact amount of traffic each one adds to the overall mix 🕵️‍♀️. To get a handle on this, you can look at today's traffic mix of Web, peer-to-peer file sharing, and User-Generated Content (UGC) platforms (e.g., YouTube), as well as Video on Demand (VoD) services 📺. Publicly available traces for these include ones from sites like the MultiProbe Framework (<http://multiprobe.ewi.tudelft.nl/multiprobe.html>), (<http://an.kaist.ac.kr/traces/IMC2007.html>, see also [Cha07]), and the UMass Trace Repository (<http://traces.cs.umass.edu/index.php/Network/Network>) 🗂️💅.

Taking a more systematic approach, and wanting to model the traffic load, we can use measurement studies that look at the composition of Internet traffic, such as [Labovitz10] and [Maier09] 📊. In [Labovitz10], a large-scale measurement study was performed to study the traffic crossing inter-domain links 🌍. The results show Web traffic dominating, at 52% over all measured traffic 👑. However, Deep Packet Inspection (DPI) techniques reveal that 25-40% of all HTTP traffic actually carries video 🎬. DPI also shows how hard it is to correctly identify the application type for P2P traffic 😭: mapping observed port numbers to well-known applications shows P2P traffic at only 0.85% of overall traffic, while DPI raises that to 18.32% [Labovitz10]. Relevant studies on a large ISP show P2P traffic ranging from 17% to 19% of overall traffic [Maier09] 🫣. Table 1 gives you an overview of these figures 💕. The "other" traffic type means traffic that can't be classified into any of the first three application categories, and it's made up of unclassified traffic and traffic heavily fragmented into several applications (e.g., 0.17% DNS traffic) 🧩.

                   Traffic Type | Ratio
                   =====================
                   Web          | 31-39%
                   ---------------------
                   P2P          | 17-19%
                   ---------------------
                   Video        | 13-21%
                   ---------------------
                   Other        | 29-31%
                   =====================

Table 1: Traffic Type Ratios of Total Traffic [Labovitz10] [Maier09] 📉

The content catalog for each type of traffic can be described by a specific set of parameters 🧁:

  • a) the cardinality of the estimated content catalog
  • b) the size of the exchanged contents (either chunks or entire named information objects)
  • c) the popularity of objects (expressed in their request frequency)

In most application types, the popularity distribution follows some power law, which means a small number of information items trigger a large proportion of the entire set of requests 🔥. The exact shape of the power law popularity distribution directly impacts the performance of the underlying protocols 💅. For instance, highly skewed popularity distributions (e.g., a Zipf-like distribution with a high slope value) favor deploying caching schemes, since caching a very small set of information items can dramatically increase the cache hit ratio 🚀. bestie, that's the whole glow-up 💖.

Several studies over the past few years have said that Zipf's law is the discrete distribution that best represents the request frequency in a number of application scenarios, from the Web to VoD services 🎞️. The key thing about this distribution is that the frequency of a content request is inversely proportional to the rank of the content itself, i.e., the smaller the rank, the higher the request frequency 👑✨. If M denotes the content catalog cardinality and 1 <= i <= M denotes the rank of the i-th most popular content, we can express the probability of requesting the content with rank "i" as:

P(X=i) = (1 / i^(alpha)) / C, with C = SUM(1 / j^(alpha)), alpha > 0
where the sum is obtained considering all values of j, 1 <= j <= M.

A recent analysis of HTTP traffic showed that content popularity is better reflected by a trimodal distribution model 🌸. In that model, the head and tail of a Zipf distribution (with slope value 0.84) are replaced by two discrete Weibull distributions, with shape parameter values 0.5 and 0.24 respectively [IMB2014] 🧚.

A variation of the Zipf distribution, called the Mandelbrot-Zipf distribution, was suggested [Saleh06] to better model environments where nodes can locally store previously requested content 🗄️. For example, it was observed that peer-to-peer file-sharing applications typically showed a 'fetch-at-most-once' style of behavior 🙃. That's because peers tend to persistently store the files they download, and this behavior may also be common in ICN 🫶.

Popularity can also be characterized in terms of:

  • a) The temporal dynamics of popularity, i.e., how requests are distributed in time. The popularity distribution expresses the number of requests submitted for each information item in a certain workload. However, it doesn't describe how those requests are spread out in time ⏰. This matters a LOT for caching schemes, since the ordering of requests obviously affects what's in a cache 😤. For example, with a Least Frequently Used (LFU) cache replacement policy, if all requests for a certain item are submitted close together in time, that item is unlikely to be evicted from the cache, even by a (globally) more popular item whose requests are more evenly spread out in time 🥹. The temporal ordering of requests matters even more when the workload has various applications all competing for the same cache space 🥊.
  • b) The spatial locality of popularity, i.e., how requests are distributed throughout a network. Spatial locality matters because it's about avoiding redundant traffic in the network 🌐. If requests are highly localized in some area of the entire network, then similar requests can be served more efficiently with mechanisms such as caching and/or multicast 📡. In other words, concentrating similar requests in a limited area of the network lets you increase the perceived cache hit ratios at caches in that area, and/or the traffic savings from using multicast 💰. Table 2 gives you an overview of the distributions that can be used to model each of the identified traffic types, i.e., Web, Video (based on YouTube measurements), and P2P (based on BitTorrent measurements) 🎀. These distributions are the outcome of a series of modeling efforts based on measurements of real traffic workloads ([Breslau99] [Mahanti00] [Busari02] [Arlitt97] [Barford98] [Barford99] [Hefeeda08] [Guo07] [Bellissimo04] [Cheng08] [Cheng13]) 🫧. A tool for creating synthetic workloads that follow these models, and that also allows generating different traffic mixes, is described in [Katsaros12] 🛠️✨.

2.3. Choosing Relevant Metrics 📏✨

Okay so, measuring how well a network performs takes a set of standard metrics, bestie 📊. These metrics should be broad enough that they can be applied equally to host-centric and information-centric (or other) networks 🌸. That way you can compare an ICN approach with an earlier version of the same approach, with another ICN approach, or with the incumbent host-centric approach 💅. It becomes way less difficult to gauge optimization and research direction 🧚. On the other hand, the metrics should be targeted to network performance only and should avoid unnecessary expansion into the physical and application layers 🙈. Similarly, right now it matters more to capture only the main figures of merit and to leave the more esoteric, less frequent cases for later 🫶.

To find a set of relevant metrics, it would be beneficial to look at the metrics used in existing ICN approaches 👀. The list of approaches is giving main character energy: Content-Centric Networking (CCN) [Jacobson09] [VoCCN] [Zhang10b], NetInf [4WARD6.1] [4WARD6.3] [SAIL-B2] [SAIL-B3], PURSUIT [PRST4.5], COMET [CMT-D5.2] [CMT-D6.2], Connect [Muscariello11] [Perino11], and CONVERGENCE [Detti12] [Blefari-Melazzi12] [Salsano12] 🦋. The metrics in these approaches fall into two categories: metrics for the approach as a whole, and metrics for individual components (name resolution, routing, and so on) 🧩. Metrics for the entire approach are further split into traffic and system metrics 🎀.

Here's the messy part 😭. The approaches don't name or define metrics consistently, and that's a major problem when you're trying to find metrics that allow comparison between approaches 💀. For the purposes of this writeup, we smoothed over the differences by grouping similarly defined metrics under the same name 🫧. We also only report the metrics that are most common across approaches, because space is limited 📝. If you want more details, go read the references for each approach 📚.

Traffic metrics in existing ICN approaches are summarized in Table 4 🍓. These metrics evaluate an approach mainly from the perspective of the end user, meaning the consumer, the provider, or the owner of the content or service 💜. Depending on the level where they're measured, we split them into user, application, and network-level traffic metrics 🌈. Network-level metrics are mostly about packet characteristics, while user-level metrics can cover elements of human perception 👁️. The approaches don't make this split explicitly, but you can see from the table that CCN and NetInf used metrics from all levels, PURSUIT and COMET focused on lower-level metrics, and Connect and CONVERGENCE went for higher-level metrics 🔥. Throughput and download time seem to be the most popular metrics overall 🏆.

               User   |    Application    |        Network
           ======================================================
             Download | Goodput | Startup | Throughput |  Packet
               time   |         | latency |            |  delay
==================================================================
CCN         |    x     |    x    |         |      x     |    x
------------------------------------------------------------------
NetInf      |    x     |         |    x    |      x     |    x
------------------------------------------------------------------
PURSUIT     |          |         |    x    |      x     |    x
------------------------------------------------------------------
COMET       |          |         |    x    |      x     |
------------------------------------------------------------------
Connect     |    x     |         |         |            |
------------------------------------------------------------------
CONVERGENCE |    x     |    x    |         |            |
==================================================================

        Table 4: Traffic Metrics Used in ICN Evaluations

While traffic metrics matter more to the end user, the owner or operator of the networking infrastructure is usually more interested in system metrics 🛠️, because those can reveal how efficient an approach is 📈. The most common system metrics are: protocol overhead, total traffic, transit traffic, cost savings, router cost, and router energy consumption 💰.

Besides the traffic and system metrics that evaluate an approach as a whole, every surveyed approach also evaluates the performance of individual components 🧃. Name resolution, request/data routing, and data caching are the most typical components, as shown in Table 5 🗂️. Forwarding Information Base (FIB) size and path length (the routing component metrics) are almost ubiquitous across approaches, probably because of the networking backgrounds of the researchers involved 🤓. That might also explain why traffic and system metrics sometimes got less focus in favor of component metrics 🙃. You could definitely argue that traffic and system metrics are affected by component metrics, but no approach has made that relationship clear 🤷‍♀️. With that in mind, and since traffic and system metrics are readily useful to end users and network operators, we'll restrict ourselves to those in the following subsections 💖.

                  Resolution      |    Routing    |    Cache
           ======================================================
             Resolution | Request | FIB  |  Path  | Size |  Hit
                today    |  rate   | size | length |      | ratio
==================================================================
CCN         |     x      |         |  x   |   x    |   x  |   x
------------------------------------------------------------------
NetInf      |     x      |    x    |      |   x    |      |   x
------------------------------------------------------------------
PURSUIT     |            |         |  x   |   x    |      |
------------------------------------------------------------------
COMET       |     x      |    x    |  x   |   x    |      |   x
------------------------------------------------------------------
CONVERGENCE |            |    x    |  x   |        |   x  |
==================================================================

    Table 5: Component Metrics in Existing ICN Approaches

Before we go further, I want to flag one thing 🚩. We'd like these metrics to work for host-centric networks too 🖥️. Standard metrics already exist for IP networks, and it would definitely be beneficial to take them into account 🙌. It's encouraging that many of the metrics used by existing ICN approaches can also be used on IP networks, and that every one of the approaches has tried, at least sometimes, to draw the parallels 🫶✨.

2.3.1. Traffic Metrics ✨

Okay bestie, so the IETF has been obsessed with figuring out how to measure IP network performance for over a decade 🤓. Most of that work happened in the IP Performance Metrics (IPPM) working group, following a framework from [RFC2330]. IPPM covers delay, delay variation, loss, reordering, and duplication 📊. IPPM is built for packet-switched IP networks, but it could maybe be changed and extended to cover ICN networks too 🦋. That's a maybe, though. More study is needed before we can call it a certainty 🥺. Still, so many experts have put in serious work on refining these metrics and methods that it would be a huge win to reuse them for measuring ICN performance 👑. Plus, those metrics and methods already work for host-centric networks, so comparing against information-centric networks would only need the ICN extension of the IPPM framework 💅. The best part? Measuring transport performance at the network output with Quality of Service (QoS) metrics like IPPM can mostly be done without depending on applications at all 🫶.

Another option is to measure transport performance with QoS metrics, but not at the network output like IPPM does. Instead, you measure at the input to the application 🎬. For a live video-streaming app, the metrics that matter are startup latency, playout lag, and playout continuity ⏯️. This approach is iconic because it abstracts away all the details of the underlying transport network, so it can be applied to compare networks with totally different concepts (host-centric, information-centric, or other) 🌈. The catch is that it depends heavily on the application, so different types of applications will probably need different metrics 😭. You might be able to pin down standard metrics for each application type, but it's not as clear-cut as it is with IPPM, so more investigation is needed 🔍.

At an even higher level of abstraction, we could measure the network's transport performance at the application output 💜. This means measuring the quality of the transported and reconstructed information as the user perceives it while consuming it 🍿. In that case we'd use Quality of Experience (QoE) metrics, which are dependent on the application by definition 🎀. For example, the standardized methods for getting a Mean Opinion Score (MOS) for VoIP (e.g., ITU-T Recommendation P.800) are totally different from the ones for IPTV (e.g., Perceptual Evaluation of Video Quality (PEVQ)) 📺. These methods are notoriously hard to implement, ngl, because they involve real users in a controlled environment 💀. Some of those constraints can be relaxed or dropped by using methods that model human perception under certain environments, but those methods are typically intrusive 🙈. The biggest drawback of measuring network performance at the application output is that only one part of each measurement is about the network. The rest is about application performance, like video coding, or even device capabilities 📱. Those things are irrelevant to our purposes here and are generally hard to separate, so we see using QoE metrics to measure ICN performance as a poor choice at this stage 🙅‍♀️.

2.3.2. System Metrics 🧚

Overall system metrics that need to be considered include reliability, scalability, energy efficiency, and delay/disconnection tolerance 💖. In deployments where ICN is targeting specific scenarios, relevant system metrics could be derived from current experience 🌸. For example, in Internet of Things (IoT) scenarios, which are discussed in [RFC7476], it makes sense to consider the current generation of sensor nodes, sources of information, and even measurement gateways (e.g., for smart metering at homes) or smartphones 📲. In this case, ICN operation ought to be evaluated not only for overall scalability and network efficiency, but also for its impact on the nodes themselves 🔋. Karnouskos et al. [SensReqs] provide a comprehensive set of sensor and IoT-related requirements, which include aspects such as resource utilization, service life-cycle management, and device management 📋.

Specific metrics are also critical in constrained environments, such as processing requirements, signaling overhead, and memory allocation for caching procedures, plus power consumption and battery lifetime 🔥. Gateways typically act as a point of service for a large number of nodes and have to satisfy information requests from remote entities, so we need to consider scalability-related metrics for them, such as the frequency and processing of successfully satisfied information requests 🚪✨.

Finally, because ICNs have in-network caching, efficiency and performance metrics for in-network caching have to be defined 🧊. Such metrics will guide researchers and operators on how in-network caching algorithms are performing 👩‍🔬. A first step in this direction was made in [Psaras11] 🎉. The paper proposes a formula that approximates the proportion of time a piece of content stays in a network cache 🕰️. The model takes as input the rate of requests for a given piece of content (the Content of Interest (CoI)), and the rate of requests for all other contents that go through the given network element (router) and move the CoI down in the (LRU) cache 🔄. The formula also takes into account the size of that router's cache 🗂️.

The output of the model essentially reflects the probability that the CoI will be found in a given cache 🎯. An initial study [Psaras11] was applied to the CCN / Named Data Networking (NDN) framework, where contents get cached at every node they traverse 🌐. The formula for calculating that probability or proportion is:

pi = [mu / (mu + lambda)]^N

where lambda is the request rate for the CoI, mu is the request rate for contents that move the CoI down the cache, and N is the size of the cache (in slots) 🧮.

The formula can be used to assess the caching performance of the system, and it can also potentially be used to identify the gain the system gets from caching 🏆. That gain can then be compared against gains from other factors, e.g., adding extra bandwidth to the network 💪.

2.4. Resource Equivalence and Trade-Offs ⚖️

As we've seen above, every ICN network is built from a set of resources 🧱. These include link capacities, different types of memory structures and repositories used for storing named data objects and chunks temporarily (i.e., caching) or persistently, and name resolution and other lookup services 🗄️. A range of engineering trade-offs comes from the complexity and processing requirements of forwarding decisions, management needs (e.g., manual configuration, explicit garbage collection), and routing needs (e.g., amount of state, manual configuration of routing tables, support for mobility) 😵‍💫.

To compare different ICN approaches, it would be really helpful to define equivalence in terms of different resources that are currently considered incomparable 🍰. For example, would provisioning an additional 5 Mbit/s link capacity lead to better performance than adding 100 GB of in-network storage? 🤔 In this context, one would consider resource equivalence (and the associated trade-offs), for example, for cache hit ratios per GB of cache, forwarding decision times, CPU cycles per forwarding decision, and so on 🧠.

3. ICN Security Aspects 🔐

The introduction of an information-centric networking architecture and its corresponding communication paradigm changes many aspects of network security 🚨. These changes will affect all scenarios described in [RFC7476] 🌍. Additional evaluation will be required to make sure the relevant security requirements are appropriately met by the implementation of the chosen architecture in the various scenarios 🔎.

The ICN security aspects described in this document reflect the ICN security challenges outlined in [RFC7927] 📝.

The ICN architectures proposed so far have concentrated on authentication of delivered content to ensure its integrity 🛡️. Even though these approaches are primarily applicable to freely accessible content that doesn't require access authorization, they will generally support delivery of encrypted content 🔒.

The introduction of widespread caching mechanisms may also provide additional attack surfaces 😬. The caching architecture to be used also needs to be evaluated to make sure it meets the requirements of the usage scenarios 🧐.

In practice, the work on security in the various ICN research projects has been heavily concentrated on authentication of content 🫠. Work on authorization, access control, and privacy, plus security threats due to the expanded role of in-network caches, has been pretty limited 🥲. For example, a roadmap for improving the security model in NetInf can be found in [Renault09] 🗺️. As secure communications on the Internet become the norm, major gaps in ICN security aspects are bound to undermine the adoption of ICN 🚧. A comprehensive overview of ICN security is also provided in [Tourani16] 📚.

In the following subsections, we briefly consider the issues and point you to the work that has been done on the security aspects of the proposed architectures 👀✨

3.1. Authentication ✨

Okay bestie, let's talk about trust 🥺🔐. For fully secure content distribution, the receiver has to be able to reliably check three things before getting access:

  • validity: Is it a complete, uncorrupted copy of what was originally published?
  • provenance: Can the receiver identify the publisher? If so, can it and the source of any cached version of the document be adequately trusted?
  • relevance: Is the content an answer to the question that the receiver asked?

Every ICN architecture we're looking at mainly goes after validity 🔒, using strong cryptographic means to tie the content request name to the content. Provenance and relevance get targeted too, just to different extents. There's a total tussle between simplicity and efficiency of access and how much assurance you get for all these traits 😤. Keeping provenance info can get extremely costly, especially when you think about (historic) relationships between multiple objects 💸. So each architecture made its own call on whether the information-centric network does the assessment or leaves it to the application 🤷‍♀️.

Another thing to think about is whether a name should be irrevocably and immutably tied to a static piece of preexisting content, or whether the name can refer to dynamically or subsequently generated content. Schemes that only target immutable content can be less resource-hungry, since they can use digest functions instead of public key cryptography for generating and checking signatures. The catch is that this can increase the load on applications, because they have to manage many names, instead of using a single name for an item of evolving content that changes over time (e.g., a piece of data containing an age reference) 😩.

Data-Oriented Network Architecture (DONA) [DONA] and CCN [Jacobson09] [Smetters09] pack most of the data needed to verify provenance into all content retrievals, but they still need to retrieve extra information (typically a security certificate) to finish the provenance authentication. Whether the application has any control over that extra retrieval depends on the implementation. CCN is explicitly designed to handle dynamic content, allowing names to be pre-allocated and attached to subsequently generated content 🌈. DONA offers variants for both dynamic and immutable content.

Publish-Subscribe Internet Technology (PURSUIT) [Tagger12] appears to let implementers choose the authentication mechanism, so it can, in theory, emulate the authentication strategy of any of the other architectures. It isn't clear whether different choices would lead to a lack of interoperability 👀.

NetInf uses the Named Information (ni) URI scheme [RFC6920] to identify content. This lets NetInf assure validity without any additional information, but it gives no assurance on provenance or relevance. A "search" request lets an application identify relevant content, and applications may choose to structure content to allow provenance assurance, but this will typically require additional network access. So NetInf validity authentication is efficient in a network environment with intermittent connectivity, since it doesn't force additional network accesses and lets the application decide on provenance validation if required 🫶. For dynamic content, NetInf can use, e.g., signed manifests. For more details on NetInf security, see [Dannewitz10] 📚.

3.2. Authorization, Access Control, and Logging 🔑

This is a potentially major concern for all the ICN architectures we're looking at 🚨. They don't provide any built-in support for an authorization framework or for logging. Once content has been published and cached in servers, routers, or endpoints not controlled by the publisher, the publisher has no way to enforce access control, find out which users accessed the content, or revoke its publication. In some cases (where requests don't necessarily contain host or user identifier information), it's even hard for publishers themselves to perform access control 😭.

You could limit access by encrypting the content, but needing to distribute keys out-of-band seems to cancel out the advantages of in-network caching 🙃. Encryption also creates big challenges when you try to manage and restrict key access. An authorization delegation scheme has been proposed [Fotiou12]. This scheme lets semi-trusted entities (such as caches or CDN nodes) delegate access control decisions to third-party access control providers that the content publisher trusts. The former entities have no access to subscriber-related information and should respect the decisions of the access control providers 💅.

A recent proposal for an extra layer in the protocol stack [LIRA] gives control of the name resolution infrastructure to the publisher. This enables access logging, as well as some degree of active cache management, e.g., purging of stale content 🧹.

One possible technique for providing access control to heterogeneous groups, while still allowing a single encrypted object representation that remains cacheable, is Attribute-Based Encryption (ABE). A first proposal for this is presented in [Ion13]. To support heterogeneous groups and avoid having a single authority that holds a master key, multi-authority ABE can be used [Lewko11] 🧠.

Evaluating the impact of these features being absent will be essential for any scenario where an ICN architecture might be deployed. It may have a seriously negative impact on the applicability of ICN in commercial environments unless a solution can be found 💼.

3.3. Privacy 🕵️‍♀️

Another area the architectures haven't been significantly analyzed for is privacy 👁️. Caching implies a trade-off between network efficiency and privacy. Users' activity is way more exposed to the scrutiny of cache owners, who they may not have any relationship with. Still, it's worth noting that only the first-hop router or cache can see who requests what, since requests are aggregated and only the previous-hop router is visible when a request is forwarded 🙈.

Even though in many ICN architectures the source of a request isn't explicitly identified, an attacker may be able to get considerable information if they can monitor transactions on the cache and get details of the objects accessed, the topological direction of requests, and information about the timing of transactions. The persistence of data in the cache can make life easier for an attacker by giving them a longer timescale for analysis ⏳.

The impact of CCN on privacy has been investigated in [Lauinger10], and that analysis applies to all ICN architectures because it's mostly focused on the common caching aspect. The privacy risks of Named Data Networking are also highlighted in [Lauinger12]. More work on privacy in ICNs can be found in [Chaabane13]. Finally, Fotiou et al. define an ICN privacy evaluation framework in [Fotiou14] 🌸.

3.4. Changes to the Network Security Threat Model 💀

The architectural differences between the various ICN models and TCP/IP have real consequences for network security 🫣. There's limited consideration of threat models and potential mitigation in the documents describing the architectures. [Lauinger10] and [Chaabane13] also consider the changed threat model. Some of the key aspects are:

  • Caching implies a trade-off between network efficiency and user privacy, as discussed in Section 3.3.
  • More-powerful routers upgraded to handle persistent caching increase the network's attack surface. This is especially true in systems that may need to perform cryptographic checks on content being cached. For example, not doing this could lead routers to disseminate invalid content 😬.
  • ICNs make it difficult to identify the origin of a request (as mentioned in Section 3.3). That slows down the process of blocking requests and requires alternative mechanisms to tell legitimate requests apart from inappropriate ones, since access control lists (ACLs) will probably be of little value for ICN requests 🚫.
  • Denial-of-service (DoS) attacks may require more effort on ICN than on TCP/IP-based host-centric networks, but they're still feasible. One reason is that it's hard for the attacker to force repeated requests for the same content onto a single node. ICNs naturally spread content, so after the initial few requests, subsequent requests will generally be satisfied by alternative sources, which blunts the impact of a DoS attack. That said, there are many ways around this, e.g., generating random suffix identifiers that always result in cache misses 🥀.
  • Per-request state in routers can be abused for DoS attacks.
  • Caches can be misused in the following ways:
    • Attackers can use caches as storage to make their own content available.
    • Attackers can decrease the efficiency of caches with the goal of DoS attacks.
    • Content can be extracted by any attacker connected to the cache, putting users' privacy at risk.

Appropriate mitigation of these threats will need to be considered in each scenario 🛡️.

4. Evaluation Tools 🧪

Since ICN is an emerging area, the community is still developing effective evaluation environments, including releasing open-source implementations, simulators, emulators, and testbeds 🛠️. So far, none of the available evaluation tools can be seen as the one and only community reference evaluation tool. Plus, no single environment supports all the well-known ICN approaches, as we describe below, which makes it hard to directly compare the results obtained for different ICN approaches 😵‍💫. The subsections that follow review the currently publicly available ICN implementations, simulators, and experimental facilities.

An updated list of the available evaluation tools will be maintained at the ICNRG Wiki page: <https://trac.tools.ietf.org/group/irtf/trac/wiki/IcnEvaluationAndTestbeds>

4.1. Open-Source Implementations ✨

okay so the Named Data Networking (NDN) project has open-sourced a software reference implementation of the architecture and protocol called NDN (http://named-data.net) 🦋 it runs on various operating systems and comes with C and Java libraries you can use to build apps. literally so good for building your own stuff 💅

CCN-lite (http://www.ccn-lite.net) is a lightweight implementation of the CCN protocol that supports most of the key features of CCNx and is interoperable with CCNx 🌸 it implements the core CCN logic in about 1000 lines of code, so it's ideal for classroom work and course projects, and also for quickly experimenting with CCN extensions. Baccelli et al. use CCN-lite on top of the RIOT operating system to run experiments over an IoT testbed [Baccelli14] 🧚

PARC is offering CCN source code under various licensing schemes, so check <http://www.ccnx.org> for the details 🎀

The PURSUIT project (http://www.fp7-pursuit.eu) has open-sourced its Blackhawk publish-subscribe (Pub/Sub) implementation for Linux and Android 🍓 more details are at <https://github.com/fp7-pursuit/blackadder>. Blackadder uses the Click modular router for ease of development, and the code distribution includes a set of tools, test applications, and scripts. The POINT project (http://www.point-h2020.eu) is currently maintaining Blackadder 🫶

The 4WARD and SAIL projects have open-sourced software that implements different aspects of NetInf, e.g., the NetInf URI format and HTTP and UDP convergence layer, using different programming languages 💜 the Java implementation gives you a local caching proxy and client. There's also an OpenNetInf prototype, a hybrid host-centric and information-centric network architecture called the Global Information Network (GIN), a browser plug-in, and video-streaming software. See <http://www.netinf.org/open-source> for more details ✨

4.2. Simulators and Emulators 🌈

okay real talk, simulators and emulators should be able to capture faithfully all features and operations of the respective ICN architecture(s), and any limitations should be openly documented 📝 it's essential that these tools come with adequate logging facilities so you can do in-depth analysis and debugging 🔍 other needs include supporting medium- to large-scale experiments, quickly and correctly setting various configurations and parameters, and playing back traffic traces captured on a real testbed or network. And obviously this doesn't even begin to touch on the need for strong validation of any evaluated implementations 💀

4.2.1. ndnSIM

The Named Data Networking (NDN) project (http://named-data.net) has developed ndnSIM [ndnSIM] [ndnSIM2] 🧠 it's a module that can be plugged into the ns-3 simulator (https://www.nsnam.org) and supports the core features of NDN. You can use ndnSIM to experiment with various NDN applications and services, plus components built for NDN such as routing protocols and caching and forwarding strategies, among others. The code for ns-3 and ndnSIM is openly available to the community and can be the basis for implementing ICN protocols or applications. For more details, see <http://ndnsim.net/2.0/> 🦋

4.2.2. ccnSIM

ccnSim [ccnSim] is a CCN-specific simulator that was specially designed to handle forwarding of a large number of CCN-chunks (http://www.infres.enst.fr/~drossi/index.php?n=Software.ccnSim) 🌸 it's written in C++ for the OMNeT++ simulation framework (https://omnetpp.org). Other CCN-specific simulators include the CCN Packet-Level Simulator [CCNPL] and CCN-Joker [Cianci12]. CCN-Joker emulates in user space all basic aspects of a CCN node (e.g., handling of Interest and Data packets, cache sizing, replacement policies), including both flow and congestion control. The code is open source and is suitable for both emulation-based analyses and real experiments 🎀 and finally, Cabral et al. [MiniCCNx] use container-based emulation and resource isolation techniques to develop a prototyping and emulation tool 🧚

4.2.3. Icarus Simulator

The Icarus simulator [ICARUS] is all about caching in ICN, and it's agnostic with respect to any particular ICN implementation 💅 it's implemented in Python, uses the Fast Network Simulator Setup tool [Saino13], and is available at <http://icarus-sim.github.io>. Icarus has several caching strategies implemented, including ProbCache [Psaras12], node-centrality-based caching [Chai12], and hash-route-based caching [HASHROUT], among others 👑

ProbCache [Psaras12] takes a resource management view on caching decisions and approximates the available cache capacity along the path from source to destination. Based on that approximation, and to reduce caching redundancy across the path, it caches content probabilistically 🍓 according to [Chai12], the node with the highest "betweenness centrality" along the path from source to destination is responsible for caching incoming content. And [HASHROUT] calculates the hash function of a content's name and assigns contents to caches of a domain based on that. The hash space is split according to the number of caches in the network. Then, on subsequent requests, and again based on the hash of the name included in the request, edge routers redirect requests to the cache assigned to the corresponding hash space. [HASHROUT] is an off-path caching strategy, and unlike [Psaras12] and [Chai12], it requires minimum coordination and redirection overhead 🫶

In its latest update, Icarus also includes an implementation of the "Satisfied Interest Table" (SIT) [Sourlas15] 🌈 the SIT points in the direction where content has been sent recently. Among other benefits, this enables information resilience in case of network fragmentation (i.e., content can still be found in neighbor caches or in users' devices) and inherently supports user-assisted caching (i.e., P2P-like content distribution). Tortelli et al. [ICNSIMS] provide a comparison of ndnSIM, ccnSim, and Icarus 🦋

4.3. Experimental Facilities 🧪

An important consideration in evaluating any kind of future Internet mechanism is the characteristics of that evaluation itself 🔍 central to assessing the features of a novel mechanism is considering how it improves over already existing technologies, and by "how much". With the disruptive nature of clean-slate approaches generating new and different technological requirements, it's complex to provide meaningful results for a network-layer framework in comparison with what's deployed in the current Internet. So even with ICN implementations and simulators available, large-scale environments that support experimental evaluation of novel research are of prime importance to the advancement of ICN deployment 😭

Different experimental facilities have different characteristics and capabilities, e.g., low cost of use, reproducible configuration, easy-to-use tools, available background traffic, and being sharable ✨

4.3.1. Open Network Lab (ONL)

An example of an experimental facility that supports CCN is the Open Network Lab [ONL]. It currently comprises 18 extensible gigabit routers and over a 100 computers representing clients, and it's freely available to the public for running CCN experiments 🌸 nodes in ONL are preloaded with CCNx software. ONL provides a graphical user interface for easy configuration and testbed setup as per the experiment requirements, and it also serves as a control mechanism, allowing access to various control variables and traffic counters 💖

It's also possible to run and evaluate CCN over popular testbeds [PLANETLAB] [EMULAB] [DETERLAB] [OFELIA] by directly running, for example, the CCNx open-source code [Salsano13] [Carofiglio13] [Awiphan13] [Bernardini14] 🎀 and the Network Experimentation Programming Interface (NEPI) [NEPI] is a tool developed for controlling and managing large-scale network experiments. NEPI can be used to control and manage large-scale CCNx experiments, e.g., on PlanetLab [Quereilhac14] 🧚

4.3.2. POINT Testbed

The POINT project is maintaining a testbed with 40 machines across Europe, North America (Massachusetts Institute of Technology (MIT)), and Japan (National Institute of Information and Communications Technology (NICT)) 🍓 they're interconnected in a topology containing one Topology Manager and one rendezvous node that handle all publish/subscribe and topology formation requests [Parisis13]. All machines run Blackadder (see Section 4.1). New nodes can join, and experiments can be run on request 🫶

4.3.3. CUTEi: Container-Based ICN Testbed

NICT has also developed a testbed for ICN experiments [Asaeda14], comprising multiple servers located in Asia and other locations 🌈 each testbed server (or virtual machine) uses a Linux kernel-based container (LXC) for node virtualization. This testbed lets users run applications and protocols for ICN in two experimentation modes, using two different container designs:

  1. application-level experimentation using a "common container" and
  2. network-level experimentation using a "user container."

A common container is shared by all testbed users, and a user container is assigned to one testbed user 👑 a common container has a global IP address to connect with other containers or external networks, whereas each user container uses a private IP address and a user space providing a closed networking environment. A user can log in to their user containers using SSH with their certificate, or access them from PCs connected to the Internet using SSH tunneling 🔥

This testbed also implements an "on-filesystem cache" to allocate caching data on a UNIX filesystem 💅 the on-filesystem cache system accommodates two kinds of caches: "individual cache" and "shared cache." An individual cache is accessible for one dedicated router for the individual user, while a shared cache is accessible for a set of routers in the same group, to avoid duplicated caching in the neighborhood for cooperative caching 🦋

5. Security Considerations 🚨

This document does not impact the security of the Internet 🙈 but Section 3 outlines security and privacy concerns that might affect a deployment of a future ICN approach. Please, bestie, read Section 3 before you deploy anything 💀🔐

6. Informative References 📚

[4WARD6.1] Ohlman, B., et al., "First NetInf Architecture
           Description", 4WARD Project Deliverable D-6.1, April 2009.

[4WARD6.3] Ahlgren, B., et al., "NetInf Evaluation", 4WARD Project
           Deliverable D-6.3, June 2010.

[Arlitt97] Arlitt, M. and C. Williamson, "Internet web servers:
           workload characterization and performance implications",
           IEEE/ACM Transactions on Networking, vol. 5, pp. 631-645,
           DOI 10.1109/90.649565, 1997.

[Asaeda14] Asaeda, H., Li, R., and N. Choi, "Container-Based Unified
           Testbed for Information-Centric Networking", IEEE Network,
           vol. 28, no. 6, pp. 60-66, DOI 10.1109/MNET.2014.6963806,
           2014.

[Awiphan13]
           Awiphan, S., et al., "Video streaming over content centric
           networking: Experimental studies on PlanetLab", Proc.
           Computing, Communications and IT Applications Conference
           (ComComAp), IEEE, DOI 10.1109/ComComAp.2013.6533602, 2013.

[Baccelli14] Baccelli, E., et al., "Information Centric Networking in the IoT: Experiments with NDN in the Wild", Proceedings of the 1st international conference on Information-centric networking (ICN '14), ACM, DOI 10.1145/2660129.2660144, 2014.

[Barabasi99] Barabasi, A. and R. Albert, "Emergence of Scaling in Random Networks", Science, vol. 286, no. 5439, pp. 509-512, DOI 10.1126/science.286.5439.509, 1999.

[Barford98] Barford, P. and M. Crovella, "Generating representative web workloads for network and server performance evaluation", in ACM SIGMETRICS '98 / PERFORMANCE '98, pp. 151-160, DOI 10.1145/277851.277897, 1998.

[Barford99] Barford, P., Bestavros, A., Bradley, A., and M. Crovella, "Changes in web client access patterns: Characteristics and caching implications", World Wide Web, vol. 2, pp. 15-28, DOI 10.1023/A:1019236319752, 1999.

[Bellissimo04] Bellissimo, A., Levine, B., and P. Shenoy, "Exploring the Use of BitTorrent as the Basis for a Large Trace Repository", University of Massachusetts Amherst, Tech. Rep. 04-41, 2004.

[Bernardini14] Bernardini, C., et al., "Socially-aware caching strategy for content centric networking", Proc. IFIP Networking Conference, DOI 10.1109/IFIPNetworking.2014.6857093, 2014.

[Blefari-Melazzi12] Blefari Melazzi, N., et al., "Scalability Measurements in an Information-Centric Network", Springer Lecture Notes in Computer Science (LNCS), vol. 7586, DOI 10.1007/978-3-642-41296-7_6, 2012.

[Breslau99] Breslau, L., Cao, P., Fan, L., Phillips, G., and S. Shenker, "Web caching and zipf-like distributions: evidence and implications", Proc. of INFOCOM '99, New York (NY), USA, DOI 10.1109/INFCOM.1999.749260, March 1999.

[Busari02] Busari, M. and C. Williamson, "ProWGen: a synthetic workload generation tool for simulation evaluation of web proxy caches", Computer Networks, vol. 38, no. 6, pp. 779-794, DOI 10.1016/S1389-1286(01)00285-7, 2002.

[Carofiglio11] Carofiglio, G., Gallo, M., Muscariello, L., and D. Perino, "Modeling Data Transfer in Content-Centric Networking", Proceedings of the 23rd International Teletraffic Congress (ITC '11), San Francisco, USA, September 2011.

[Carofiglio13] Carofiglio, G., et al., "Optimal multipath congestion control and request forwarding in Information-Centric Networks", Proc. 2013 21st IEEE International Conference on Network Protocols (ICNP), DOI 10.1109/ICNP.2013.6733576, 2013.

[CCNPL] Institut de Recherche Technologique (IRT) SystemX, "CCNPL-SIM", http://systemx.enst.fr/ccnpl-sim.

[ccnSim] Rossini, G. and D. Rossi, "Large scale simulation of CCN networks", Proc. AlgoTel 2012, La Grande Motte, France, May 2012.

[Cha07] Cha, M., Kwak, H., Rodriguez, P., Ahn, Y.-Y., and S. Moon, "I tube, you tube, everybody tubes: analyzing the world's largest user generated content video system", Proceedings of the 7th ACM SIGCOMM conference on Internet measurement (IMC '07), San Diego (CA), USA, DOI 10.1145/1298306.1298309, October 2007.

[Chaabane13] Chaabane, A., De Cristofaro, E., Kaafar, M., and E. Uzun, "Privacy in Content-Oriented Networking: Threats and Countermeasures", ACM SIGCOMM Computer Communication Review, Vol. 43, Issue 3, DOI 10.1145/2500098.2500102, July 2013.

[Cheng08] Cheng, X., Dale, C., and J. Liu, "Statistics and social network of YouTube videos", 16th International Workshop on Quality of Service (IWQoS 2008), IEEE, pp. 229-238, DOI 10.1109/IWQOS.2008.32, 2008.

[Cheng13] Cheng, X., Liu, J., and C. Dale, "Understanding the Characteristics of Internet Short Video Sharing: YouTube as a Case Study", IEEE Transactions on Multimedia, vol. 15, issue 5, DOI 10.1109/TMM.2013.2265531, 2013.

[Chai12] Chai, W., He, D., Psaras, I., and G. Pavlou, "Cache 'Less for More' in Information-centric Networks", Proceedings of the 11th international IFIP TC 6 conference on Networking (IFIP '12), DOI 10.1007/978-3-642-30045-5_3, 2012.

[Cianci12] Cianci, I. et al. "CCN - Java Opensource Kit EmulatoR for Wireless Ad Hoc Networks", Proc. of the 7th International Conference on Future Internet Technologies (CFI '12), Seoul, Korea, DOI 10.1145/2377310.2377313, September 2012.

[CMT-D5.2] Beben, A., et al., "Scalability of COMET System", COMET Project Deliverable D5.2, February 2013.

[CMT-D6.2] Georgiades, M., et al., "Prototype Experimentation and Demonstration", COMET Project Deliverable D6.2, February 2013.

[Dannewitz10] Dannewitz, C., Golic, J., Ohlman, B., B. Ahlgren, "Secure Naming for A Network of Information", IEEE Conference on Computer Communications Workshops (INFOCOM), San Diego, CA, DOI 10.1109/INFCOMW.2010.5466661, March 2010.

[DETERLAB] Benzel, T., "The Science of Cyber-Security Experimentation: The DETER Project", Proceedings of the 27th Annual Computer Security Applications Conference (ACSAC '11), DOI 10.1145/2076732.2076752, December 2011.

[Dimitropoulos09] Dimitropoulos, X., et al., "Graph annotations in modeling complex network topologies", ACM Transactions on Modeling and Computer Simulation (TOMACS), vol. 19, no. 4, DOI 10.1145/1596519.1596522, November 2009.

[DONA] Koponen, T., et al., "A Data-Oriented (and Beyond) Network Architecture", Proceedings of the 2007 conference on Applications, technologies, architectures, and protocols for computer communications (SIGCOMM '07), ACM, DOI 10.1145/1282380.1282402, 2007.

[EMULAB] Eide, E., et al., "An Experimentation Workbench for Replayable Networking Research", Proceedings of the 4th USENIX conference on Networked systems design & implementation (NSDI '07), 2007.

[Fotiou12] Fotiou, N., et al., "Access control enforcement delegation for information-centric networking architectures", Proceedings of the second edition of the ICN workshop on Information-centric networking (ICN '12), ACM, DOI 10.1145/2342488.2342507, 2012.

[Fotiou14] Fotiou, N., et al., "A framework for privacy analysis of ICN architectures", Proc. Second Annual Privacy Forum (APF), Springer, DOI 10.1007/978-3-319-06749-0_8, 2014.

[Fri12] Fricker, C., Robert, P., Roberts, J. and N. Sbihi, "Impact of traffic mix on caching performance in a content-centric network", 2012 IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), Orlando, USA, DOI 10.1109/INFCOMW.2012.6193511, March 2012.

[Goog08] Google, "Official Google Blog: We knew the web was big...", July 2008, http://googleblog.blogspot.it/2008/07/we-knew-web-was-big.html.

[Guo07] Guo, L., Chen, S., Xiao, Z., Tan, E., Ding, X., and X. Zhang, "A performance study of BitTorrent-like peer-to-peer systems", IEEE Journal on Selected Areas in Communication, vol. 25, no. 1, pp. 155-169, DOI 10.1109/JSAC.2007.070116, 2007.

[HASHROUT] Saino, L., Psaras, I., and G. Pavlou, "Hash-routing Schemes for Information-Centric Networking", Proceedings of the 3rd ACM SIGCOMM workshop on Information-centric networking (ICN '13), DOI 10.1145/2491224.2491232, 2013.

[Hefeeda08] Hefeeda, M. and O. Saleh, "Traffic Modeling and Proportional Partial Caching for Peer-to-Peer Systems", IEEE/ACM Transactions on Networking, vol. 16, no. 6, pp. 1447-1460, DOI 10.1109/TNET.2008.918081, 2008.

[ICARUS] Saino, L., Psaras, I., and G. Pavlou, "Icarus: a Caching Simulator for Information Centric Networking (ICN)", Proceedings of the 7th International ICST Conference on Simulation Tools and Techniques (SimuTools '14), DOI 10.4108/icst.simutools.2014.254630, 2014.

[Detti12] Detti, A., et al., "Supporting the Web with an Information Centric Network that Routes by Name", Elsevier Computer Networks, vol. 56, no. 17, DOI 10.1016/j.comnet.2012.08.006, November 2012.

[ICNSIMS] Tortelli, M., et al., "CCN Simulators: Analysis and Cross-Comparison", Proceedings of the 1st international conference on Information-centric networking (ICN '14), ACM, DOI 10.1145/2660129.2660133, 2014.

[IMB2014] Imbrenda, C., Muscariello, L., and D. Rossi, "Analyzing Cacheable Traffic in ISP Access Networks for Micro CDN Applications via Content-Centric Networking", Proceedings of the 1st international conference on Information-centric networking (ICN '14), DOI 10.1145/2660129.2660146, 2014.

[Ion13] Ion, M., Zhang, J., and E. Schooler, "Toward content-centric privacy in ICN: attribute-based encryption and routing", Proceedings of the ACM SIGCOMM 2013 conference on SIGCOMM (SIGCOMM '13), ACM, DOI 10.1145/2486001.2491717, 2013.

[Jacobson09] Jacobson, V., et al., "Networking Named Content", Proceedings of the 5th international conference on Emerging networking experiments and technologies (CoNEXT '09), DOI 10.1145/1658939.1658941, 2009.

[Katsaros12] Katsaros, K., Xylomenos, G., and G. Polyzos, "GlobeTraff: a traffic workload generator for the performance evaluation of future Internet architectures", 2012 5th International Conference on New Technologies, Mobility and Security (NTMS), DOI 10.1109/NTMS.2012.6208742, 2012.

[Katsaros15] Katsaros, K., et al., "On the Inter-domain Scalability of Route-by-Name Information-Centric Network Architectures", Proc. IFIP Networking Conference, DOI 10.1109/IFIPNetworking.2015.7145308, 2015.

[Kaune09] Kaune, S. et al., "Modelling the Internet Delay Space Based on Geographical Locations", 17th Euromicro International Conference on Parallel, Distributed and Network-based Processing, Weimar, Germany, DOI 10.1109/PDP.2009.44, 2009.

[Labovitz10] Labovitz, C., Iekel-Johnson, S., McPherson, D., Oberheide, J., and F. Jahanian, "Internet inter-domain traffic", In Proceedings of the ACM SIGCOMM 2010 conference (SIGCOMM DOI 10.1145/1851182.1851194, 2010.

[Lauinger10] Lauinger, T., "Security and Scalability of Content-Centric Networking", Masters Thesis, Technische Universitaet Darmstadt and Eurecom, September 2010.

[Lauinger12] Lauinger, Y., et al, "Privacy Risks in Named Data Networking: What is the Cost of Performance?", ACM SIGCOMM Computer Communication Review, Vol. 42, Issue 5, DOI 10.1145/2378956.2378966, 2012.

[Led12] Lederer, S., Muller, C., and C. Timmerer, "Dynamic adaptive streaming over HTTP dataset", Proceedings of the ACM Multimedia Systems Conference (MMSys '12), pp. 89-94, DOI 10.1145/2155555.2155570, 2012.

[Lewko11] Lewko, A. and B. Waters, "Decentralizing attribute-based encryption", Proc. of EUROCRYPT 2011, Lecture Notes in Computer Science (LNCS), vol. 6632, pp. 568-588, DOI 10.1007/978-3-642-20465-4_31, 2011.

[LIRA] Psaras, I., Katsaros, K., Saino, L., and G. Pavlou, "Lira: A location independent routing layer based on source- provided ephemeral names", Electronic and Electrical Eng. Dept., UCL, London, UK, Tech. Rep. 2014, <http://www.ee.ucl.ac.uk/comit-project/publications.html>.

[Mahanti00] Mahanti, A., Williamson, C., and D. Eager., "Traffic analysis of a web proxy caching hierarchy", IEEE Network, Vol. 14, No. 3, pp. 16-23, DOI 10.1109/65.844496, May/June 2000.

[Maier09] Maier, G., Feldmann, A., Paxson, V., and M. Allman, "On dominant characteristics of residential broadband internet traffic", In Proceedings of the 9th ACM SIGCOMM conference on Internet measurement conference (IMC '09), New York, NY, USA, 90-102. DOI 10.1145/1644893.1644904, 2009.

[Marciniak08] Marciniak, P., Liogkas, N., Legout, A., and E. Kohler, "Small is not always beautiful", In Proc. of IPTPS, International Workshop of Peer-to-Peer Systems, Tampa Bay, Florida (FL), USA, February 2008.

[MiniCCNx] Cabral, C., et al., "High fidelity content-centric experiments with Mini-CCNx", 2014 IEEE Symposium on Computers and Communications (ISCC), DOI 10.1109/ISCC.2014.6912537, 2014.

[Montage] Hussain, A. and J. Chen, "Montage Topology Manager: Tools for Constructing and Sharing Representative Internet Topologies", DETER Technical Report, ISI-TR-684, August 2012.

[Muscariello11] Muscariello, L., Carofiglio, G., and M. Gallo, "Bandwidth and storage sharing performance in information centric networking", Proceedings of the ACM SIGCOMM workshop on Information-centric networking (ICN '11), DOI 10.1145/2018584.2018593, 2011.

[ndnSIM] Afanasyev, A., et al., "ndnSIM: NDN simulator for NS-3", NDN Technical Report NDN-0005, Revision 2, October 2012.

[ndnSIM2] Mastorakis, S., et al., "ndnSIM 2.0: A new version of the NDN simulator for NS-3", NDN Technical Report NDN-0028, Revision 1, January 2015.

[NEPI] Quereilhac, A., et al., "NEPI: An integration framework for Network Experimentation", 2011 19th International Conference on Software, Telecommunications and Computer Networks (SoftCOM), IEEE, 2011.

[OFELIA] Sune, M., et al., "Design and implementation of the OFELIA FP7 facility: The European OpenFlow testbed", Computer Networks, vol. 61, pp. 132-150, DOI 10.1016/j.bjp.2013.10.015, March 2014.

[ONL] DeHart, J., et al., "The open network laboratory: a resource for networking research and education", ACM SIGCOMM Computer Communication Review (CCR), vol. 35, no. 5, pp. 75-78, DOI 10.1145/1096536.1096547, 2005.

[Parisis13] Parisis, G., Trossen, D., and H. Asaeda, "A Node Design and a Framework for Development and Experimentation for an Information-Centric Network", IEICE Transactions on Communications, vol. E96-B, no. 7, pp. 1650-1660, July 2013.

[Perino11] Perino, D. and M. Varvello, "A Reality Check for Content Centric Networking", Proceedings of the ACM SIGCOMM workshop on Information-centric networking (ICN '11), DOI 10.1145/2018584.2018596, 2011.

[PLANETLAB] Chun, B., et al., "Planetlab: an overlay testbed for broad-coverage services", ACM SIGCOMM Computer Communication Review (CCR), vol. 33, no. 3, pp. 3-12, DOI 10.1145/956993.956995, 2003.

[PRST4.5] Riihijarvi, J., et al., "Final Architecture Validation and Performance Evaluation Report", PURSUIT Project Deliverable D4.5, January 2013.

[Psaras11] Psaras, I., Clegg, R., Landa, R., Chai, W., Pavlou, G., "Modelling and Evaluation of CCN-Caching Trees", Proceedings of the 10th international IFIP TC 6 conference on Networking, Valencia, Spain, May 2011.

[Psaras12] Psaras, I., Chai, W., and G. Pavlou, "Probabilistic In- Network Caching for Information-Centric Networks", Proceedings of the second edition of the ICN workshop on Information-centric networking (ICN '12), DOI 10.1145/2342488.2342501, 2012.

[Quereilhac14] Quereilhac, A., et al., "Demonstrating a unified ICN development and evaluation framework", Proceedings of the 1st international conference on Information-centric networking (ICN '14), ACM, DOI 10.1145/2660129.2660132, 2014.

[Renault09] Renault, E., Ahmad, A., and M. Abid, "Toward a Security Model for the Future Network of Information", Proceedings of the 4th International Conference on Ubiquitous Information Technologies & Applications (ICUT '09), IEEE, DOI 10.1109/ICUT.2009.5405676, 2009.

[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, <http://www.rfc-editor.org/info/rfc2330>.

[RFC5743] Falk, A., "Definition of an Internet Research Task Force (IRTF) Document Stream", RFC 5743, DOI 10.17487/RFC5743, December 2009, <http://www.rfc-editor.org/info/rfc5743>.

[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, <http://www.rfc-editor.org/info/rfc6920>.

[RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., Tyson, G., Davies, E., Molinaro, A., and S. Eum, "Information-Centric Networking: Baseline Scenarios", RFC 7476, DOI 10.17487/RFC7476, March 2015, <http://www.rfc-editor.org/info/rfc7476>.

[RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, "Information-Centric Networking (ICN) Research Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, <http://www.rfc-editor.org/info/rfc7927>.

[RFC7933] Westphal, C., Ed., Lederer, S., Posch, D., Timmerer, C., Azgin, A., Liu, W., Mueller, C., Detti, A., Corujo, D., Wang, J., Montpetit, M., and N. Murray, "Adaptive Video Streaming over Information-Centric Networking (ICN)", RFC 7933, DOI 10.17487/RFC7933, August 2016, <http://www.rfc-editor.org/info/rfc7933>.

[SAIL-B2] SAIL, "NetInf Content Delivery and Operations", SAIL Project Deliverable D-B.2, May 2012.

[SAIL-B3] Kutscher, D., Ed., et al., "Final NetInf Architecture", SAIL Project Deliverable D-B.3, January 2013, <http://www.sail-project.eu/deliverables/>.

[Saino13] Saino, L., Cocora, C., and G. Pavlou, "A Toolchain for Simplifying Network Simulation Setup", Proceedings of the 6th International ICST Conference on Simulation Tools and Techniques (SimuTools '13), 2013.

[Saleh06] Saleh, O., and M. Hefeeda, "Modeling and caching of peer- to-peer traffic", Proceedings of the 2006 IEEE International Conference on Network Protocols (ICNP), DOI 10.1109/ICNP.2006.320218, 2006.

[Salsano12] Salsano, S., et al., "Transport-Layer Issues in Information Centric Networks", Proceedings of the second edition of the ICN workshop on Information-centric networking (ICN '12), ACM, DOI 10.1145/2342488.2342493, 2012.

[Salsano13] Salsano, S., et al., "Information Centric Networking over SDN and OpenFlow: Architectural Aspects and Experiments on the OFELIA Testbed", Computer Networks, vol. 57, no. 16, pp. 3207-3221, DOI 10.1016/j.comnet.2013.07.031, November 2013.

[SensReqs] Karnouskos, S., et al., "Requirement considerations for ubiquitous integration of cooperating objects", 2011 4th IFIP International Conference on New Technologies, Mobility and Security (NTMS), DOI 10.1109/NTMS.2011.5720605, 2011.

[Smetters09] Smetters, D., and V. Jacobson, "Securing network content", Technical Report TR-2009-01, PARC, 2009.

[Sourlas15] Sourlas, V., Tassiulas, L., Psaras, I., and G. Pavlou, "Information Resilience through User-Assisted Caching in Disruptive Content-Centric Networks", 14th IFIP Networking Conference, Toulouse, France, DOI 10.1109/IFIPNetworking.2015.7145301, May 2015.

[Tagger12] Tagger, B., et al., "Update on the Architecture and Report on Security Analysis", Deliverable 2.4, PURSUIT EU FP7 project, April 2012.

[Tourani16] Tourani, R., Mick, T., Misra, S., and G. Panwar, "Security, Privacy, and Access Control in Information- Centric Networking: A Survey", arXiv:1603.03409, March 2016.

[VoCCN] Jacobson, V., et al., "VoCCN: Voice-over Content-Centric Networks", Proceedings of the 2009 workshop on Re- architecting the internet (ReArch '09), DOI 10.1145/1658978.1658980, 2009.

[Watts98] Watts, D. J. and S. H. Strogatz, "Collective dynamics of 'small-world' networks", Nature, vol. 393, no. 6684, pp. 440-442, DOI 10.1038/30918, April 1998.

[Yu06] Yu, H., Zheng, D., Zhao, B., and W. Zheng, "Understanding user behavior in large-scale video-on-demand systems", ACM SIGOPS Operating Systems Review - Proceedings of the 2006 EuroSys conference, Vol. 40, Issue 4, pp. 333-344, DOI 10.1145/1218063.1217968, April 2006.

[Zhang10a] Zhang, C., Dhungel, P., Wu, D., and K. Ross, "Unraveling the BitTorrent Ecosystem", IEEE Transactions on Parallel and Distributed Systems, vol. 22, issue 7, pp. 1164-1177, DOI 10.1109/TPDS.2010.123, 2010.

[Zhang10b] Zhang, L., et al., "Named Data Networking (NDN) Project", NDN Technical Report NDN-0001, October 2010, <http://named-data.net/publications/techreports/>.

[Zhou11] Zhou, J., Li, Y., Adhikari, K., and Z.-L. Zhang, "Counting YouTube videos via random prefix sampling", Proceedings of the 2011 ACM SIGCOMM conference on Internet measurement conference (IMC '11), Berlin, Germany, DOI 10.1145/2068816.2068851, November 2011. 🎬✨

Acknowledgments 🫶

Konstantinos Katsaros wrote the updated text of Section 2.2 and put together an extensive set of references. Literally the MVP 👑

Priya Mahadevan, Daniel Corujo, and Gareth Tyson helped with a draft version of this document. 💜

This document has benefited from reviews, pointers to the growing ICN literature, suggestions, comments, and proposed text from the following members of the IRTF Information-Centric Networking Research Group (ICNRG), listed in alphabetical order: Marica Amadeo, Hitoshi Asaeda, E. Baccelli, Claudia Campolo, Christian Esteve Rothenberg, Suyong Eum, Nikos Fotiou, Dorothy Gellert, Luigi Alfredo Grieco, Myeong-Wuk Jang, Ren Jing, Will Liu, Antonella Molinaro, Luca Muscariello, Ioannis Psaras, Dario Rossi, Stefano Salsano, Damien Saucez, Dirk Trossen, Jianping Wang, Yuanzhe Xuan, and Xinwen Zhang. The whole ICNRG crew is iconic 🌈🦋

The IRSG review was provided by Aaron Falk. 🌸

Authors' Addresses 📮

Kostas Pentikousis (editor), the one who ran the show 💅

Travelping
Koernerstr. 7-10
10785 Berlin
Germany

Email: k.pentikousis@travelping.com

Borje Ohlman 🌷

Ericsson Research
S-16480 Stockholm
Sweden

Email: Borje.Ohlman@ericsson.com

Elwyn Davies 🍓

Trinity College Dublin/Folly Consulting Ltd
Dublin, 2
Ireland

Email: davieseb@scss.tcd.ie

Spiros Spirou 🧚

Intracom Telecom
19.7 km Markopoulou Avenue
19002 Peania, Athens
Greece

Email: spis@intracom-telecom.com

Gennaro Boggia 🎀

Dept. of Electrical and Information Engineering
Politecnico di Bari
Via Orabona 4
70125 Bari
Italy

Email: g.boggia@poliba.it

And that's a wrap on RFC 7945! 🦋💖 Five authors, a whole ICNRG squad, and a reference list that could fill your entire feed. Bestie, we did it 🎉✨

📦 where this page comes from