Internet Research Task Force (IRTF) K. Pentikousis, Ed. Request for Comments: 7945 Travelping Category: Informational B. Ohlman ISSN: 2070-1721 Ericsson E. Davies Trinity College Dublin S. Spirou Intracom Telecom G. Boggia Politecnico di Bari September 2016 Information-Centric Networking: Evaluation and Security Considerations
AbstractThis document presents a number of considerations regarding evaluating Information-Centric Networking (ICN) and sheds some light on the impact of ICN on network security. It also surveys the evaluation tools currently available to researchers in the ICN area and provides suggestions regarding methodology and metrics. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the <insert_name> Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7945.
Copyright Notice 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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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
RFC7476], the development phase that ICN is going through and the plethora of approaches to tackle the hardest problems make this a very active and growing research area but, on the downside, it also makes it more difficult to compare different proposals on an equal footing. Performance evaluation using actual network deployments has the advantage of realistic workloads and reflects the environment where the service or protocol is to be deployed. In the case of ICN, however, it is not currently clear what qualifies as a "realistic workload". Trace-based analysis of ICN is in its infancy, and more work is needed towards defining characteristic workloads for ICN evaluation studies. Accordingly, the experimental process and the evaluation methodology per se are actively being researched for different ICN architectures. Numerous factors affect the experimental results, including the topology selected; the background traffic that an application is being subjected to; network conditions such as available link capacities, link delays, and loss-rate characteristics throughout the selected topology; failure and disruption patterns; node mobility; and the diversity of devices used. The goal of this document is to summarize evaluation guidelines and tools alongside suggested data sets and high-level approaches. We expect this to be of interest to the ICN community as a whole, as it can assist researchers and practitioners alike to compare and contrast different ICN designs, as well as with the state of the art in host-centric solutions, and identify the respective strengths and weaknesses. We note that, apart from the technical evaluation of the
functionality of an ICN architecture, the future success of ICN will be largely driven by its deployability and economic viability. Therefore, 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 allow the architecture to spread across the network. This document has been 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 that are relevant for evolving the Internet at large. The ICNRG produces documents that provide guidelines for experimental activities in the area of ICN so that different, alternative solutions can be compared consistently, and information sharing can be accomplished for experimental deployments. This document incorporates input from ICNRG participants and their corresponding text contributions; it has been reviewed by several ICNRG active participants (see the Acknowledgments), and represents the consensus of the research group. That said, note that this document does not constitute an IETF standard; see also [RFC5743]. The remainder of this document is organized as follows. Section 2 presents 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. Section 2.4. There are two major types of evaluations of ICN that we see a need to make. One type is to compare ICN to traditional networking, and the other type is to compare different ICN implementations and approaches against each other. In this section, we detail some of the functional components needed when evaluating different ICN implementations and approaches.
RFC7476]. However, there is no single topology that can be used to easily evaluate all aspects of ICN. Therefore, one should choose from a range of topologies depending on the focus of the evaluation. For scalability and resilience studies, there is a wide range of synthetic topologies, such as the Barabasi-Albert model [Barabasi99] and the Watts-Strogatz small-world topology [Watts98]. These allow experiments to be performed whilst controlling various key parameters (e.g., node degree). These synthetic topologies are appropriate in the general case, as there are no practical assurances that a future information-centric network will have the same topology as any of today's networks. 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). A problem is the large size of the topology (approximately 45K Autonomous Systems, close to 200K links), which may limit the scalability of the employed evaluation tool. Katsaros et al. [Katsaros15] address this problem by using scaled down topologies created following the methodology described in [Dimitropoulos09]. 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, defining just a node graph will not 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 such parameters can be taken from existing platforms such as iPlane (http://iplane.cs.washington.edu). Synthetic values could be produced with specific tools [Kaune09].
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 with the purpose of modeling the traffic load, we can resort to measurement studies that investigate the composition of Internet traffic, such as [Labovitz10] and [Maier09]. In [Labovitz10], a large-scale measurement study was performed, with the purpose of studying the traffic crossing inter- domain links. The results indicate the dominance of Web traffic, amounting to 52% over all measured traffic. However, Deep Packet Inspection (DPI) techniques reveal that 25-40% of all HTTP traffic actually carries video traffic. Results from DPI techniques also reveal the difficulty in correctly identifying the application type in the case of P2P traffic: mapping observed port numbers to well- known applications shows P2P traffic constituting only 0.85% of overall traffic, while DPI raises this percentage to 18.32% [Labovitz10]. Relevant studies on a large ISP show that the percentage of P2P traffic ranges from 17% to 19% of overall traffic [Maier09]. Table 1 provides an overview of these figures. The "other" traffic type denotes traffic that cannot be classified in any of the first three application categories, and it consists 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 characterized 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, indicating that 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 the deployment of caching schemes, since caching a very small set of information items can dramatically increase the cache hit ratio. Several studies in the past few years have stated that Zipf's law is the discrete distribution that best represents the request frequency in a number of application scenarios, ranging from the Web to VoD services. The key aspect of 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 which 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, termed 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 exhibited a 'fetch-at-most-once' style of behavior. This is because peers tend to persistently store the files they download, a behavior that may also be prevalent 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 participating into a certain workload. However, they do not describe how these requests are distributed in time. This aspect is of primary importance when considering the performance of caching schemes since the ordering of the requests obviously affects the contents of a cache. For example, with a Least Frequently Used (LFU) cache replacement policy, if all requests for a certain item are submitted close in time, the item is unlikely to be evicted from the cache, even by a (globally) more popular item whose requests are more evenly distributed in time. The temporal ordering of requests gains even more importance when considering workloads consisting of various applications, all competing for the same cache space. b) The spatial locality of popularity i.e., how requests are distributed throughout a network. The importance of spatial locality relates to the ability to avoid redundant traffic in the network. If requests are highly localized in some area of the entire network, then similar requests can be more efficiently served with mechanisms such as caching and/or multicast, i.e., the concentration of similar requests in a limited area of the network allows increasing the perceived cache hit ratios at caches in the area and/or the traffic savings from the use of multicast. Table 2 provides an overview of 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 the creation of synthetic workloads following these models, and also allowing the generation of different traffic mixes, is described in [Katsaros12]. | Object Size | Temporal Locality | Popularity Distribution ===================================================================== Web | Concatenation | Ordering via the | Zipf: p(i)=K/i^a | of Lognormal | Least Recently Used | i: popularity rank | (body) and | (LRU) stack model | N: total items | Pareto (tail) | [Busari02] | K: 1/Sum(1/i^a) | [Barford98] | | a: distribution slope | [Barford99] | Exact timing via | values 0.64-0.84 | | exponential | [Breslau99] [Mahanti00] | | distribution | | | [Arlitt97] | --------------------------------------------------------------------- VoD | Duration/size: | No analytical models | Weibull: k=0.513, | Concatenated | | lambda=6010 | normal; most | Random distribution | | videos | across total | Gamma: k=0.372, | ~330 kbit/s | duration | theta=23910 | [Cheng13] | | [Cheng08] --------------------------------------------------------------------- P2P | Wide variation | Mean arrival rate of | Mandelbrot-Zipf | on torrent | 0.9454 torrents/hour | [Hefeeda08]: | sizes | Peers in a swarm | p(i)=K/((i+q)/a) | [Hefeeda08]. | arrive as | q: plateau factor, | No analytical | l(t)= l0*e^(-t/tau) | 5 to 100. | models exist: | l0: initial arrival | Flatter head than in | Sample a real | rate (87.74 average) | Zipf-like distribution | BitTorrent | tau: object | (where q=0) | distribution | popularity | | [Bellissimo04] | (1.16 average)* | | or use fixed | [Guo07] | | value | | ===================================================================== * Random ordering of swarm births (first request). For each swarm, calculate a different tau. Based on average tau and object popularity. Exponential decay rule for subsequent requests. Table 2: Overview of Traffic Type Models Table 3 summarizes the content catalog. With this shared point of reference, the use of the same set of parameters (depending on the scenario of interest) among researchers will be eased, and different proposals could be compared on a common base.
Traffic | Catalog | Mean Object Size | Popularity Distribution Load | Size | [Zhou11] [Fri12] | [Cha07] [Fri12] [Yu06] |[Goog08] | [Marciniak08] | [Breslau99] [Mahanti00] |[Zhang10a]| [Bellissimo04] | |[Cha07] | [Psaras11] | |[Fri12] | [Carofiglio11] | | | | | | | | | | =================================================================== Web | 10^12 | Chunk: 1-10 KB | Zipf with | | | 0.64 <= alpha <= 0.83 ------------------------------------------------------------------- File | 5x10^6 | Chunk: 250-4096 KB | Zipf with sharing | | Object: ~800 MB | 0.75 <= alpha <= 0.82 ------------------------------------------------------------------- UGC | 10^8 | Object: ~10 MB | Zipf, alpha >= 2 ------------------------------------------------------------------- VoD | 10^4 | Object: ~100 MB | Zipf, 0.65 <= alpha <= 1 (+HLS) | | ~1 KB (*) | (+DASH) | | ~5.6 KB (*) | =================================================================== UGC = User-Generated Content VoD = Video on Demand HLS = HTTP Live Streaming DASH = Dynamic Adaptive Streaming over HTTP (*) Using adaptive video streaming (e.g., HLS and DASH), with an optimal segment length (10 s for HLS and 2 s for DASH) and a bitrate of 4500 kbit/s [RFC7933] [Led12] Table 3: Content Catalog figures of merit and to leave more esoteric and less frequent cases for the future.
To arrive at a set of relevant metrics, it would be beneficial to look at the metrics used in existing ICN approaches, such as 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 used 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 subdivided into traffic and system metrics. It is important to note that the various approaches do not name or define metrics consistently. This is a major problem when trying to find metrics that allow comparison between approaches. For the purposes of exposition, we have tried to smooth over differences by classifying similarly defined metrics under the same name. Also, due to space constraints, we have chosen to report here only the most common metrics between approaches. For more details, the reader should consult the references for each approach. Traffic metrics in existing ICN approaches are summarized in Table 4. These are metrics for evaluating an approach mainly from the perspective of the end user, i.e., the consumer, provider, or owner of the content or service. Depending on the level where these metrics are measured, we have made the distinction into user, application, and network-level traffic metrics. So, for example, network-level metrics are mostly focused on packet characteristics, whereas user-level metrics can cover elements of human perception. The approaches do not make this distinction explicitly, but we can see from the table that CCN and NetInf have used metrics from all levels, PURSUIT and COMET have focused on lower-level metrics, and Connect and CONVERGENCE opted for higher-level metrics. Throughput and download time seem to be the most popular metrics altogether.
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 are more important for the end user, the owner or operator of the networking infrastructure is normally more interested in system metrics, which can reveal the efficiency of an approach. The most common system metrics used are: protocol overhead, total traffic, transit traffic, cost savings, router cost, and router energy consumption. Besides the traffic and systems metrics that aim to evaluate an approach as a whole, all surveyed approaches also evaluate the performance of individual components. Name resolution, request/data routing, and data caching are the most typical components, as summarized in Table 5. Forwarding Information Base (FIB) size and path length, i.e., the routing component metrics, are almost ubiquitous among approaches, perhaps due to the networking background of the involved researchers. That might be also the reason for the sometimes decreased focus on traffic and system metrics, in favor of component metrics. It can certainly be argued that traffic and system metrics are affected by component metrics; however, no approach has made the relationship clear. With this in mind and taking into account that traffic and system metrics are readily useful to end users and network operators, we will restrict ourselves to those in the following subsections.
Resolution | Routing | Cache ====================================================== Resolution | Request | FIB | Path | Size | Hit time | 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 proceeding, we should note that we would like our metrics to be applicable to host-centric networks as well. Standard metrics already exist for IP networks, and it would certainly be beneficial to take them into account. It is encouraging that many of the metrics used by existing ICN approaches can also be used on IP networks and that all of the approaches have tried on occasion to draw the parallels. RFC2330]. IPPM metrics include delay, delay variation, loss, reordering, and duplication. While the IPPM work is certainly based on packet- switched IP networks, it is conceivable that it can be modified and extended to cover ICN networks as well. However, more study is necessary to turn this claim into a certainty. Many experts have toiled for a long time on devising and refining the IPPM metrics and methods, so it would be an advantage to use them for measuring ICN performance. In addition, said metrics and methods work already for host-centric networks, so comparison with information-centric networks would entail only the ICN extension of the IPPM framework. Finally, an important benefit of measuring the transport performance of a network at its output, using Quality of Service (QoS) metrics such as IPPM, is that it can be done mostly without any dependence to applications.
Another option for measuring transport performance would be to use QoS metrics, not at the output of the network like with IPPM, but at the input to the application. For a live video-streaming application the relevant metrics would be startup latency, playout lag, and playout continuity. The benefit of this approach is that it abstracts away all details of the underlying transport network, so it can be readily applied to compare between networks of different concepts (host-centric, information-centric, or other). As implied earlier, the drawback of the approach is its dependence on the application, so it is likely that different types of applications will require different metrics. It might be possible to identify standard metrics for each type of application, but the situation is not as clear as with IPPM metrics, and further investigation is necessary. At a higher level of abstraction, we could measure the network's transport performance at the application output. This entails measuring the quality of the transported and reconstructed information as perceived by the user during consumption. In such an instance we would use Quality of Experience (QoE) metrics, which are by definition dependent on the application. For example, the standardized methods for obtaining a Mean Opinion Score (MOS) for VoIP (e.g., ITU-T Recommendation P.800) is quite different from those for IPTV (e.g., Perceptual Evaluation of Video Quality (PEVQ)). These methods are notoriously hard to implement, as they involve real users in a controlled environment. Such constraints can be relaxed or dropped by using methods that model human perception under certain environments, but these methods are typically intrusive. The most important drawback of measuring network performance at the output of the application is that only one part of each measurement is related to network performance. The rest is related to application performance, e.g., video coding, or even device capabilities, both of which are irrelevant to our purposes here and are generally hard to separate. We therefore see the use of QoE metrics in measuring ICN performance as a poor choice at this stage. RFC7476], it is reasonable 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 with respect not only to overall scalability and network efficiency, but
also the impact on the nodes themselves. Karnouskos et al. [SensReqs] provide a comprehensive set of sensor and IoT-related requirements, for example, which include aspects such as resource utilization, service life-cycle management, and device management. Additionally, various specific metrics are also critical in constrained environments, such as processing requirements, signaling overhead, and memory allocation for caching procedures, in addition to power consumption and battery lifetime. For gateways (which typically act as a point of service to a large number of nodes and have to satisfy the information requests from remote entities), we need to consider scalability-related metrics, such as frequency and processing of successfully satisfied information requests. Finally, given the in-network caching functionality of ICNs, efficiency and performance metrics of in-network caching have to be defined. Such metrics will need to guide researchers and operators regarding the performance of in-network caching algorithms. A first step on this direction has been made in [Psaras11]. The paper proposes a formula that approximates the proportion of time that 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 takes also into account the size of the cache of this router. The output of the model essentially reflects the probability that the CoI will be found in a given cache. An initial study [Psaras11] is applied to the CCN / Named Data Networking (NDN) framework, where contents get cached at every node they traverse. The formula according to which the probability or proportion is calculated is given by: 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 can also potentially be used to identify the gain of the system due to caching. This can then be used to compare against gains by other factors, e.g., addition of extra bandwidth in the network.
RFC7476]. Additional evaluation will be required to ensure 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 currently proposed have concentrated on authentication of delivered content to ensure its integrity. Even though the approaches are primarily applicable to freely accessible content that does not 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 ensure that 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 and security threats due to the expanded role of in-network caches has been quite limited. For example, a roadmap for improving the security model in NetInf can be found in [Renault09]. As secure communications on the Internet are becoming 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 provide pointers to the work that has been done on the security aspects of the architectures proposed.
applications because they are required to manage many names, rather than use 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] integrate most of the data needed to verify provenance into all content retrievals but need to be able to retrieve additional information (typically a security certificate) in order to complete the provenance authentication. Whether the application has any control of this extra retrieval will depend 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 dynamic and immutable content. Publish-Subscribe Internet Technology (PURSUIT) [Tagger12] appears to allow implementers to choose the authentication mechanism so that it can, in theory, emulate the authentication strategy of any of the other architectures. It is not clear whether different choices would lead to lack of interoperability. NetInf uses the Named Information (ni) URI scheme [RFC6920] to identify content. This allows NetInf to assure validity without any additional information but gives no assurance on provenance or relevance. A "search" request allows an application to identify relevant content, and applications may choose to structure content to allow provenance assurance, but this will typically require additional network access. NetInf validity authentication is consequently efficient in a network environment with intermittent connectivity as it does not force additional network accesses and allows the application to decide on provenance validation if required. For dynamic content, NetInf can use, e.g., signed manifests. For more details on NetInf security, see [Dannewitz10].
Access could be limited by encrypting the content, but the necessity of distributing keys out-of-band appears to negate the advantages of in-network caching. This also creates significant challenges when attempting to manage and restrict key access. An authorization delegation scheme has been proposed [Fotiou12]. This scheme allows semi-trusted entities (such as caches or CDN nodes) to delegate access control decisions to third-party access control providers that are trusted by the content publisher. 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 some degree of active cache management, e.g., purging of stale content. One possible technique that could allow for providing access control to heterogeneous groups and still allow for 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 has a master key multi-authority, ABE can be used [Lewko11]. Evaluating the impact of the absence of these features 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.
The impact of CCN on privacy has been investigated in [Lauinger10], and the analysis is applicable to all ICN architectures because it is mostly focused on the common caching aspect. The privacy risks of Named Data Networking are also highlighted in [Lauinger12]. Further work on privacy in ICNs can be found in [Chaabane13]. Finally, Fotiou et al. define an ICN privacy evaluation framework in [Fotiou14]. Lauinger10] and [Chaabane13] also consider the changed threat model. Some of the key aspects are: o Caching implies a trade-off between network efficiency and user privacy as discussed in Section 3.3. o More-powerful routers upgraded to handle persistent caching increase the network's attack surface. This is particularly the case in systems that may need to perform cryptographic checks on content that is being cached. For example, not doing this could lead routers to disseminate invalid content. o ICNs makes it difficult to identify the origin of a request (as mentioned in Section 3.3), slowing down the process of blocking requests and requiring alternative mechanisms to differentiate legitimate requests from inappropriate ones as access control lists (ACLs) will probably be of little value for ICN requests. o Denial-of-service (DoS) attacks may require more effort on ICN than on TCP/IP-based host-centric networks, but they are still feasible. One reason for this is that it is difficult for the attacker to force repeated requests for the same content onto a single node; ICNs naturally spread content so that after the initial few requests, subsequent requests will generally be satisfied by alternative sources, blunting 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. o Per-request state in routers can be abused for DoS attacks.
o Caches can be misused in the following ways: + Attackers can use caches as storage to make their own content available. + The efficiency of caches can be decreased by attackers 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.