tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7927

Informational
Pages: 38
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: IRTF

Information-Centric Networking (ICN) Research Challenges

Part 1 of 2, p. 1 to 17
None       Next Section

 


Top       ToC       Page 1 
Internet Research Task Force (IRTF)                     D. Kutscher, Ed.
Request for Comments: 7927                                           NEC
Category: Informational                                           S. Eum
ISSN: 2070-1721                                         Osaka University
                                                          K. Pentikousis
                                                              Travelping
                                                               I. Psaras
                                                                     UCL
                                                               D. Corujo
                                                  Universidade de Aveiro
                                                               D. Saucez
                                                                   INRIA
                                                              T. Schmidt
                                                             HAW Hamburg
                                                            M. Waehlisch
                                                               FU Berlin
                                                               July 2016


        Information-Centric Networking (ICN) Research Challenges

Abstract

   This memo describes research challenges for Information-Centric
   Networking (ICN), an approach to evolve the Internet infrastructure
   to directly support information distribution by introducing uniquely
   named data as a core Internet principle.  Data becomes independent
   from location, application, storage, and means of transportation,
   enabling or enhancing a number of desirable features, such as
   security, user mobility, multicast, and in-network caching.
   Mechanisms for realizing these benefits is the subject of ongoing
   research in the IRTF and elsewhere.  This document describes current
   research challenges in ICN, including naming, security, routing,
   system scalability, mobility management, wireless networking,
   transport services, in-network caching, and network management.

   This document is a product of the IRTF Information-Centric Networking
   Research Group (ICNRG).

[Page 2] 
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 Information-
   Centric Networking 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/rfc7927.

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.

Top       Page 3 
Table of Contents

   1. Introduction ....................................................4
   2. Problems with Host-Centric Communications .......................4
   3. ICN Terminology and Concepts ....................................6
      3.1. Terminology ................................................6
      3.2. Concepts ...................................................6
   4. ICN Research Challenges .........................................8
      4.1. Naming, Data Integrity, and Data Origin Authentication .....8
      4.2. Security ..................................................10
           4.2.1. Data Integrity and Origin Authentication ...........10
           4.2.2. Binding NDOs to Real-World Identities ..............11
           4.2.3. Access Control and Authorization ...................12
           4.2.4. Encryption .........................................13
           4.2.5. Traffic Aggregation and Filtering ..................13
           4.2.6. State Overloading ..................................13
           4.2.7. Delivering Data Objects from Replicas ..............14
           4.2.8. Cryptographic Robustness ...........................14
           4.2.9. Routing and Forwarding Information Bases ...........15
      4.3. Routing and Resolution System Scalability .................15
           4.3.1. Route-By-Name Routing ..............................15
           4.3.2. Lookup-By-Name Routing .............................16
           4.3.3. Hybrid Routing .....................................17
      4.4. Mobility Management .......................................18
      4.5. Wireless Networking .......................................20
      4.6. Rate and Congestion Control ...............................22
      4.7. In-Network Caching ........................................24
           4.7.1. Cache Placement ....................................24
           4.7.2. Content Placement: Content-to-Cache Distribution ...25
           4.7.3. Request-to-Cache Routing ...........................26
           4.7.4. Staleness Detection of Cached NDOs .................26
           4.7.5. Cache Sharing by Multiple Applications .............27
      4.8. Network Management ........................................27
      4.9. ICN Applications ..........................................29
           4.9.1. Web Applications ...................................30
           4.9.2. Video Streaming and Download .......................30
           4.9.3. Internet of Things .................................31
   5. Security Considerations ........................................32
   6. Informative References .........................................32
   Acknowledgments ...................................................37
   Authors' Addresses ................................................37

