doc: Add RFC documents

1 files changed, 2131 insertions, 0 deletions

diff --git a/doc/rfc/rfc7927.txt b/doc/rfc/rfc7927.txt
new file mode 100644
index 0000000..e016088
--- /dev/null
+++ b/doc/rfc/rfc7927.txt
@@ -0,0 +1,2131 @@
+
+
+
+
+
+
+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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kutscher, et al.              Informational                     [Page 1]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kutscher, et al.              Informational                     [Page 2]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+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
+
+
+
+
+
+
+
+
+
+
+Kutscher, et al.              Informational                     [Page 3]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+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
+
+
+
+
+
+Kutscher, et al.              Informational                     [Page 4]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   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.
+
+
+
+
+
+
+
+
+
+Kutscher, et al.              Informational                     [Page 5]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+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.
+
+
+
+Kutscher, et al.              Informational                     [Page 6]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   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.
+
+
+
+
+Kutscher, et al.              Informational                     [Page 7]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   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
+
+
+
+Kutscher, et al.              Informational                     [Page 8]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   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
+
+
+
+
+
+Kutscher, et al.              Informational                     [Page 9]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+      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.
+
+
+
+
+
+
+
+
+Kutscher, et al.              Informational                    [Page 10]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   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.
+
+
+
+
+
+Kutscher, et al.              Informational                    [Page 11]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   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:
+
+
+
+Kutscher, et al.              Informational                    [Page 12]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+       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
+
+
+
+Kutscher, et al.              Informational                    [Page 13]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   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:
+
+
+
+
+
+
+
+
+Kutscher, et al.              Informational                    [Page 14]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   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
+
+
+
+Kutscher, et al.              Informational                    [Page 15]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   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].
+
+
+
+
+Kutscher, et al.              Informational                    [Page 16]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   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?
+
+
+
+
+
+
+
+
+Kutscher, et al.              Informational                    [Page 17]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+4.4.  Mobility Management
+
+   Mobility management has been an active field in host-centric
+   communications for more than two decades.  In IETF in particular,
+   starting with [RFC2002], a multitude of enhancements to IP have been
+   standardized aiming to "allow transparent routing of IP datagrams to
+   mobile nodes in the Internet" [RFC5944].  In a nutshell, mobility
+   management for IP networks is locator-oriented and relies on the
+   concept of a mobility anchor as a foundation for providing always-on
+   connectivity to mobile nodes (see [MMIN]).  Other standards
+   organizations, such as 3GPP, have followed similar anchor-based
+   approaches.  Traffic to and from the mobile node must flow through
+   the mobility anchor, typically using a set of tunnels, enabling the
+   mobile node to remain reachable while changing its point of
+   attachment to the network.
+
+   Needless to say, an IP network that supports node mobility is more
+   complex than one that does not, as specialized network entities must
+   be introduced in the network architecture.  This is reflected in the
+   control plane as well, which carries mobility-related signaling
+   messages, establishes and tears down tunnels, and so on.  While
+   mobile connectivity was an afterthought in IP, in ICN, this is
+   considered a primary deployment environment.  Most, if not all, ICN
+   proposals consider mobility from the very beginning, although at
+   varying levels of architectural and protocol detail.  That said, no
+   solution has so far come forward with a definite answer on how to
+   handle mobility in ICN using native primitives.  In fact, we observe
+   that mobility appears to be addressed on an ICN proposal-specific
+   basis.  That is, there is no single paradigm solution, akin to
+   tunneling through a mobility anchor in host-centric networking, that
+   can be applied across different ICN proposals.  For instance,
+   although widely deployed mobile network architectures typically come
+   with their own network entities and associated protocols, they follow
+   the same line of design with respect to managing mobility.  This
+   design thinking, which calls for incorporating mobility anchors,
+   permeates in the ICN literature too.
+
+   However, employing mobility anchors and tunneling is probably not the
+   best way forward in ICN research for mobile networking.
+   Fundamentally, this approach is anything but information-centric and
+   location-independent.  In addition, as argued in [SEEN], current
+   mobility management schemes anchor information retrieval not only at
+   a specific network gateway (e.g., home agent in Mobile IP) but also
+   at a specific correspondent node due to the end-to-end nature of
+   host-centric communication.  However, once a change in the point of
+   attachment occurs, information retrieval from the original
+   "correspondent node" may no longer be optimal.  This was shown in
+   [MANI], for example, where a simple mechanism that triggers the
+
+
+
+Kutscher, et al.              Informational                    [Page 18]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   discovery of new retrieval providers for the same data object,
+   following a change in the point of attachment, clearly outperforms a
+   tunnel-based approach like Mobile IP in terms of object download
+   times.  The challenge here is how to capitalize on location
+   information while facilitating the use of ICN primitives, which
+   natively support multicast and anycast.
+
+   ICN naming and name resolution, as well as the security features that
+   come along, should natively support mobility.  For example, CCN [CCN]
+   does not have the restriction of spanning tree routing, so it is able
+   to take advantage of multiple interfaces or adapt to the changes
+   produced by rapid mobility (i.e., there is no need to bind a layer 3
+   address with a layer 2 address).  In fact, client mobility can be
+   simplified by allowing requests for new content to normally flow from
+   different interfaces or through newly connected points of attachment
+   to the network.  However, when the node moving is the (only) content
+   source, it appears that more complex network support might be
+   necessary, including forwarding updates and cache rebuilding.  A case
+   in point is a conversation network service, such as a voice or video
+   call between two parties.  The requirements in this case are more
+   stringent when support for seamless mobility is required, especially
+   when compared to content dissemination that is amenable to buffering.
+   Another parameter that needs to be paid attention to is the impact of
+   using different wireless access interfaces based on different
+   technologies, where the performance and link conditions can vary
+   widely depending of numerous factors.
+
+   In host-centric networking, mobility management mechanisms ensure
+   optimal handovers and (ideally) seamless transition from one point of
+   attachment to another.  In ICN, however, the traditional meaning of
+   "point of attachment" no longer applies as communication is not
+   restrained by location-based access to data objects.  Therefore, a
+   "seamless transition" in ICN ensures that content reception continues
+   without any perceptible change from the point of view of the ICN
+   application receiving that content.  Moreover, this transition needs
+   to be executed in parallel with ICN content identification and
+   delivery mechanisms, enabling scenarios such as preparation of the
+   content delivery process at the target connectivity point prior to
+   the handover (to reduce link switch disturbances).  Finally, these
+   mobility aspects can also be tightly coupled with network management
+   aspects, in respect to policy enforcement, link control, and other
+   parameters necessary for establishing the node's link to the network.
+
+   In summary, the following research challenges for ICN mobility
+   management can be derived:
+
+   o  How can mobility management take full advantage of native ICN
+      primitives?
+
+
+
+Kutscher, et al.              Informational                    [Page 19]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   o  How do we avoid the need for mobility anchors in a network that by
+      design supports multicast, anycast, and location-independent
+      information retrieval?
+
+   o  How can content retrieval mechanisms interface with specific link
+      operations, such as identifying which links are available for
+      certain content?
+
+   o  How can mobility be offered as a service that is only activated
+      when the specific user/content/conditions require it?
+
+   o  How can mobility management be coordinated between the node and
+      the network for optimization and policing procedures?
+
+   o  How do we ensure that managing mobility does not introduce
+      scalability issues in ICN?
+
+   o  How will the name resolution process be affected by rapid
+      topological changes when the content source itself is mobile?
+
+4.5.  Wireless Networking
+
+   Today, all layer 2 (L2) wireless network radio access technologies
+   are developed with a clear assumption in mind: the waist of the
+   protocol stack is IP, and it will be so for the foreseeable future.
+   By fixing the protocol stack waist, engineers can answer a large set
+   of questions, including how to handle conversational traffic (e.g.,
+   voice calls) vs. web traffic, how to support multicast, and so on, in
+   a rather straightforward manner.  Broadcast, on the other hand, which
+   is inherent in wireless communication, is not fully taken advantage
+   of.  On the contrary, researchers are often more concerned about
+   introducing mechanisms that ensure that "broadcast storms" do not
+   take down a network.  The question of how can broadcast better serve
+   ICN needs has yet to be thoroughly investigated.
+
+   Wireless networking is often intertwined with mobility, but this is
+   not always the case.  In fact, empirical measurements often indicate
+   that many users tend to connect (and remain connected) to a single
+   Wi-Fi access point for considerable amounts of time.  A case in
+   point, which is frequently cited in different variations in the ICN
+   literature, is access to a document repository during a meeting.  For
+   instance, in a typical IETF working group meeting, a scribe takes
+   notes, which are uploaded to a centralized repository (see Figure 1).
+   Subsequently, each meeting participant obtains a copy of the document
+   on their own devices for local use, annotation, and sharing with
+   colleagues that are not present at the meeting.  Note that in this
+   example, there is no node mobility and that it is not important
+
+
+
+
+Kutscher, et al.              Informational                    [Page 20]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   whether the document with the notes is uploaded in one go at the end
+   of the session or in a streaming-like fashion as is typical today
+   with online (cloud-based) document processing.
+
+           +---------------------+
+           | Document Repository |
+           +---------------------+
+                     ||
+                 (Internet)
+                     ||
+             +--------------+
+             | Access Point |
+             +--------------+
+            /  |             \
+           /   |              \
+          /    |               \
+     Scribe   Participant 1 ... Participant N
+
+                Figure 1: Document Sharing During a Meeting
+
+   In this scenario, we observe that the same data object bits
+   (corresponding to the meeting notes) need to traverse the wireless
+   medium at least N+1 times, where N is the number of meeting
+   participants obtaining a copy of the notes.  In effect, a broadcast
+   medium is shoehorned into N+1 virtual unicast channels.  One could
+   argue that wireless local connectivity is inexpensive, but this is
+   not the critical factor in this example.  The actual information
+   exchange wastes N times the available network capacity, no matter
+   what the spectral efficiency (or the economics) underlying the
+   wireless technology is.  This waste is a direct result of extending
+   the remote access paradigm from wired to wireless communication,
+   irrespective of the special characteristics of the latter.
+
+   It goes without saying that an ICN approach that does not take into
+   consideration the wireless nature of an interface will waste the same
+   amount of resources as a host-centric paradigm.  In-network caching
+   at the wireless access point could reduce the amount of data carried
+   over the backhaul link, but, if there is no change in the use of the
+   wireless medium, the NDO will still be carried over the wireless
+   ether N+1 times.  Intelligent caching strategies, replica placement
+   cooperation, and so on simply cannot alleviate this.  On the other
+   hand, promiscuous interface operation and opportunistic caching would
+   maximize wireless network capacity utilization in this example.
+
+   Arguably, if one designs a future wireless access technology with an
+   information-centric "layer 3" in mind, many of the design choices
+   that are obvious in an all-IP architecture may no longer be valid.
+
+
+
+
+Kutscher, et al.              Informational                    [Page 21]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   Although this is clearly outside the scope of this document, a few
+   research challenges that the wider community may be interested in
+   include:
+
+   o  Can we use wireless resources more frugally with the information-
+      centric paradigm than what is possible today in all-IP wireless
+      networks?
+
+   o  In the context of wireless access, how can we leverage the
+      broadcast nature of the medium in an information-centric network?
+
+   o  Would a wireless-oriented ICN protocol stack deliver significant
+      performance gains?  How different would it be from a wired-
+      oriented ICN protocol stack?
+
+   o  Is it possible that by changing the network paradigm to ICN we
+      can, in practice, increase the spectral efficiency (bits/s/Hz) of
+      a wireless network beyond what would be possible with today's
+      host-centric approaches?  What would be the impact of doing so
+      with respect to energy consumption?
+
+   o  Can promiscuous wireless interface operation coupled with
+      opportunistic caching increase ICN performance, and if so, by how
+      much?
+
+   o  How can a conversational service be supported at least as
+      efficiently as today's state-of-the-art wireless networks deliver?
+
+   o  What are the benefits of combining ICN with network coding in
+      wireless networks?
+
+   o  How can Multiple-Input Multiple-Output (MIMO) and Coordinated
+      Multipoint Transmission (CoMP) be natively combined with ICN
+      primitives in future cellular networks?
+
+4.6.  Rate and Congestion Control
+
+   ICN's receiver-driven communication model as described above creates
+   new opportunities for transport protocol design, as it does not rely
+   solely on end-to-end communication from a sender to a requestor.  A
+   requested data object can be accessible in multiple different network
+   locations.  A node can thus decide how to utilize multiple sources,
+   e.g., by sending parallel requests for the same NDO or by switching
+   sources (or next hops) in a suitable schedule for a series of
+   requests.
+
+
+
+
+
+
+Kutscher, et al.              Informational                    [Page 22]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   In this model, the requestor would control the data rate by
+   regulating its request sending rate and next by performing source/
+   next-hop selections.  Specific challenges depend on the specific ICN
+   approach, but general challenges for receiver-driven transport
+   protocols (or mechanisms, since dedicated protocols might not be
+   required) include flow and congestion control, fairness, network
+   utilization, stability (of data rates under stable conditions), etc.
+   [HRICP] and [CONTUG] describe request rate control protocols and
+   corresponding design challenges.
+
+   As mentioned above, the ICN communication paradigm does not depend
+   strictly on end-to-end flows, as contents might be received from in-
+   network caches.  The traditional concept of a flow is then somewhat
+   not valid as sub-flows, or flowlets, might be formed on the fly, when
+   fractions of an NDO are transmitted from in-network caches.  For a
+   transport-layer protocol, this is challenging, as any measurement
+   related to this flow as traditionally done by transport protocols
+   such as TCP, can often prove misleading.  For example, false Round-
+   Trip Time (RTT) measurements will lead to largely variable average
+   and smoothed RTT values, which in turn will trigger false timeout
+   expirations.
+
+   Furthermore, out-of-order delivery is expected to be common in a
+   scenario where parts of a data object are retrieved from in-network
+   caches rather than from the origin server.  Several techniques for
+   dealing with out-of-order delivery have been proposed in the past for
+   TCP, some of which could potentially be modified and reused in the
+   context of ICN.  Further research is needed in this direction though
+   to choose the right technique and adjust it according to the
+   requirements of the ICN architecture and transport protocol in use.
+
+   ICN offers routers the possibility to aggregate requests and can use
+   several paths, meaning that there is no such thing as a (dedicated)
+   end-to-end communication path, e.g., a router that receives two
+   requests for the same content at the same time only sends one request
+   to its neighbor.  The aggregation of requests has a general impact on
+   transport protocol design and offers new options for employing per-
+   node forwarding strategies and for rethinking in-network resource
+   sharing [RESOURCE-POOL].
+
+   Achieving fairness for requestors can be one challenge as it is not
+   possible to identify the number of requestors behind one particular
+   request.  A second problem related to request aggregation is the
+   management of request retransmissions.  Generally, it is assumed that
+   a router will not transmit a request if it transmitted an identical
+   request recently, and because there is no information about the
+   requestor, the router cannot distinguish the initial request from a
+
+
+
+
+Kutscher, et al.              Informational                    [Page 23]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   client from a retransmission from the same client.  In such a
+   situation, routers can adapt their timers to use the best of the
+   communication paths.
+
+4.7.  In-Network Caching
+
+   Explicitly named data objects allow for caching at virtually any
+   network element, including routers, proxy caches, and end-user
+   devices.  Therefore, in-network caching can improve network
+   performance by fetching content from nodes that are geographically
+   placed closer to the end user.  Several issues that need further
+   investigation have been identified with respect to in-network
+   caching.  In this section, we list important challenges that relate
+   to the properties of the new ubiquitous caching system.
+
+4.7.1.  Cache Placement
+
+   The declining cost of fast memory gives the opportunity to deploy
+   caches in network routers and to take advantage of cached NDOs.  We
+   identify two approaches to in-network caching, namely, on-path and
+   off-path caching.  Both approaches have to consider the issue of
+   cache location.  Off-path caching is similar to traditional proxy-
+   caching or CDN server placement.  Retrieval of contents from off-path
+   caches requires redirection of requests and, therefore, is closely
+   related to the Request-to-Cache Routing problem discussed below.
+   Off-path caches have to be placed in strategic points within a
+   network in order to reduce the redirection delays and the number of
+   detour hops to retrieve cached contents.  Previous research on proxy-
+   caching and CDN deployment is helpful in this case.
+
+   On the other hand, on-path caching requires less network intervention
+   and fits more neatly in ICN.  However, on-path caching requires line-
+   speed operation, which places more constraints on the design and
+   operation of in-network caching elements.  Furthermore, the gain of
+   such a system of on-path in-network caches relies on opportunistic
+   cache hits and has therefore been considered of limited benefit,
+   given the huge amount of contents hosted in the Internet.  For this
+   reason, network operators might initially consider only a limited
+   number of network elements to be upgraded to in-network caching
+   elements.  The decision on which nodes should be equipped with caches
+   is an open issue and might be based, among others, on topological
+   criteria or traffic characteristics.  These challenges relate to both
+   the Content Placement problem and the Request-to-Cache Routing
+   problem discussed below.
+
+   In most cases, however, the driver for the implementation,
+   deployment, and operation of in-network caches will be its cost.
+   Operating caches at line speed inevitably requires faster memory,
+
+
+
+Kutscher, et al.              Informational                    [Page 24]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   which increases the implementation cost.  Based on the capital to be
+   invested, ISPs will need to make strategic decisions on the cache
+   placement, which can be driven by several factors, such as avoidance
+   of inter-domain/expensive links, centrality of nodes, size of domain
+   and the corresponding spatial locality of users, and traffic patterns
+   in a specific part of the network (e.g., university vs. business vs.
+   fashion district of a city).
+
+4.7.2.  Content Placement: Content-to-Cache Distribution
+
+   Given a number of on-path or off-path in-network caching elements,
+   content-to-cache distribution will affect both the dynamics of the
+   system, in terms of request redirections (mainly in case of off-path
+   caches) and the gain of the system in terms of cache hits.  A
+   straightforward approach to content placement is on-path placement of
+   contents as they travel from source to destination.  This approach
+   reduces the computation and communication overhead of placing content
+   within the network but, on the other hand, might reduce the chances
+   of hitting cached contents.  This relates to the Request-to-Cache
+   Routing problem discussed next.
+
+   Furthermore, the number of replicas held in the system brings up
+   resource management issues in terms of cache allocation.  For
+   example, continuously replicating data objects in all network
+   elements results in redundant copies of the same objects.  The issue
+   of redundant replication has been investigated in the past for
+   hierarchical web caches.  However, in hierarchical web-caching,
+   overlay systems coordination between the data and the control plane
+   can guarantee increased performance in terms of cache hits.  Line-
+   speed, on-path, in-network caching poses different requirements;
+   therefore, new techniques need to be investigated.  In this
+   direction, reducing the redundancy of cached copies is a study item.
+   However, the issue of coordinated content placement in on-path caches
+   remains open.
+
+   The Content-to-Cache Allocation problem relates also to the
+   characteristics of the content to be cached.  Popular content might
+   need to be placed where it is going to be requested next.
+   Furthermore, issues of "expected content popularity" or temporal
+   locality need to be taken into account in designing in-network
+   caching algorithms in order for some contents to be given priority
+   (e.g., popular content vs. one-timers).  The criteria as to which
+   contents should be given priority in in-network content caches
+   relates also to the business relationships between content providers
+   and network operators.  Business model issues will drive some of
+   these decisions on content-to-cache distribution, but such issues are
+   outside the scope of this note and are not discussed here further.
+
+
+
+
+Kutscher, et al.              Informational                    [Page 25]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+4.7.3.  Request-to-Cache Routing
+
+   In order to take advantage of cached contents, requests have to be
+   forwarded to the nodes that cache the corresponding contents.  This
+   challenge relates to name-based routing, discussed earlier.  Requests
+   should ideally follow the path to the cached NDO.  However,
+   instructions as to which content is cached where cannot be broadcast
+   throughout the network.  Therefore, the knowledge of an NDO location
+   at the time of the request either might not exist or might not be
+   accurate (i.e., contents might have been removed by the time a
+   request is redirected to a specific node).
+
+   Coordination between the data and the control planes to update
+   information of cached contents has been considered, but in this case,
+   scalability issues arise.  We therefore have two options.  We either
+   have to rely on opportunistic caching, where requests are forwarded
+   to a server and in case the NDO is found on the path, then the
+   content is fetched from this node instead of the origin server, or we
+   employ cache-aware routing techniques.  Cache-aware routing can
+   involve either both the control and the data plane or only one of
+   them.  Furthermore, cache-aware routing can be done in a domain-wide
+   scale or can involve more than one individual Autonomous System (AS).
+   In the latter case, business relationships between ASes might need to
+   be exploited in order to build a scalable model.
+
+4.7.4.  Staleness Detection of Cached NDOs
+
+   Due to the largely distributed copies of NDOs in in-network caches,
+   ICN should be able to provide a staleness verification algorithm that
+   provides synchronization of NDOs located at their providers and in-
+   network caching points.  Two types of approaches can be considered
+   for this problem, namely direct and indirect approaches.
+
+   In the direct approach, each cache looks up certain information in
+   the NDO's name, e.g., the timestamp, that directly indicates its
+   staleness.  This approach is applicable to some NDOs that come from
+   machine-to-machine and Internet of Things scenarios, whose base
+   operation relies on obtaining the latest version of that NDO (i.e., a
+   soil sensor in a farm providing different continuous parameters that
+   are sent to a display or greenhouse regulation system) [FRESHNESS].
+
+   In the indirect approach, each cache consults the publisher of the
+   cached NDO about its staleness before serving it.  This approach
+   assumes that the NDO includes the publisher information, which can be
+   used to reach the publisher.  It is suitable for the NDO whose
+   expiration time is difficult to be set in advance, e.g., a web page
+
+
+
+
+
+Kutscher, et al.              Informational                    [Page 26]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   that contains the main text (which stays the same ever after) and the
+   interactive sections such as comments or ads (which are updated
+   irregularly).
+
+   It is often argued that ignoring stale NDOs in caches and simply
+   providing new names for updated NDOs might be sufficient rather than
+   using a staleness verification algorithm to manage them.  However,
+   notifying the new names of updated NDOs to users is not a trivial
+   task.  Unless the update is informed to all users at the same time,
+   some users would use the old name although they intended to retrieve
+   the updated NDO.
+
+   One research challenge is how to design consistency and coherence
+   models for caching NDOs along with their revision handling and
+   updating protocols in a scalable manner.
+
+4.7.5.  Cache Sharing by Multiple Applications
+
+   When ICN is deployed as a general, application-independent network
+   and cache infrastructure, multiple consumers and producers
+   (representing different applications) would communicate over the same
+   infrastructure.  With universal naming schemes or sufficiently unique
+   hash-based identifiers, different application could also share
+   identical NDOs in a transparent way.
+
+   Depending on the naming, data integrity, and data origin
+   authentication approaches, there may be technical and business
+   challenges to share caches across different applications, for
+   example, content protection, avoiding cache poisoning, ensuring
+   performance isolation, etc.  As ICN research matures, these
+   challenges should be addressed more specifically in a dedicated
+   document.
+
+4.8.  Network Management
+
+   Managing networks has been a core craft in the IP-based host-centric
+   paradigm ever since the technology was introduced in production
+   networks.  However, at the onset of IP, management was considered
+   primarily as an add-on.  Essential tools that are used daily by
+   networkers, such as ping and traceroute, did not become widely
+   available until more than a decade or so after IP was first
+   introduced.  Management protocols, such as SNMP, also became
+   available much later than the original introduction of IP, and many
+   still consider them insufficient despite the years of experience we
+   have running host-centric networks.  Today, when new networks are
+   deployed, network management is considered a key aspect for any
+   operator, a major challenge that is directly reflected in higher
+   operational cost if not done well.  If we want ICN to be deployed in
+
+
+
+Kutscher, et al.              Informational                    [Page 27]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   infrastructure networks, development of management tools and
+   mechanisms must go hand in hand with the rest of the architecture
+   design.
+
+   Although defining an FCAPS (Fault, Configuration, Accounting,
+   Performance, and Security) [ISOIEC-7498-4] management model for ICN
+   is clearly outside the scope of this document, there is a need for
+   creating basic tools early on while ICN is still in the design and
+   experimentation phases that can evolve over time and help network
+   operations centers (NOCs) to define policies, validate that they are
+   indeed used in practice, be notified early on about failures, and
+   determine and resolve configuration problems.  Authentication,
+   Authorization, and Accounting (AAA) as well as performance
+   management, from a NOC perspective, will also need to be considered.
+   Given the expectations for a large number of nodes and unprecedented
+   traffic volumes, automating tasks or even better employing self-
+   management mechanisms are preferred.  The main challenge here is that
+   all tools we have at our disposal today are node-centric, are end-to-
+   end oriented, or assume a packet-stream communication environment.
+   Rethinking reachability and operational availability, for example,
+   can yield significant insights into how information-centric networks
+   will be managed in the future.
+
+   With respect to network management, we see three different aspects.
+   First, any operator needs to manage all resources available in the
+   network, which can range from node connectivity to network bandwidth
+   availability to in-network storage to multi-access support.  In ICN,
+   users will also bring into the network significant resources in terms
+   of network coverage extension, storage, and processing capabilities.
+   Delay Tolerant Networking (DTN) characteristics should also be
+   considered to the degree that this is possible (e.g., content
+   dissemination through data mules).  Second, given that nodes and
+   links are not at the center of an information-centric network,
+   network management should capitalize on native ICN mechanisms.  For
+   example, in-network storage and name resolution can be used for
+   monitoring, while native publish/subscribe functionality can be used
+   for triggering notifications.  Finally, management is also at the
+   core of network-controlling capabilities by allowing operating
+   actions to be mediated and decided, triggering and activating
+   networking procedures in an optimized way.  For example, monitoring
+   aspects can be conjugated with different management actions in a
+   coordinated way, allowing network operations to flow in a concerted
+   manner.
+
+   However, the considerations on leveraging intrinsic ICN mechanisms
+   and capabilities to support management operations go beyond a simple
+   mapping exercise.  In fact, it not only raises a series of challenges
+   on its own, but also opens up new possibilities for both ICN and
+
+
+
+Kutscher, et al.              Informational                    [Page 28]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   "network management" as a concept.  For instance, naming mechanisms
+   are central to ICN-intrinsic operations, which are used to identify
+   and reach content under different aspects (e.g., hierarchically
+   structured vs. "flattish" names).  In this way, ICN is decoupled from
+   host-centric aspects on which traditional network management schemes
+   rely.  As such, questions are raised that can directly be translated
+   into challenges for network management capability, such as, for
+   example, how to address a node or a network segment in an ICN naming
+   paradigm, how to identify which node is connected "where", how to be
+   aware of the node capabilities (i.e., high or low-powered machine-to-
+   machine (M2M) node), and if there is a host-centric protocol running
+   where the management process can also leverage.
+
+   But, on the other hand, these same inherent ICN characteristics also
+   allow us to look into network management through a new perspective.
+   By centering its operations around NDOs, one can conceive new
+   management operations addressing, for example, per-content management
+   or access control, as well as analyzing performance per NDO instead
+   of per link or node.  Moreover, such considerations can also be used
+   to manage operational aspects of ICN mechanisms themselves.  For
+   example, [NDN-MGMT] reutilizes inherent content-centric capabilities
+   of CCN to manage optimal link connectivity for nodes, in concert with
+   a network optimization process.  Conversely, how these content-
+   centric aspects can otherwise influence and impact management in
+   other areas (e.g., security and resilience) is also important, as
+   exemplified in [CCN-ACCESS], where access control mechanisms are
+   integrated into a prototype of the [PURSUIT] architecture.
+
+   The set of core research challenges for ICN management includes:
+
+   o  Management and control of NDO reception at the requestor
+
+   o  Coordination of management information exchange and control
+      between ICN nodes and ICN network control points
+
+   o  Identification of management and controlling actions and items
+      through information naming
+
+   o  Relationship between NDOs and host entities identification, i.e.,
+      how to identify a particular link, interface, or flow that needs
+      to be managed
+
+4.9.  ICN Applications
+
+   ICN can be applied to different application domains and is expected
+   to provide benefits for application developers by providing a more
+   suitable interface for application developers (in addition to the
+
+
+
+
+Kutscher, et al.              Informational                    [Page 29]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   other ICN benefits described above).  [RFC7476] provides an overview
+   of relevant application domains at large.  This section discusses
+   opportunities and challenges for selected application types.
+
+4.9.1.  Web Applications
+
+   Intuitively, the ICN request/response communication style seems to be
+   directly mappable to web communication over HTTP.  NDO names could be
+   the equivalent of URIs in today's web, proprietary and transparent
+   caching could be obsoleted by ICN in-network caching, and developers
+   could directly use an ICN request/response API to build applications.
+
+   Research efforts such as [ICN2014-WEB-NDN] have analyzed real-world
+   web applications and ways to implement them in ICN.  The most
+   significant insight is that REST-style (Representational State
+   Transfer) web communication relies heavily on transmitting user/
+   application context information in HTTP GET requests, which would
+   have to be mapped to corresponding ICN messages.  The challenge in
+   ICN would be how to exactly achieve that mapping.  This could be done
+   to some degree by extending name formats or by extending message
+   structure to include cookies and similar context information.  The
+   design decisions would need to consider overhead in routers (for
+   example, if larger GET/Interest messages would have to be stored in
+   corresponding tables on routers).
+
+   Other challenges include the ability to return different results
+   based on requestor-specific processing in the presence of immutable
+   objects (and name-object bindings) in ICN and the ability for
+   efficient bidirectional communication, which would require some
+   mechanism to name and reach requestor applications.
+
+4.9.2.  Video Streaming and Download
+
+   One of ICN's prime application areas is video streaming and download
+   where accessing named data, object-level security, and in-network
+   storage can fulfill requirements for both video streaming and
+   download.  The applicability and benefits of ICN to video has been
+   demonstrated by several prototype developments
+   [ICN2014-AHLGREN-VIDEO-DEMO].
+
+   [VIDEO-STREAMING] discusses the opportunities and challenges of
+   implementing today's video services such as DASH-based (Dynamic
+   Adaptive Streaming over HTTP) streaming and download over ICN,
+   considering performance requirements, relationship to peer-to-peer
+   live streaming, IPTV, and Digital Rights Management (DRM).
+
+
+
+
+
+
+Kutscher, et al.              Informational                    [Page 30]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   In addition to just porting today's video application from a host-
+   centric paradigm to ICN, there are also promising opportunities to
+   leverage the ICN network services for redesigning and thus
+   significantly enhancing video access and distribution
+   [ICNRG-2015-01-WESTPHAL].  For example, ICN store and forward could
+   be leveraged for rate adaptation to achieve maximum throughput and
+   optimal Quality of Experience (QoE) in scenarios with varying link
+   properties, if capacity information is fed back to rate selection
+   algorithms at senders.  Other optimizations such as more aggressive
+   prefetching could be performed in the network by leveraging
+   visibility of chunk NDO names and NDO metadata in the network.
+   Moreover, multi-source rate adaptation in combination with network
+   coding could enable better QoE, for example, in multi-interface/
+   access scenarios where multiple paths from client to upstream caches
+   exist [RFC7476].
+
+4.9.3.  Internet of Things
+
+   The essence of ICN lies in the name-based routing that enables users
+   to retrieve NDOs by the names regardless of their locations.  By
+   definition, ICN is well suited for IoT applications, where users
+   consume data generated from IoTs without maintaining secure
+   connections to them.  The basic request/response style APIs of ICN
+   enable developers to build IoT applications in a simple and fast
+   manner.
+
+   Ongoing efforts such as [ICN-FOR-IOT], [ICN-ARCH], and
+   [ICN2014-NDNWILD] have addressed the requirements and challenges of
+   ICN for IoT.  For instance, many IoT applications depend on a PUSH
+   model where data transmission is initiated by the publisher, so they
+   can support various real-time applications (emergency alarm, etc.).
+   However, ICN does not support the PUSH model in a native manner due
+   to its inherent receiver-driven data transmission mechanism.  The
+   challenge would be how to efficiently support the PUSH model in ICN,
+   so it provides publish/subscribe-style APIs for IoT application
+   developers.  This could be done by introducing other types of
+   identifiers such as a device identifier or by extending the current
+   request/response communication style, which may result in heavy
+   overhead in ICN routers.
+
+   Moreover, key characteristics of the ICN underlying operation also
+   impact important aspects of IoT, such as the caching in content
+   storage of network forwarding entities.  This allows the
+   simplification of ICN-based IoT application development.  Since the
+   network is able to act on named content, generic names provide a way
+   to address content independently of the underlying device (and
+   access) technology, and bandwidth consumption is optimized due to the
+   availability of cached content.  However, these aspects raise
+
+
+
+Kutscher, et al.              Informational                    [Page 31]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   challenges themselves concerning the freshness of the information
+   received from the cache in contrast to the last value generated by a
+   sensor, as well as pushing content to specific nodes (e.g., for
+   controlling them), which requires individual addressing for
+   identification.  In addition, due to the heterogeneous nature of IoT
+   nodes, their processing capabilities might not be able to handle the
+   necessary content signing verification procedures.
+
+5.  Security Considerations
+
+   This document does not impact the security of the Internet.  Security
+   questions related to ICN are discussed in Section 4.2.
+
+6.  Informative References
+
+   [ACCESS-CTL-DEL]
+              Fotiou, N., Marias, G., and G. Polyzos, "Access control
+              enforcement delegation for information-centric networking
+              architectures", Proceedings of the second edition of the
+              ICN workshop on Information-centric networking (ICN
+              '12) Helsinki, Finland, DOI 10.1145/2342488.2342507, 2012.
+
+   [BACKSCATTER]
+              Waehlisch, M., Schmidt, TC., and M. Vahlenkamp,
+              "Backscatter from the Data Plane - Threats to Stability
+              and Security in Information-Centric Network
+              Infrastructure", Computer Networks Vol 57, No. 16, pp.
+              3192-3206, DOI 10.1016/j.comnet.2013.07.009, November
+              2013.
+
+   [BREADCRUMBS]
+              Rosensweig, E. and J. Kurose, "Breadcrumbs: Efficient,
+              Best-Effort Content Location in Cache Networks",
+              In Proceedings of the IEEE INFOCOM 2009,
+              DOI 10.1109/INFCOM.2009.5062201, April 2009.
+
+   [CCN]      Jacobson, V., Smetters, D., Thornton, J., Plass, M.,
+              Briggs, N., and R. Braynard, "Networking Named Content",
+              CoNEXT 2009, DOI 10.1145/1658939.1658941, December 2009.
+
+   [CCN-ACCESS]
+              Fotiou, N., Marias, G., and G. Polyzos, "Access control
+              enforcement delegation for information-centric networking
+              architectures", In Proceedings of the second edition of
+              the ICN workshop on Information-centric networking (ICN
+              '12), ACM, New York, NY, USA, 85-90,
+              DOI 10.1145/2342488.2342507, 2012.
+
+
+
+
+Kutscher, et al.              Informational                    [Page 32]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   [CHAUM]    Chaum, D. and E. van Heijst, "Group signatures",
+              In Proceedings of EUROCRYPT, DOI 10.1007/3-540-46416-6_22,
+              1991.
+
+   [COMPACT]  Cowen, L., "Compact routing with minimum stretch",
+              In Journal of Algorithms, vol. 38, pp. 170-183,
+              DOI 10.1006/jagm.2000.1134, 2001.
+
+   [CONTUG]   Arianfar, S., Nikander, P., Eggert, L., Ott, J., and W.
+              Wong, "ConTug: A Receiver-Driven Transport Protocol for
+              Content-Centric Networks", Technical Report Aalto
+              University Comnet, 2011.
+
+   [DONA]     Koponen, T., Ermolinskiy, A., Chawla, M., Kim, K., gon
+              Chun, B., and S. Shenker, "A Data-Oriented (and Beyond)
+              Network Architecture", In Proceedings of SIGCOMM 2007,
+              DOI 10.1145/1282427.1282402, August 2007.
+
+   [ENCRYPTION-AC]
+              Kurihara, J., Uzun, E., and C. Wood, "An Encryption-Based
+              Access Control Framework for Content-Centric Networking",
+              IFIP Networking 2015, Toulouse, France,
+              DOI 10.1109/IFIPNetworking.2015.7145300, September 2015.
+
+   [FRESHNESS]
+              Quevedo, J., Corujo, D., and R. Aguiar, "Consumer Driven
+              Information Freshness Approach for Content Centric
+              Networking", IEEE INFOCOM Workshop on Name-Oriented
+              Mobility Toronto, Canada,
+              DOI 10.1109/INFCOMW.2014.6849279, May 2014.
+
+   [GREEDY]   Papadopoulos, F., Krioukov, D., Boguna, M., and A. Vahdat,
+              "Greedy forwarding in dynamic scale-free networks embedded
+              in hyperbolic metric spaces", In Proceedings of the IEEE
+              INFOCOM, San Diego, USA, DOI 10.1109/INFCOM.2010.5462131,
+              2010.
+
+   [HRICP]    Carofiglio, G., Gallo, M., and L. Muscariello, "Joint hop-
+              by-hop and receiver-driven interest control protocol for
+              content-centric networks", In Proceedings of ACM SIGCOMM
+              ICN 2012, DOI 10.1145/2342488.2342497, 2012.
+
+   [ICN-ARCH] Zhang, Y., Raychadhuri, D., Grieco, L., Baccelli, E.,
+              Burke, J., Ravindran, R., Ed., and G. Wang, "ICN based
+              Architecture for IoT - Requirements and Challenges", Work
+              in Progress, draft-zhang-iot-icn-challenges-02, August
+              2015.
+
+
+
+
+Kutscher, et al.              Informational                    [Page 33]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   [ICN-FOR-IOT]
+              Lindgren, A., Ben Abdesslem, F., Ahlgren, B., Schelen, O.,
+              and A. Malik, "Applicability and Tradeoffs of Information-
+              Centric Networking for Efficient IoT", Work in Progress,
+              draft-lindgren-icnrg-efficientiot-03, July 2015.
+
+   [ICN2014-AHLGREN-VIDEO-DEMO]
+              Ahlgren, B., Jonasson, A., and B. Ohlman, "Demo Overview:
+              HTTP Live Streaming over NetInf Transport", ACM SIGCOMM
+              Information-Centric Networking Conference Paris, France,
+              DOI 10.1145/2660129.2660136, September 2014.
+
+   [ICN2014-NDNWILD]
+              Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M.
+              Waehlisch, "Information Centric Networking in the IoT:
+              Experiments with NDN in the Wild", ACM SIGCOMM
+              Information-Centric Networking Conference Paris, France,
+              DOI 10.1145/2660129.2660144, September 2014.
+
+   [ICN2014-WEB-NDN]
+              Moiseenko, I., Stapp, M., and D. Oran, "Communication
+              Patterns for Web Interaction in Named Data Networking",
+              ACM SIGCOMM Information-Centric Networking
+              Conference Paris, France, DOI 10.1145/2660129.2660152,
+              September 2014.
+
+   [ICNNAMING]
+              Ghodsi, A., Koponen, T., Rajahalme, J., Sarolahti, P., and
+              S. Shenker, "Naming in Content-Oriented Architectures",
+              In Proceedings ACM SIGCOMM Workshop on Information-Centric
+              Networking (ICN), DOI 10.1145/2018584.2018586, 2011.
+
+   [ICNRG-2015-01-WESTPHAL]
+              Westphal, C., "Video over ICN", IRTF ICNRG
+              Meeting Cambridge, Massachusetts, USA, January 2015,
+              <http://www.ietf.org/proceedings/interim/2015/01/13/icnrg/
+              slides/slides-interim-2015-icnrg-1-0.pptx>.
+
+   [ICNSURVEY]
+              Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D.,
+              and B. Ohlman, "A Survey of Information-Centric
+              Networking", In Communications Magazine, IEEE, vol. 50,
+              no. 7, pp. 26-36, DOI 10.1109/MCOM.2012.6231276, 2012.
+
+
+
+
+
+
+
+
+Kutscher, et al.              Informational                    [Page 34]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   [ISOIEC-7498-4]
+              ISO, "Information Processing Systems -- Open Systems
+              Interconnection -- Basic Reference Model -- Part 4:
+              Management Framework", November 1989,
+              <http://standards.iso.org/ittf/PubliclyAvailableStandards/
+              s014258_ISO_IEC_7498-4_1989(E).zip>.
+
+   [MANI]     Pentikousis, K. and T. Rautio, "A multiaccess Network of
+              Information", WoWMoM 2010 IEEE,
+              DOI 10.1109/WOWMOM.2010.5534922, June 2010.
+
+   [MDHT]     D'Ambrosio, M., Dannewitz, C., Karl, H., and V.
+              Vercellone, "MDHT: A hierarchical name resolution service
+              for information-centric networks", ACM SIGCOMM workshop on
+              Information-centric networking Toronto, Canada,
+              DOI 10.1145/2018584.2018587, August 2011.
+
+   [MMIN]     Pentikousis, K. and P. Bertin, "Mobility management in
+              infrastructure networks", Internet Computing, IEEE vol.
+              17, no. 5, pp. 74-79, DOI 10.1109/MIC.2013.98, October
+              2013.
+
+   [NDN-CTL-SHARING]
+              Yu, Y., "Controlled Sharing of Sensitive Content", IRTF
+              ICNRG Meeting San Francisco, USA, October 2015,
+              <https://www.ietf.org/proceedings/interim/2015/10/03/
+              icnrg/slides/slides-interim-2015-icnrg-4-8.pdf>.
+
+   [NDN-MGMT] Corujo, D., Aguiar, R., Vidal, I., and J. Garcia-Reinoso,
+              "A named data networking flexible framework for management
+              communications", Communications Magazine, IEEE vol. 50,
+              no. 12, pp. 36-43, DOI 10.1109/MCOM.2012.6384449, December
+              2012.
+
+   [PURSUIT]  Fotiou et al., N., "Developing Information Networking
+              Further: From PSIRP to PURSUIT", In Proceedings of Proc.
+              BROADNETS. ICST, DOI 10.1007/978-3-642-30376-0_1, 2010.
+
+   [RANDOM]   Gkantsidis, C., Mihail, M., and A. Saberi, "Random walks
+              in peer-to-peer networks: algorithms and evaluation",
+              In Perform. Eval., vol. 63, pp. 241-263,
+              DOI 10.1016/j.peva.2005.01.002, 2006.
+
+   [RESOURCE-POOL]
+              Psaras, I., Saino, L., and G. Pavlou, "Revisiting Resource
+              Pooling: The case of In-Network Resource Sharing", ACM
+              HotNets Los Angeles, USA, DOI 10.1145/2670518.2673875,
+              October 2014.
+
+
+
+Kutscher, et al.              Informational                    [Page 35]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   [RFC2002]  Perkins, C., Ed., "IP Mobility Support", RFC 2002,
+              DOI 10.17487/RFC2002, October 1996,
+              <http://www.rfc-editor.org/info/rfc2002>.
+
+   [RFC4838]  Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
+              R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
+              Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
+              April 2007, <http://www.rfc-editor.org/info/rfc4838>.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246,
+              DOI 10.17487/RFC5246, August 2008,
+              <http://www.rfc-editor.org/info/rfc5246>.
+
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
+              <http://www.rfc-editor.org/info/rfc5280>.
+
+   [RFC5944]  Perkins, C., Ed., "IP Mobility Support for IPv4, Revised",
+              RFC 5944, DOI 10.17487/RFC5944, November 2010,
+              <http://www.rfc-editor.org/info/rfc5944>.
+
+   [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>.
+
+   [RFC7696]  Housley, R., "Guidelines for Cryptographic Algorithm
+              Agility and Selecting Mandatory-to-Implement Algorithms",
+              BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
+              <http://www.rfc-editor.org/info/rfc7696>.
+
+   [SEEN]     Pentikousis, K., "In search of energy-efficient mobile
+              networking", Communications Magazine, IEEE vol. 48 no. 1,
+              pp. 95-103, DOI 10.1109/MCOM.2010.5394036, January 2010.
+
+
+
+
+
+
+
+
+Kutscher, et al.              Informational                    [Page 36]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   [VIDEO-STREAMING]
+              Westphal, C., Ed., Lederer, S., Posch, D., Timmerer, C.,
+              Azgin, A., Liu, S., Mueller, C., Detti, A., Corujo, D.,
+              Wang, J., Montpetit, M., Murray, N., Azgin, A., and S.
+              Liu, "Adaptive Video Streaming over ICN", Work in
+              Progress, draft-irtf-icnrg-videostreaming-08, April 2016.
+
+Acknowledgments
+
+   The authors would like to thank Georgios Karagiannis for providing
+   suggestions on QoS research challenges, Dimitri Papadimitriou for
+   feedback on the routing section, and Joerg Ott and Stephen Farrell
+   for reviewing the whole document.
+
+Authors' Addresses
+
+   Dirk Kutscher (editor)
+   NEC
+   Kurfuersten-Anlage 36
+   Heidelberg
+   Germany
+
+   Email: kutscher@neclab.eu
+
+
+   Suyong Eum
+   Osaka University, School of Information Science and Technology
+   1-5 Yamadaoka, Suita
+   Osaka  565-0871
+   Japan
+
+   Phone: +81-6-6879-4571
+   Email: suyong@ist.osaka-u.ac.jp
+
+
+   Kostas Pentikousis
+   Travelping
+   Koernerstr. 7-10
+   Berlin  10785
+   Germany
+
+   Email: k.pentikousis@travelping.com
+
+
+
+
+
+
+
+
+
+Kutscher, et al.              Informational                    [Page 37]
+
+RFC 7927                     ICN Challenges                    July 2016
+
+
+   Ioannis Psaras
+   University College London, Dept. of E.E.  Eng.
+   Torrington Place
+   London  WC1E 7JE
+   United Kingdom
+
+   Email: i.psaras@ucl.ac.uk
+
+
+   Daniel Corujo
+   Universidade de Aveiro
+   Instituto de Telecomunicacoes, Campus Universitario de Santiago
+   Aveiro  P-3810-193
+   Portugal
+
+   Email: dcorujo@av.it.pt
+
+
+   Damien Saucez
+   INRIA
+   2004 route des Lucioles - BP 93
+   Sophia Antipolis  06902 Cedex
+   France
+
+   Email: damien.saucez@inria.fr
+
+
+   Thomas C. Schmidt
+   HAW Hamburg
+   Berliner Tor 7
+   Hamburg  20099
+   Germany
+
+   Email: t.schmidt@haw-hamburg.de
+
+
+   Matthias Waehlisch
+   FU Berlin
+   Takustr. 9
+   Berlin  14195
+   Germany
+
+   Email: waehlisch@ieee.org
+
+
+
+
+
+
+
+
+Kutscher, et al.              Informational                    [Page 38]
+