Top      ToC       Page 4 
1.  Introduction

   Information-Centric Networking (ICN) is an approach to evolve the
   Internet infrastructure to directly support accessing Named Data
   Objects (NDOs) as a first-order network service.  Data objects become
   independent of location, application, storage, and means of
   transportation, allowing for inexpensive and ubiquitous in-network
   caching and replication.  The expected benefits are improved
   efficiency and security, better scalability with respect to
   information/bandwidth demand, and better robustness in challenging
   communication scenarios.

   ICN concepts can be deployed by retooling the protocol stack: name-
   based data access can be implemented on top of the existing IP
   infrastructure, e.g., by allowing for named data structures,
   ubiquitous caching, and corresponding transport services, or it can
   be seen as a packet-level internetworking technology that would cause
   fundamental changes to Internet routing and forwarding.  In summary,
   ICN can evolve the Internet architecture towards a network model
   based on named data with different properties and different services.

   This document presents the ICN research challenges that need to be
   addressed in order to achieve these goals.  These research challenges
   are seen from a technical perspective, although business
   relationships between Internet players will also influence
   developments in this area.  We leave business challenges for a
   separate document, however.  The objective of this memo is to
   document the technical challenges and corresponding current
   approaches and to expose requirements that should be addressed by
   future research work.

   This document has been reviewed, commented on, and discussed
   extensively for nearly two years by the vast majority of ICNRG
   members, which certainly exceeds 100 individuals.  It is the
   consensus of ICNRG that the research challenges described in this
   document should be published in the IRTF stream of the RFC series.
   This document does not constitute a standard.

2.  Problems with Host-Centric Communications

   The best current practice to manage the above-mentioned growth in
   terms of data volume and number of devices is to increase
   infrastructure investment, employ application-layer overlays that
   cache content such as Content Distribution Networks (CDNs) and Peer-
   to-Peer (P2P) applications, provide location-independent access to
   data, and optimize its delivery.  In principle, such platforms

Top      ToC       Page 5 
   provide a service model of accessing named data objects (NDOs) (e.g.,
   replicated web resources in data centers) instead of a host-to-host
   packet delivery service model.

   However, since this functionality resides in overlays only, the full
   potential of content distribution platforms cannot be leveraged as
   the network is not aware of data requests and data transmissions.
   This has the following impact:

   o  Data traffic typically follows sub-optimal paths as it is
      effectively routed, depending on the overlay topology instead of
      the Internet-layer topology.

   o  Network capabilities, such as multicast and broadcast, are largely
      underutilized or not employed at all.  As a result, request and
      delivery for the same object have to be made multiple times.

   o  Overlays typically require significant infrastructure support,
      e.g., authentication portals, content storage, and applications
      servers, making it often impossible to establish local, direct
      communication.

   o  The forwarding layer cannot cooperate with transport-layer
      functions, so sometimes useful functionality such as local
      retransmission and local rate control have to be implemented with
      TCP proxies or other intermediaries.

   o  Provenance validation uses host authentication today.  As such,
      even if there are locally cached copies available, it is normally
      not easily possible to validate their authenticity.

   o  Many applications follow their own approach to caching,
      replication, transport, and authenticity validation (if at all),
      although they all share similar models for accessing named data
      objects in the network.

   Host-centric communication systems restrict applications to data
   transfer between end-hosts only.  Naming data directly provides a
   powerful "hook" for applications to exploit and natively support
   multi-party communication, e.g., multi-source/multi-destination
   communication and a ubiquitous information ecosystem that is not
   restricted to end-host addresses.

Top      ToC       Page 6 
3.  ICN Terminology and Concepts

3.1.  Terminology

   Information-Centric Networking (ICN):  A concept for communicating in
      a network that provides accessing named data objects as a first
      order service.  See Section 3.2 for details.

   Named Data Object (NDO):  Addressable data unit in an information-
      centric network that can represent a collection of bytes or a
      piece of information.  In ICN, each data object has a name bound
      to it, and there are typically mechanisms to secure (and validate)
      this binding.  Different ICN approaches have different concepts
      for how to map NDOs to individual units of transport, e.g., chunks
      and segments.  Sometimes smaller units may be represented by NDOs
      themselves.  Within the context of this document, an NDO is any
      named data object that can be requested from the network, and we
      do not consider sub-units below the NDO level.  In this document,
      we often use the terms "NDO" and "data object" interchangeably.

   Requestor:  Entity in an ICN network that is sending a request for a
      named data object to the network.

   Publisher:  Entity in an ICN network that publishes an NDO to the
      network, so that corresponding requests can reach the publisher.
      The publisher does not need to be identical to the actual creator,
      for example, a publisher could provide the service of hosting NDOs
      on behalf of the actual creators/owners.

3.2.  Concepts

   Fundamentally, ICN provides access to named data as a first-order
   network service, i.e., the network is able to serve requests to named
   data natively.  That means network nodes can receive requests for
   named data and act as necessary, for example, by forwarding the
   request to a suitable next hop.  Consequently, the network processes
   requests for named data objects (and corresponding responses)
   natively.  Every network node on a path is enabled to perform
   forwarding decisions, cache objects, etc.  This enables the network
   to forward such requests on optimal paths, employing the best
   transmission technologies at every node, e.g., broadcast/multicast
   transmission in wireless networks to avoid duplicate transmission of
   both requests and responses.

   In ICN, there is a set of common concepts and node requirements
   beyond this basic service model.  Naming data objects is a key
   concept.  In general, ICN names represent neither network nodes nor
   interfaces -- they represent NDOs independently of their location.

Top      ToC       Page 7 
   Names do play a key role in forwarding decisions and are used for
   matching requests to responses: in order to provide better support
   for accessing copies of NDOs regardless of their location, it is
   important to be able to validate that a response actually delivers
   the bits that correspond to an original request for named data.

   Name-content binding validation is a fundamental security service in
   ICN, and this is often achieved by establishing a verifiable binding
   between the object name and the actual object or an identity that has
   created the object.  ICN can support other security services, such as
   provenance validation and encryption, depending on the details of
   naming schemes, object models, and assumptions on infrastructure
   support.  Security services such as name-content binding validation
   are available to any node, i.e., not just the actual requestors.
   This is an important feature for enabling ingress gateways to check
   object authenticity to prevent denial-of-service attacks.

   Based on these fundamental properties, it is possible to leverage
   network storage ubiquitously: every ICN node can cache data objects
   and respond to requests for such objects -- it is not required to
   validate the authenticity of the node itself since name-content
   bindings can be validated.  Ubiquitous in-network storage can be used
   for different purposes: it can enable sharing, i.e., the same object
   copy can be delivered to multiple users/nodes as in today's proxy
   caches and CDNs.  It can also be used to make communication more
   robust (and perform better) by enabling the network to answer
   requests from local caches (instead of from origin servers).  In case
   of disruption (message not delivered), a node can resend the request,
   and it could be answered by an on-path cache, i.e., on the other side
   of the disrupted link.  The network itself would be able to send
   local retransmissions, which enables shorter round-trip times and the
   offloading of origin servers and other parts of the network.

   ICN potentially retrieves segments of NDOs from multiple data
   sources, so only a requestor can determine the completion of a
   retrieval process, i.e., the retrieval of NDOs or individual segments
   is typically controlled by a requestor.  For this reason, ICN
   transport protocols are typically based on a receiver-driven
   mechanism: requestors can control message sending rates by regulating
   the request sending rate (assuming that every response message has to
   be triggered by a request message).  Retransmission would be achieved
   by resending requests, e.g., after a timeout.  Because objects can be
   replicated, object transmission and transport sessions would not
   necessarily have end-to-end semantics: requests can be answered by
   caches, and a node can select one or multiple next-hop destinations
   for a particular request depending on configuration, observed
   performance, or other criteria.

Top      ToC       Page 8 
   This receiver-driven communication model potentially enables new
   interconnection and business models: a request for named data can be
   linked to an interest of a requestor (or requesting network) in data
   from another peer, which could suggest modeling peering agreements
   and charging accordingly.

4.  ICN Research Challenges

4.1.  Naming, Data Integrity, and Data Origin Authentication

   Naming data objects is as important for ICN as naming hosts is for
   today's Internet.  Fundamentally, ICN requires unique names for
   individual NDOs, since names are used for identifying objects
   independently of their location or container.  In addition, since
   NDOs can be cached anywhere, the origin cannot be trusted anymore,
   hence the importance of establishing a verifiable binding between the
   object and its name (name-data binding validation) so that a
   requestor can be sure that the received bits do correspond to the NDO
   originally requested (data integrity).  Data origin authentication is
   a different security service that can be related to naming, i.e.,
   verifying that an NDO has indeed been published by a publisher (that
   could be identified by a name prefix).

   The above functions are fundamentally required for the information-
   centric network to work reliably; otherwise, neither network elements
   nor requestors can trust object authenticity.  Lack of this trust
   enables several attacks, including DoS attacks, by injecting spoofed
   content into the network.  There are different ways to use names and
   cryptography to achieve the desired functions [ICNNAMING]
   [ICNSURVEY], and there are different ways to manage namespaces
   correspondingly.

   Two types of naming schemes have been proposed in the ICN literature:
   hierarchical and flat namespaces.  For example, a hierarchical scheme
   may have a structure similar to current URIs, where the hierarchy is
   rooted in a publisher prefix.  Such hierarchy enables aggregation of
   routing information, improving scalability of the routing system.  In
   some cases, names are human readable, which makes it possible for
   users to manually type in names, reuse, and, to some extent, map the
   name to the user intent.

   The second general class of naming schemes enables verifying the
   object's name-data integrity without requiring a Public Key
   Infrastructure (PKI) or other third party to first establish trust in
   the key.  This is achieved, e.g., by binding the hash of the NDO
   content to the object's name.  For instance, this can be done by
   directly embedding the hash of the content in the name.  Another
   option is an indirect binding, which embeds the public key of the

Top      ToC       Page 9 
   publisher in the name and signs the hash of the content with the
   corresponding private key.  The resulting names are typically non-
   hierarchical, or flat, although the publisher field could be employed
   to create a structure that could facilitate route aggregation.

   There are several design trade-offs for ICN naming that affect
   routing and security.  Hash-based names are not human readable nor
   hierarchical.  They can, however, provide some structure for
   aggregation, for instance, a name part corresponding to a publisher.
   In hash-based names with indirect binding, the key of the publisher
   is bound to the name of NDO, so when a user receives, e.g., the
   triplet, namely (data, key, signature), the receiving entity can
   verify that the NDO has been generated by the possessor of the
   private/public key pair and that the NDO has not been changed in
   transit (data integrity).  This can be done by cryptographically
   hashing the received key and the name of the NDO, and comparing it
   with the received hashed key.  Then, the key can be used to verify
   the signature.

   Data origin authentication can be achieved by validating signatures
   based on public key cryptography about an NDO's name and content.  In
   order to ascertain data integrity and origin authenticity with such
   an approach, a PKI-like system is required that would allow linking
   the corresponding public key to a trust chain.

   Research challenges specific to naming include:

   o  Naming static data objects can be performed by using content
      hashes as part of object names, so that publishers can calculate
      the hash over existing data objects and requestors, and any ICN
      node can validate the name-content binding by recalculating the
      hash and comparing it to the name (component).  [RFC6920]
      specifies a concrete naming format for this.

   o  Naming dynamic objects refers to use cases where the name has to
      be generated before the object is created.  For example, this
      could be the case for live streaming, when a publisher wants to
      make the stream available by registering stream chunk names in the
      network.  One approach to this can be hash-based names with
      indirect binding as described above.

   o  Requestor privacy protection can be a challenge in ICN as a direct
      consequence of the accessing-named-data-objects paradigm: if the
      network can "see" requests and responses, it can also log request
      history for network segments or individual users, which can be
      undesirable, especially since names are typically expected to be

Top      ToC       Page 10 
      long-lived.  That is, even if the name itself does not reveal much
      information, the assumption is that the name can be used to
      retrieve the corresponding data objects in the future.

   o  Updating and versioning NDOs can be challenging because it can
      contradict fundamental ICN assumptions: if an NDO can be
      replicated and stored in in-network storage for later retrieval,
      names have to be long-lived and the name-content binding must not
      change; updating an object (i.e., changing the content without
      generating a new name) is not possible.  Versioning is one
      possible solution but requires a naming scheme that supports it
      (and a way for requestors to learn about newer and older
      versions).

   o  Managing accessibility can also be a challenge.  In ICN, the
      general assumption is to enable ubiquitous access to NDOs, but
      there can be relevant use cases where access to objects should be
      restricted, for example, to a specific user group.  There are
      different approaches for this, such as object encryption
      (requiring key distribution and related mechanisms) or the concept
      of scopes, e.g., based on names that can only be used/resolved
      under some constraints.

4.2.  Security

   Security is an active research field in ICN.  This section provides
   an overview of important security features and corresponding
   challenges that are related to shifting to information-centric
   communications.  Some challenges are well understood, and there are
   (sometimes multiple different) approaches to address them, whereas
   other challenges are active research and engineering topics.

4.2.1.  Data Integrity and Origin Authentication

   As mentioned in Section 4.1, data integrity verification is an
   important ICN feature, since NDOs are retrieved not only from an
   original copy holder but also from any caching point.  Hence, the
   communication channel endpoints to retrieve NDOs are not trustable
   anymore, and solutions widely used today such as Transport Layer
   Security (TLS) [RFC5246] cannot be used as a general solution.  Since
   data objects can be maliciously modified, ICN should provide
   receivers with a security mechanism to verify the integrity of the
   data object, and there are different ways to achieve this.

Top      ToC       Page 11 
   An efficient approach for static NDOs is providing a name-content-
   binding by hashing an NDO and using the hash as a part of the
   object's name.  [RFC6920] provides a mechanism and a format for
   representing a digest algorithm and the actual digest in a name
   (amongst other information).

   For dynamic objects where it is desirable to refer to an NDO by name
   before the object has been created, public key cryptography is often
   applied, i.e., every NDO would be authenticated by means of a
   signature performed by the data object publisher so that any data
   object consumer can verify the validity of the data object based on
   the signature.  However, in order to verify the signature of an
   object, the consumer must know the public key of the entity that
   signed the object.

   Data origin authentication, i.e., verifying that an NDO has indeed
   been published by a publisher, requires a secure binding of an NDO
   name to a publisher identity -- this is also typically implemented
   using public key cryptography, i.e., by requiring a receiver to
   verify digital signatures that are part of received messages.

   One research challenge is then to support a mechanism to distribute
   the publisher's public keys to the consumers of data objects.  There
   are two main approaches to achieve this: one is based on an external
   third-party authority such as hierarchical Public Key Infrastructure
   (PKI) (see [RFC5280] for a description of hierarchical PKI), and the
   other is to adapt a hash-based scheme with indirect binding.  The
   former, as the name implies, depends on an external third party
   authority to distribute the public key of the publisher for the
   consumers.  In a hash-based scheme with indirect binding, the public
   key (or a hash of it) would be used as part of the name -- which is
   sufficient to validate the data integrity.

   In cases where information about the origin of a data object is not
   available by other means, the object itself would have to incorporate
   the necessary information to determine the object publisher, for
   example, with a certificate, that can be validated through the PKI.
   Once the certificate is authenticated, its public key can be used to
   authenticate the signed data object itself.

4.2.2.  Binding NDOs to Real-World Identities

   In addition to validating NDO authenticity, it is still important to
   bind real-world identities, e.g., a publisher identity, to objects,
   so that a requestor can verify that a received object was actually
   published by a certain source.

Top      ToC       Page 12 
   With hash-based names, real-world identity bindings are not
   intrinsically established: the name provides the hash of the NDO or
   of the public key that was used to sign the NDO.  There needs to be
   another binding to a real-world identity if that feature is
   requested.

   If the object name directly provides the publisher name and if that
   name is protected by a certificate that links to a PKI-like trust
   chain, the object name itself can provide an intrinsic binding to a
   real-world identity.

   Binding between NDOs and real-world identities is essential, but
   there is no universal way to achieve it as it is all intrinsic to a
   particular ICN approach.

4.2.3.  Access Control and Authorization

   Access control and authorization is a challenge in ICN, because of
   the lack of user-to-server authentication in the fundamental
   communication model based on named data.

   All ICN entities are capable of delivering NDOs on demand due to
   their in-network caching function.  In such an environment,
   traditional access control schemes based on Access Control List (ACL)
   are ill-suited since widely distributed ICN entities have to maintain
   an identical control policy over NDOs for each consumer, which is
   prohibited due to computational overhead and privacy issues.  There
   are two complementary approaches to address the issues:

   1.  Separated approach: access control service from a third party
       that is independent from ICN entities.  Due to the clear
       separation, ICN entities are free from computational overhead to
       determine the accessibility of NDOs by consumers; also, consumers
       can secure their privacy through the independent authorization
       entity [ACCESS-CTL-DEL].  Relevant challenges to this approach
       include reducing the authorization delay (when communicating to
       the access control provider) and currency and consistency of
       access control information (when access control lists are
       distributed).

   2.  Integrated approach: access control service from ICN entities.
       This mechanism is often based on content encryption and key
       distribution [ENCRYPTION-AC].  As mentioned previously, this
       approach suffers from prohibitive overhead for ICN entities due
       to the process of key verification.  While key distribution is
       challenging per se, this approach is beneficial in a way that
       NDOs can be retrieved without the help of an external access
       control provider.  Challenges to this approach include:

Top      ToC       Page 13 
       1.  applying an access control mechanism for dynamic NDOs in in-
           network caches in a timely manner;

       2.  providing consumers with the different levels of
           accessibility to individual NDOs in a scalable manner; and

       3.  managing key revocation and similar PKI management functions.

4.2.4.  Encryption

   In ICN, NDOs can be encrypted to implement access control (only
   consumers in possession of corresponding decryption keys can access
   the content) or privacy (same approach).  Distributing and managing
   the corresponding keys as well as providing usable interfaces to
   applications and human users are challenges and the subject of
   ongoing work.

   In principle, the challenges are similar to those of broadcast/media
   distribution, and similar approaches (combing symmetric with public
   key cryptography) are being investigated [NDN-CTL-SHARING].

4.2.5.  Traffic Aggregation and Filtering

   One request message to retrieve a data object can actually aggregate
   requests coming from several consumers.  This aggregation of requests
   reduces the overall traffic but makes per-requestor filtering harder.
   The challenge in this case is to provide a mechanism that allows
   request aggregation and per-requestor filtering.  A possible solution
   is to indicate the set of requestors in the aggregated request such
   that the response can indicate the subset of requestors allowed to
   access the data object.  However, this solution requires
   collaboration from other nodes in the network and is not suitable for
   caching.  Another possible solution is to encrypt data objects and
   ensure that only authorized consumers can decrypt them.  This
   solution does not preclude caching and does not require collaboration
   from the network.  However, it implies a mechanism to generate group
   keys (e.g., different private keys can be used to decrypt the same
   encrypted data object) [CHAUM].

4.2.6.  State Overloading

   ICN solutions that implement state on intermediate routers for
   request routing or forwarding (e.g., Content-Centric Networking (CCN)
   [CCN]) are subject to denial-of-service attacks from overloading or
   superseding the internal state of a router (e.g., "interest flooding"
   [BACKSCATTER]).  Additionally, stateful forwarding can enable attack
   vectors such as resource exhaustion or complexity attacks to the
   routing infrastructure.  The challenge is then to provision routers

Top      ToC       Page 14 
   and construct internal state in a way that alleviates sensibility to
   such attacks.  The problem becomes even harder if the protocol does
   not provide information about the origin of messages.  Without
   origin, it is a particular challenge to distinguish between regular
   (intense) use and misuse of the infrastructure.

4.2.7.  Delivering Data Objects from Replicas

   A common capability of ICN solutions is data replication and in-
   network storage.  Delivering replicated data objects from caches
   decouples content consumption from data sources, which leads to a
   loss of control on (1) content access and (2) content dissemination.
   In a widely distributed, decentralized environment like the Internet,
   this raises several challenges.

   One group of challenges is related to content management.  Without
   access control, a content provider loses the means to count and
   survey content consumption, to limit access scopes, to control or
   know about the number of copies of its data in the network, or to
   withdraw earlier publications reliably.  Any non-cooperative or
   desynchronized data cache may hinder an effective content management
   policy.

   Another group of challenges arises from potential traffic
   amplifications in the decoupled environment.  ICN solutions that
   attempt to retrieve content from several replicas in parallel, or
   decorrelated network routing states, but also distributed attackers
   may simultaneously initiate the transmission of content from multiple
   replicas towards the same destination (e.g., "initiated overloads" or
   "blockades" [BACKSCATTER]).  Methods for mitigating such threats need
   rigorous forwarding checks that require alignment with caching
   procedures (e.g., on-path or off-path).

4.2.8.  Cryptographic Robustness

   Content producers sign their content to ensure the integrity of data
   and to allow for data object authentication.  This is a fundamental
   requirement in ICN due to distributed caching.  Publishers, who
   massively sign content, which is long-lived, offer time and data to
   an attacker for comprising cryptographic credentials.  Signing a
   large amount of data eases common attacks that try to breach the key
   of the publisher.  Based on this observation, the following research
   challenges emerge:

Top      ToC       Page 15 
   o  To which extent does the content publication model conflict with
      the cryptographic limitations?

   o  How can we achieve transparent re-signing without introducing
      additional cryptographic weaknesses or key management overhead?

   In general, ICN implementations should be designed considering the
   guidelines provided by [RFC7696], especially regarding cryptographic
   algorithm agility, for example, [RFC6920] specifies a naming scheme
   for hash-based names that was designed to support algorithm agility.

4.2.9.  Routing and Forwarding Information Bases

   In information-centric networks, one attack vector is to increase the
   size of routing and forwarding information bases at ICN nodes, i.e.,
   attacking routing scalability in networks that rely on routing by
   name.  This is an intrinsic ICN security issue: possible mitigation
   approaches include combining routing information authenticity
   validation with filtering (e.g., maximum de-aggregation level
   whenever applicable, blacklists, etc.,).

4.3.  Routing and Resolution System Scalability

   ICN routing is a process that finds an NDO based on its name
   initially provided by a requestor.  ICN routing may comprise three
   steps: (1) name resolution, (2) discovery, and (3) delivery.  The
   name resolution step translates the name of the requested NDO into
   its locator.  The discovery step routes the request to the data
   object based on its name or locator.  The last step (delivery) routes
   the data object back to the requestor.  Depending on how these steps
   are combined, ICN routing schemes can be categorized as Route-By-Name
   Routing (RBNR), Lookup-By-Name Routing (LBNR), and Hybrid Routing
   (HR) as discussed in the following subsections.

4.3.1.  Route-By-Name Routing

   RBNR omits the first name resolution step as the name of the NDO is
   directly used to route the request to the data object.  Therefore,
   routing information for each data object has to be maintained in the
   routing table.  Since the number of data objects is very large
   (estimated as 10^11 back in 2007 [DONA], but this may be
   significantly larger than that, e.g., 10^15 to 10^22), the size of
   routing tables becomes a concern, as it can be proportional to the
   number of data objects unless an aggregation mechanism is introduced.
   On the other hand, RBNR reduces overall latency and simplifies the
   routing process due to the omission of the resolution process.  For
   the delivery step, RBNR needs another identifier (ID) of either host
   or location to forward the requested data object back to the

Top      ToC       Page 16 
   requestor.  Otherwise, an additional routing mechanism has to be
   introduced, such as breadcrumbs routing [BREADCRUMBS], in which each
   request leaves behind a trail of breadcrumbs along its forwarding
   path, and then the response is forwarded back to the requestor
   consuming the trail.

   Challenges specific to RBNR include:

   o  How can we aggregate the names of data objects to reduce the
      number of routing entries?

   o  How does a user learn the name that is designed for aggregation by
      the provider?  For example, although we name our contribution as
      "ICN research challenges", the IRTF (provider) may want to change
      the name to "/IETF/IRTF/ICN/Research challenges" for aggregation.
      In this case, how does a user learn the name "/IETF/IRTF/ICN/
      Research challenges" to retrieve the contribution initially named
      "ICN research challenges" without any resolution process?

   o  Without introducing the name aggregation scheme, can we still
      achieve scalable routing by taking advantage of topological
      structure and distributed copies?  For example, would employing
      compact routing [COMPACT], random walk [RANDOM], or greedy routing
      [GREEDY] work at the Internet scale?

   o  How can we incorporate copies of a data object in in-network
      caches in this routing scheme?

   o  Breadcrumbs routing implies a symmetric path for ICN request and
      response delivery.  Some network configurations and link types
      prohibit symmetric path forwarding, so it would be challenging to
      interconnect such networks to an infrastructure based on
      breadcrumbs routing.  For example, certain forwarding strategies
      in Delay-Tolerant Networking (DTN) [RFC4838] are employing
      opportunistic forwarding where responses cannot be assumed to
      travel the same path as requests.

4.3.2.  Lookup-By-Name Routing

   LBNR uses the first name resolution step to translate the name of the
   requesting data object into its locator.  Then, the second discovery
   step is carried out based on the locator.  Since IP addresses could
   be used as locators, the discovery step can depend on the current IP
   infrastructure.  The delivery step can be implemented similarly to IP
   routing.  The locator of the requestor is included in the request
   message, and then the requested data object is delivered to the
   requestor based on the locator.  An instantiation of LBNR is [MDHT].

Top      ToC       Page 17 
   Challenges specific to LBNR include:

   o  How can we build a scalable resolution system that provides:

      *  Fast lookup: Mapping the name of a data object to its locators
         (copies as well).

      *  Fast update: The location of a data object is expected to
         change frequently.  Also, multiple data objects may change
         their locations at the same time, e.g., data objects in a
         laptop.

   o  How can we incorporate copies of a data object in in-network
      caches in this routing scheme?

4.3.3.  Hybrid Routing

   HR combines RBNR and LBNR to benefit from their advantages.  Within a
   single administrative domain, e.g., an ISP, where scalability issues
   can be addressed with network planning, RBNR can be adopted to reduce
   overall latency by omitting the resolution process.  On the other
   hand, LBNR can be used to route between domains that have their own
   prefix (locator).

   For instance, a request message initially includes the name of the
   NDO for the operation of RBNR and is forwarded to a cached copy of
   the NDO or the original server.  When the request message fails to
   find a routing entry in the router, a name resolution step kicks in
   to translate the name into its locator before forwarding the request
   message based on the retrieved locator.

   Challenges specific to HR are:

   o  How can we design a scalable mapping system that, given the name
      of the NDO, should return a destination domain locator so that a
      user request can be encapsulated and forwarded to the domain?

   o  How can the mapping information be secured to prevent a malicious
      router from hijacking the request message by chaining its locator?

   o  How can the bind between the name and the content of the NDO be
      maintained for the verification of its origin and integrity when
      the name changes due to the retrieved locator?


Next Section