Research Directions for Using Information-Centric Networking (ICN) in Disaster Scenarios
RFC 8884



Internet Research Task Force (IRTF)                           J. Seedorf
Request for Comments: 8884     HFT Stuttgart - Univ. of Applied Sciences
Category: Informational                                  M. Arumaithurai
ISSN: 2070-1721                                  University of Göttingen
                                                               A. Tagami
                                                      KDDI Research Inc.
                                                         K. Ramakrishnan
                                                University of California
                                                      N. Blefari Melazzi
                                                  University Tor Vergata
                                                            October 2020

 Research Directions for Using Information-Centric Networking (ICN) in
                           Disaster Scenarios

Abstract

   Information-Centric Networking (ICN) is a new paradigm where the
   network provides users with named content instead of communication
   channels between hosts.  This document outlines some research
   directions for ICN with respect to applying ICN approaches for coping
   with natural or human-generated, large-scale disasters.  This
   document is a product of the Information-Centric Networking Research
   Group (ICNRG).

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
   https://www.rfc-editor.org/info/rfc8884.

Copyright Notice

   Copyright (c) 2020 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
   (https://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.

Table of Contents

   1.  Introduction
   2.  Disaster Scenarios
   3.  Research Challenges and Benefits of ICN
     3.1.  High-Level Research Challenges
     3.2.  How ICN Can be Beneficial
     3.3.  ICN as Starting Point vs. Existing DTN Solutions
   4.  Use Cases and Requirements
   5.  ICN-Based Research Approaches and Open Research Challenges
     5.1.  Suggested ICN-Based Research Approaches
     5.2.  Open Research Challenges
   6.  Security Considerations
   7.  Conclusion
   8.  IANA Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Acknowledgment
   Authors' Addresses

1.  Introduction

   This document summarizes some research challenges for coping with
   natural or human-generated, large-scale disasters.  In particular,
   the document discusses potential research directions for applying
   Information-Centric Networking (ICN) to address these challenges.

   Research and standardization approaches exist (for instance, see the
   work and discussions in the concluded IRTF DTN Research Group [dtnrg]
   and in the IETF DTN Working Group [dtnwg]).  In addition, a published
   Experimental RFC in the IRTF Stream [RFC5050] discusses Delay-
   Tolerant Networking (DTN), which is a key necessity for communicating
   in the disaster scenarios we are considering in this document.
   'Disconnection tolerance' can thus be achieved with these existing
   DTN approaches.  However, while these approaches can provide
   independence from an existing communication infrastructure (which
   indeed may not work anymore after a disaster has happened), ICN
   offers key concepts, such as new naming schemes and innovative
   multicast communication, which together enable many essential
   (publish/subscribe-based) use cases for communication after a
   disaster (e.g., message prioritization, one-to-many delivery of
   messages, group communication among rescue teams, and the use cases
   discussed in Section 4).  One could add such features to existing DTN
   protocols and solutions; however, in this document, we explore the
   use of ICN as a starting point for building a communication
   architecture that supports (somewhat limited) communication
   capabilities after a disaster.  We discuss the relationship between
   the ICN approaches (for enabling communication after a disaster)
   discussed in this document with existing work from the DTN community
   in more depth in Section 3.3.

   'Emergency Support and Disaster Recovery' is also listed among the
   ICN Baseline Scenarios in [RFC7476] as a potential scenario that 'can
   be used as a base for the evaluation of different ICN approaches so
   that they can be tested and compared against each other while
   showcasing their own advantages' [RFC7476] . In this regard, this
   document complements [RFC7476] by investigating the use of ICN
   approaches for 'Emergency Support and Disaster Recovery' in depth and
   discussing the relationship to existing work in the DTN community.

   This document focuses on ICN-based approaches that can enable
   communication after a disaster.  These approaches reside mostly on
   the network layer.  Other solutions for 'Emergency Support and
   Disaster Recovery' (e.g., on the application layer) may complement
   the ICN-based networking approaches discussed in this document and
   expand the solution space for enabling communications among users
   after a disaster.  In fact, addressing the use cases explored in this
   document would require corresponding applications that would exploit
   the discussed ICN benefits on the network layer for users.  However,
   the discussion of applications or solutions outside of the network
   layer are outside the scope of this document.

   This document represents the consensus of the Information-Centric
   Networking Research Group (ICNRG); it is not an IETF product and it
   does not define a standard.  It has been reviewed extensively by the
   ICN Research Group (RG) members active in the specific areas of work
   covered by the document.

   Section 2 gives some examples of what can be considered a large-scale
   disaster and what the effects of such disasters on communication
   networks are.  Section 3 outlines why ICN can be beneficial in such
   scenarios and provides a high-level overview on corresponding
   research challenges.  Section 4 describes some concrete use cases and
   requirements for disaster scenarios.  In Section 5, some concrete
   ICN-based solutions approaches are outlined.

2.  Disaster Scenarios

   An enormous earthquake hit Northeastern Japan (Tohoku areas) on March
   11, 2011 and caused extensive damages, including blackouts, fires,
   tsunamis, and a nuclear crisis.  The lack of information and means of
   communication caused the isolation of several Japanese cities.  This
   impacted the safety and well-being of residents and affected rescue
   work, evacuation activities, and the supply chain for food and other
   essential items.  Even in the Tokyo area, which is 300 km away from
   the Tohoku area, more than 100,000 people became 'returner refugees'
   who could not reach their homes because they had no means of public
   transportation (the Japanese government has estimated that more than
   6.5 million people would become returner refugees if such a
   catastrophic disaster were to hit the Tokyo area).

   That earthquake in Japan also showed that the current network is
   vulnerable to disasters.  Mobile phones have become the lifelines for
   communication, including safety confirmation.  Besides (emergency)
   phone calls, services in mobile networks commonly being used after a
   disaster include network disaster SMS notifications (or SMS 'Cell
   Broadcast' [cellbroadcast]), available in most cellular networks.
   The aftermath of a disaster puts a high strain on available resources
   due to the need for communication by everyone.  Authorities, such as
   the president or prime minister, local authorities, police, fire
   brigades, and rescue and medical personnel, would like to inform the
   citizens of possible shelters, food, or even of impending danger.
   Relatives would like to communicate with each other and be informed
   about their well-being.  Affected citizens would like to make
   inquiries about food distribution centers and shelters or report
   trapped and missing people to the authorities.  Moreover, damage to
   communication equipment, in addition to the already existing heavy
   demand for communication, highlights the issue of fault tolerance and
   energy efficiency.

   Additionally, disasters caused by humans (i.e., disasters that are
   caused deliberately and willfully and have the element of human
   intent such as a terrorist attack) may need to be considered.  In
   such cases, the perpetrators could be actively harming the network by
   launching a denial-of-service attack or by monitoring the network
   passively to obtain information exchanged, even after the main
   disaster itself has taken place.  Unlike some natural disasters that
   are predictable to a small extent using weather forecasting
   technologies, may have a slower onset, and occur in known
   geographical regions and seasons, terrorist attacks almost always
   occur suddenly without any advance warning.  Nevertheless, there
   exist many commonalities between natural and human-induced disasters,
   particularly relating to response and recovery, communication, search
   and rescue, and coordination of volunteers.

   The timely dissemination of information generated and requested by
   all the affected parties during and in the immediate aftermath of a
   disaster is difficult to provide within the current context of global
   information aggregators (such as Google, Yahoo, Bing, etc.) that need
   to index the vast amounts of specialized information related to the
   disaster.  Specialized coverage of the situation and timely
   dissemination are key to successfully managing disaster situations.
   We believe that network infrastructure capabilities provided by
   Information-Centric Networks can be suitable, in conjunction with
   application and middleware assistance.

3.  Research Challenges and Benefits of ICN

3.1.  High-Level Research Challenges

   Given a disaster scenario as described in Section 2, on a high level,
   one can derive the following (incomplete) list of corresponding
   technical challenges:

   Enabling usage of functional parts of the infrastructure, even
   when these are disconnected from the rest of the network:
      Assuming that parts of the network infrastructure (i.e., cables/
      links, routers, mobile bases stations, etc.) are functional after
      a disaster has taken place, it is desirable to be able to continue
      using such components for communication as much as possible.  This
      is challenging when these components are disconnected from the
      backhaul, thus forming fragmented networks.  This is especially
      true for today's mobile networks, which are comprised of a
      centralized architecture, mandating connectivity to central
      entities (which are located in the core of the mobile network) for
      communication.  But also in fixed networks, access to a name
      resolution service is often necessary to access some given
      content.

   Decentralized authentication, content integrity, and trust:
      In mobile networks, users are authenticated via central entities.
      While special services important in a disaster scenario exist and
      may work without authentication (such as SMS 'Cell Broadcast'
      [cellbroadcast] or emergency calls), user-to-user (or user-to-
      authorities) communication is normally not possible without being
      authenticated via a central entity in the network.  In order to
      communicate in fragmented or disconnected parts of a mobile
      network, the challenge of decentralizing user authentication
      arises.  Independently of the network being fixed or mobile, data
      origin authentication and verifying the correctness of content
      retrieved from the network may be challenging when being 'offline'
      (e.g., potentially disconnected from content publishers as well as
      from servers of a security infrastructure, which can provide
      missing certificates in a certificate chain or up-to-date
      information on revoked keys/certificates).  As the network
      suddenly becomes fragmented or partitioned, trust models may shift
      accordingly to the change in authentication infrastructure being
      used (e.g., one may switch from a PKI to a web-of-trust model,
      such as Pretty Good Privacy (PGP)).  Note that blockchain-based
      approaches are, in most cases, likely not suitable for the
      disaster scenarios considered in this document, as the
      communication capabilities needed to find consensus for a new
      block as well as for retrieving blocks at nodes will presumably
      not be available (or too excessive for the remaining
      infrastructure) after a disaster.

   Delivering/obtaining information and traffic prioritization in
   congested networks:
      Due to broken cables, failed routers, etc., it is likely that the
      communication network has much less overall capacity for handling
      traffic in a disaster scenario.  Thus, significant congestion can
      be expected in parts of the infrastructure.  It is therefore a
      challenge to guarantee message delivery in such a scenario.  This
      is even more important because, in the case of a disaster
      aftermath, it may be crucial to deliver certain information to
      recipients (e.g., warnings to citizens) with higher priority than
      other content.

   Delay/disruption-tolerant approach:
      Fragmented networks make it difficult to support direct end-to-end
      communication with small or no delay.  However, communication in
      general and especially during a disaster can often tolerate some
      form of delay.  For example, in order to know if someone's
      relatives are safe or not, a corresponding emergency message need
      not necessarily be supported in an end-to-end manner but would
      also be helpful to the human recipient if it can be transported in
      a hop-by-hop fashion with some delay.  For these kinds of use
      cases, it is sufficient to improve communication resilience in
      order to deliver such important messages.

   Energy efficiency:
      Long-lasting power outages may lead to batteries of communication
      devices running out, so designing energy-efficient solutions is
      very important in order to maintain a usable communication
      infrastructure.

   Contextuality:
      Like any communication in general, disaster scenarios are
      inherently contextual.  Aspects of geography, the people affected,
      the rescue communities involved, the languages being used, and
      many other contextual aspects are highly relevant for an efficient
      realization of any rescue effort and, with it, the realization of
      the required communication.

3.2.  How ICN Can be Beneficial

   Several aspects of ICN make related approaches attractive candidates
   for addressing the challenges described in Section 3.1.  Below is an
   (incomplete) list of considerations why ICN approaches can be
   beneficial to address these challenges:

   Routing-by-name:
      ICN protocols natively route by named data objects and can
      identify objects by names, effectively moving the process of name
      resolution from the application layer to the network layer.  This
      functionality is very handy in a fragmented network where
      reference to location-based, fixed addresses may not work as a
      consequence of disruptions.  For instance, name resolution with
      ICN does not necessarily rely on the reachability of application-
      layer servers (e.g., DNS resolvers).  In highly decentralized
      scenarios (e.g., in infrastructureless, opportunistic
      environments), the ICN routing-by-name paradigm effectively may
      lead to a 'replication-by-name' approach, where content is
      replicated depending on its name.

   Integrity and authentication of named data objects:
      ICN is built around the concept of named data objects.  Several
      proposals exist for integrating the concept of 'self-certifying
      data' into a naming scheme (e.g., see [RFC6920]).  With such
      approaches, object integrity of data retrieved from the network
      can be verified without relying on a trusted third party or PKI.
      In addition, given that the correct object name is known, such
      schemes can also provide data origin authentication (for instance,
      see the usage example in Section 8.3 of [RFC6920]).

   Content-based access control:
      ICN promotes a data-centric communication model that naturally
      supports content-based security (e.g., allowing access to content
      only to a specific user or class of users).  In fact, in ICN, it
      is the content itself that is secured (encrypted), if desired,
      rather than the communication channel.  This functionality could
      facilitate trusted communications among peer users in isolated
      areas of the network where a direct communication channel may not
      always or continuously exist.

   Caching:
      Caching content along a delivery path is an inherent concept in
      ICN.  Caching helps in handling huge amounts of traffic and can
      help to avoid congestion in the network (e.g., congestion in
      backhaul links can be avoided by delivering content from caches at
      access nodes).

   Sessionless:
      ICN does not require full end-to-end connectivity.  This feature
      facilitates a seamless aggregation between a normal network and a
      fragmented network, which needs DTN-like message forwarding.

   Potential to run traditional IP-based services (IP-over-ICN):
      While ICN and DTN promote the development of novel applications
      that fully utilize the new capabilities of the ICN/DTN network,
      work in [Trossen2015] has shown that an ICN-enabled network can
      transport IP-based services, either directly at IP or even at HTTP
      level.  With this, IP- and ICN/DTN-based services can coexist,
      providing the necessary support of legacy applications to affected
      users while reaping any benefits from the native support for ICN
      in future applications.

   Opportunities for traffic engineering and traffic prioritization:
      ICN provides the possibility to perform traffic engineering based
      on the name of desired content.  This enables priority-based
      replication depending on the scope of a given message
      [Psaras2014].  In addition, as [Trossen2015], among others, have
      pointed out, the realization of ICN services and particularly of
      IP-based services on top of ICN provide further traffic
      engineering opportunities.  The latter not only relate to the
      utilization of cached content, as outlined before, but to the
      ability to flexibly adapt to route changes (important in
      unreliable infrastructure, such as in disaster scenarios),
      mobility support without anchor points (again, important when
      parts of the infrastructure are likely to fail), and the inherent
      support for multicast and multihoming delivery.

3.3.  ICN as Starting Point vs. Existing DTN Solutions

   There has been quite some work in the DTN (Delay-Tolerant Networking)
   community on disaster communication (for instance, see the work and
   discussions in the concluded IRTF DTN Research Group [dtnrg] and in
   the IETF DTN Working Group [dtnwg]).  However, most DTN work lacks
   important features, such as publish/subscribe (pub/sub) capabilities,
   caching, multicast delivery, and message prioritization based on
   content types, which are needed in the disaster scenarios we
   consider.  One could add such features to existing DTN protocols and
   solutions, and indeed individual proposals for adding such features
   to DTN protocols have been made (e.g., [Greifenberg2008] and
   [Yoneki2007] propose the use of a pub/sub-based multicast
   distribution infrastructure for DTN-based opportunistic networking
   environments).

   However, arguably ICN -- having these intrinsic properties (as also
   outlined above) -- makes a better starting point for building a
   communication architecture that works well before and after a
   disaster.  For a disaster-enhanced ICN system, this would imply the
   following advantages: a) ICN data mules would have built-in caches
   and can thus return content for interests straight on, b) requests do
   not necessarily need to be routed to a source (as with existing DTN
   protocols), instead any data mule or end user can in principle
   respond to an interest, c) built-in multicast delivery implies
   energy-efficient, large-scale spreading of important information that
   is crucial in disaster scenarios, and d) pub/sub extension for
   popular ICN implementations exist [COPSS2011], which are very
   suitable for efficient group communication in disasters and provide
   better reliability, timeliness, and scalability, as compared to
   existing pub/sub approaches in DTN [Greifenberg2008] [Yoneki2007] .

   Finally, most DTN routing algorithms have been solely designed for
   particular DTN scenarios.  By extending ICN approaches for DTN-like
   scenarios, one ensures that a solution works in regular (i.e., well-
   connected) settings just as well (which can be important in reality,
   where a routing algorithm should work before and after a disaster).
   It is thus reasonable to start with existing ICN approaches and
   extend them with the necessary features needed in disaster scenarios.
   In any case, solutions for disaster scenarios need a combination of
   ICN-features and DTN-capabilities.

4.  Use Cases and Requirements

   This section describes some use cases for the aforementioned disaster
   scenario (as outlined in Section 2) and discusses the corresponding
   technical requirements for enabling these use cases.

   Delivering Messages to Relatives/Friends:
      After a disaster strikes, citizens want to confirm to each other
      that they are safe.  For instance, shortly after a large disaster
      (e.g., an earthquake or a tornado), people have moved to different
      refugee shelters.  The mobile network is not fully recovered and
      is fragmented, but some base stations are functional.  This use
      case imposes the following high-level requirements: a) people must
      be able to communicate with others in the same network fragment
      and b) people must be able to communicate with others that are
      located in different fragmented parts of the overall network.
      More concretely, the following requirements are needed to enable
      the use case: a) a mechanism for a scalable message forwarding
      scheme that dynamically adapts to changing conditions in
      disconnected networks, b) DTN-like mechanisms for getting
      information from one disconnected island to another disconnected
      island, c) source authentication and content integrity so that
      users can confirm that the messages they receive are indeed from
      their relatives or friends and have not been tampered with, and d)
      the support for contextual caching in order to provide the right
      information to the right set of affected people in the most
      efficient manner.

   Spreading Crucial Information to Citizens:
      State authorities want to be able to convey important information
      (e.g., warnings or information on where to go or how to behave) to
      citizens.  These kinds of information shall reach as many citizens
      as possible, i.e., crucial content from legal authorities shall
      potentially reach all users in time.  The technical requirements
      that can be derived from this use case are a) source
      authentication and content integrity, such that citizens can
      confirm the correctness and authenticity of messages sent by
      authorities, b) mechanisms that guarantee the timeliness and loss-
      free delivery of such information, which may include techniques
      for prioritizing certain messages in the network depending on who
      sent them, and c) DTN-like mechanisms for getting information from
      disconnected island to another disconnected island.

   It can be observed that different key use cases for disaster
   scenarios imply overlapping and similar technical requirements for
   fulfilling them.  As discussed in Section 3.2, ICN approaches are
   envisioned to be very suitable for addressing these requirements with
   actual technical solutions.  In [Robitzsch2015], a more elaborate set
   of requirements is provided that addresses, among disaster scenarios,
   a communication infrastructure for communities facing several
   geographic, economic, and political challenges.

5.  ICN-Based Research Approaches and Open Research Challenges

   This section outlines some ICN-based research approaches that aim at
   fulfilling the previously mentioned use cases and requirements
   (Section 5.1).  Most of these works provide proof-of-concept type
   solutions, addressing singular challenges.  Thus, several open issues
   remain, which are summarized in Section 5.2.

5.1.  Suggested ICN-Based Research Approaches

   The research community has investigated ICN-based solutions to
   address the aforementioned challenges in disaster scenarios.
   Overall, the focus is on delivery of messages and not real-time
   communication.  While most users would probably like to conduct real-
   time voice/video calls after a disaster, in the extreme scenario we
   consider (with users being scattered over different fragmented
   networks as can be the case in the scenarios described in Section 2),
   somewhat delayed message delivery appears to be inevitable, and full-
   duplex real-time communication seems infeasible to achieve (unless
   users are in close proximity).  Thus, the assumption is that -- for a
   certain amount of time at least (i.e., the initial period until the
   regular communication infrastructure has been repaired) -- users
   would need to live with message delivery and publish/subscribe
   services but without real-time communication.  Note, however, that a)
   in principle, ICN can support Voice over IP (VoIP) calls; thus, if
   users are in close proximity, (duplex) voice communication via ICN is
   possible [Gusev2015], and b) delayed message delivery can very well
   include (recorded) voice messages.

   ICN 'data mules':
      To facilitate the exchange of messages between different network
      fragments, mobile entities can act as ICN 'data mules', which are
      equipped with storage space and move around the disaster-stricken
      area gathering information to be disseminated.  As the mules move
      around, they deliver messages to other individuals or points of
      attachment to different fragments of the network.  These 'data
      mules' could have a predetermined path (an ambulance going to and
      from a hospital), a fixed path (drone/robot assigned specifically
      to do so), or a completely random path (doctors moving from one
      camp to another).  An example of a many-to-many communication
      service for fragmented networks based on ICN data mules has been
      proposed in [Tagami2016].

   Priority-dependent or popularity-dependent, name-based
   replication:
      By allowing spatial and temporal scoping of named messages,
      priority-based replication depending on the scope of a given
      message is possible.  Clearly, spreading information in disaster
      cases involves space and time factors that have to be taken into
      account as messages spread.  A concrete approach for such scope-
      based prioritization of ICN messages in disasters, called 'NREP',
      has been proposed [Psaras2014], where ICN messages have
      attributes, such as user-defined priority, space, and temporal
      validity.  These attributes are then taken into account when
      prioritizing messages.  In [Psaras2014], evaluations show how this
      approach can be applied to the use case 'Delivering Messages to
      Relatives/Friends' described in Section 4.  In [Seedorf2016], a
      scheme is presented that enables estimating the popularity of ICN
      interest messages in a completely decentralized manner among data
      mules in a scenario with random, unpredictable movements of ICN
      data mules.  The approach exploits the use of nonces associated
      with end user requests, common in most ICN architectures.  It
      enables for a given ICN data mule to estimate the overall
      popularity (among end users) of a given ICN interest message.
      This enables data mules to optimize content dissemination with
      limited caching capabilities by prioritizing interests based on
      their popularity.

   Information resilience through decentralized forwarding:
      In a dynamic or disruptive environment, such as the aftermath of a
      disaster, both users and content servers may dynamically join and
      leave the network (due to mobility or network fragmentation).
      Thus, users might attach to the network and request content when
      the network is fragmented and the corresponding content origin is
      not reachable.  In order to increase information resilience,
      content cached both in in-network caches and in end-user devices
      should be exploited.  A concrete approach for the exploitation of
      content cached in user devices is presented in [Sourlas2015] . The
      proposal in [Sourlas2015] includes enhancements to the Named Data
      Networking (NDN) router design, as well as an alternative
      Interest-forwarding scheme that enables users to retrieve cached
      content when the network is fragmented and the content origin is
      not reachable.  Evaluations show that this approach is a valid
      tool for the retrieval of cached content in disruptive cases and
      can be applied to tackle the challenges presented in Section 3.1 .

   Energy efficiency:
      A large-scale disaster can cause a large-scale blackout; thus, a
      number of base stations (BSs) will be operated by their batteries.
      Capacities of such batteries are not large enough to provide
      cellular communication for several days after the disaster.  In
      order to prolong the batteries' life from one day to several days,
      different techniques need to be explored, including priority
      control, cell zooming, and collaborative upload.  Cell zooming
      switches off some of the BSs because switching off is the only way
      to reduce power consumed at the idle time.  In cell zooming, areas
      covered by such inactive BSs are covered by the active BSs.
      Collaborative communication is complementary to cell zooming and
      reduces power proportional to a load of a BS.  The load represents
      cellular frequency resources.  In collaborative communication, end
      devices delegate sending and receiving messages to and from a BS
      to a representative end device of which radio propagation quality
      is better.  The design of an ICN-based publish/subscribe protocol
      that incorporates collaborative upload is ongoing work.  In
      particular, the integration of collaborative upload techniques
      into the COPSS (Content Oriented Publish/Subscribe System)
      framework is envisioned [COPSS2011].

   Data-centric confidentiality and access control:
      In ICN, the requested content is no longer associated to a trusted
      server or an endpoint location, but it can be retrieved from any
      network cache or a replica server.  This calls for 'data-centric'
      security, where security relies on information exclusively
      contained in the message itself, or if extra information provided
      by trusted entities is needed, this should be gathered through
      offline, asynchronous, and noninteractive communication, rather
      than from an explicit online interactive handshake with trusted
      servers.  The ability to guarantee security without any online
      entities is particularly important in disaster scenarios with
      fragmented networks.  One concrete cryptographic technique is
      'Ciphertext-Policy Attribute Based Encryption (CP-ABE)', allowing
      a party to encrypt a content specifying a policy that consists in
      a Boolean expression over attributes that must be satisfied by
      those who want to decrypt such content.  Such encryption schemes
      tie confidentiality and access control to the transferred data,
      which can also be transmitted in an unsecured channel.  These
      schemes enable the source to specify the set of nodes allowed to
      later on decrypt the content during the encryption process.

   Decentralized authentication of messages:
      Self-certifying names provide the property that any entity in a
      distributed system can verify the binding between a corresponding
      public key and the self-certifying name without relying on a
      trusted third party.  Self-certifying names thus provide a
      decentralized form of data origin authentication.  However, self-
      certifying names lack a binding with a corresponding real-world
      identity.  Given the decentralized nature of a disaster scenario,
      a PKI-based approach for binding self-certifying names with real-
      world identities is not feasible.  Instead, a Web of Trust can be
      used to provide this binding.  Not only are the cryptographic
      signatures used within a Web of Trust independent of any central
      authority, but there are also technical means for making the
      inherent trust relationships of a Web of Trust available to
      network entities in a decentralized, 'offline' fashion, such that
      information received can be assessed based on these trust
      relationships.  A concrete scheme for such an approach has been
      published in [Seedorf2014], in which concrete examples for
      fulfilling the use case 'Delivering Messages to Relatives/Friends'
      with this approach are also given.

5.2.  Open Research Challenges

   The proposed solutions in Section 5.1 investigate how ICN approaches
   can, in principle, address some of the outlined challenges.  However,
   several research challenges remain open and still need to be
   addressed.  The following (incomplete) list summarizes some
   unanswered research questions and items that are being investigated
   by researchers:

   *  Evaluating the proposed mechanisms (and their scalability) in
      realistic, large-scale testbeds with actual, mature
      implementations (compared to simulations or emulations).

   *  To specify, for each mechanism suggested, what would be the user
      equipment required or necessary before and after a disaster and to
      what extent ICN should be deployed in the network.

   *  How can DTN and ICN approaches be best used for an optimal overall
      combination of techniques?

   *  How do data-centric encryption schemes scale and perform in large-
      scale, realistic evaluations?

   *  Building and testing real (i.e., not early-stage prototypes) ICN
      data mules by means of implementation and integration with lower-
      layer hardware; conducting evaluations of decentralized forwarding
      schemes in real environments with these actual ICN data mules.

   *  How to derive concrete, name-based policies allowing prioritized
      spreading of information.

   *  Further investigating, developing, and verifying of mechanisms
      that address energy efficiency requirements for communication
      after a disaster.

   *  How to properly disseminate authenticated object names to nodes
      (for decentralized integrity verification and authentication)
      before a disaster or how to retrieve new authenticated object
      names by nodes during a disaster.

6.  Security Considerations

   This document does not define a new protocol (or protocol extension)
   or a particular mechanism; therefore, it introduces no specific new
   security considerations.  General security considerations for ICN,
   which also apply when using ICN techniques to communicate after a
   disaster, are discussed in [RFC7945].

   The after-disaster communication scenario, which is the focus of this
   document, raises particular attention to decentralized
   authentication, content integrity, and trust as key research
   challenges (as outlined in Section 3.1).  The corresponding use cases
   and ICN-based research approaches discussed in this document thus
   imply certain security requirements.  In particular, data origin
   authentication, data integrity, and access control are key
   requirements for many use cases in the aftermath of a disaster (see
   Section 4).

   In principle, the kinds of disasters discussed in this document can
   happen as a result of a natural disaster, accident, or human error.
   However, intentional actions can also cause such a disaster (e.g., a
   terrorist attack, as mentioned in Section 2).  In this case (i.e.,
   intentionally caused disasters by attackers), special attention needs
   to be paid when re-enabling communications as temporary, somewhat
   unreliable communications with potential limited security features
   may be anticipated and abused by attackers (e.g., to circulate false
   messages to cause further intentional chaos among the human
   population, to leverage this less secure infrastructure to refine
   targeting, or to track the responses of security/police forces).
   Potential solutions on how to cope with intentionally caused
   disasters by attackers and on how to enable a secure communications
   infrastructure after an intentionally caused disaster are out of
   scope of this document.

   The use of data-centric security schemes, such as 'Ciphertext-Policy
   Attribute Based Encryption' (as mentioned in Section 5.1), which
   encrypt the data itself (and not the communication channel), in
   principle, allows for the transmission of such encrypted data over an
   unsecured channel.  However, metadata about the encrypted data being
   retrieved still arises.  Such metadata may disclose sensitive
   information to a network-based attacker, even if such an attacker
   cannot decrypt the content itself.

   This document has summarized research directions for addressing these
   challenges and requirements, such as efforts in data-centric
   confidentiality and access control, as well as recent works for
   decentralized authentication of messages in a disaster-struck
   networking infrastructure with nonfunctional routing links and
   limited communication capabilities (see Section 5).

7.  Conclusion

   This document has outlined some research directions for ICN with
   respect to applying ICN approaches for coping with natural or human-
   generated, large-scale disasters.  The document has described high-
   level research challenges for enabling communication after a disaster
   has happened, as well as a general rationale why ICN approaches could
   be beneficial to address these challenges.  Further, concrete use
   cases have been described and how these can be addressed with ICN-
   based approaches has been discussed.

   Finally, this document provides an overview of examples of existing
   ICN-based solutions that address the previously outlined research
   challenges.  These concrete solutions demonstrate that indeed the
   communication challenges in the aftermath of a disaster can be
   addressed with techniques that have ICN paradigms at their base,
   validating our overall reasoning.  However, further, more-detailed
   challenges exist, and more research is necessary in all areas
   discussed: efficient content distribution and routing in fragmented
   networks, traffic prioritization, security, and energy efficiency.
   An incomplete, high-level list of such open research challenges has
   concluded the document.

   In order to deploy ICN-based solutions for disaster-aftermath
   communication in actual mobile networks, standardized ICN baseline
   protocols are a must.  It is unlikely to expect all user equipment in
   a large-scale mobile network to be from the same vendor.  In this
   respect, the work being done in the IRTF ICNRG is very useful as it
   works toward standards for concrete ICN protocols that enable
   interoperability among solutions from different vendors.  These
   protocols -- currently being developed in the IRTF ICNRG as
   Experimental specifications in the IRTF Stream -- provide a good
   foundation for deploying ICN-based, disaster-aftermath communication
   and thereby address key use cases that arise in such situations (as
   outlined in this document).

8.  IANA Considerations

   This document has no IANA actions.

9.  References

9.1.  Normative References

   [RFC5050]  Scott, K. and S. Burleigh, "Bundle Protocol
              Specification", RFC 5050, DOI 10.17487/RFC5050, November
              2007, <https://www.rfc-editor.org/info/rfc5050>.

   [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,
              <https://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,
              <https://www.rfc-editor.org/info/rfc7476>.

   [RFC7945]  Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S.,
              and G. Boggia, "Information-Centric Networking: Evaluation
              and Security Considerations", RFC 7945,
              DOI 10.17487/RFC7945, September 2016,
              <https://www.rfc-editor.org/info/rfc7945>.

9.2.  Informative References

   [cellbroadcast]
              Wikipedia, "Cell Broadcast", August 2020,
              <https://en.wikipedia.org/w/
              index.php?title=Cell_Broadcast&oldid=972614007>.

   [COPSS2011]
              Chen, J., Arumaithurai, M., Jiao, L., Fu, X., and K.
              Ramakrishnan, "COPSS: An Efficient Content Oriented
              Publish/Subscribe System", Seventh ACM/IEEE Symposium on
              Architectures for Networking and Communications Systems
              (ANCS), DOI 10.1109/ANCS.2011.27, October 2011,
              <https://doi.org/10.1109/ANCS.2011.27>.

   [dtnrg]    IRTF, "Delay-Tolerant Networking Research Group (DTNRG)",
              <https://irtf.org/dtnrg>.

   [dtnwg]    IETF, "Delay/Disruption Tolerant Networking (dtn)",
              <https://datatracker.ietf.org/wg/dtn/about/>.

   [Greifenberg2008]
              Greifenberg, J. and D. Kutscher, "Efficient Publish/
              Subscribe-Based Multicast for Opportunistic Networking
              with Self-Organized Resource Utilization", Advanced
              Information Networking and Applications - Workshops,
              DOI 10.1109/WAINA.2008.255, March 2008,
              <https://doi.org/10.1109/WAINA.2008.255>.

   [Gusev2015]
              Gusev, P. and J. Burke, "NDN-RTC: Real-Time
              Videoconferencing over Named Data Networking", 2nd ACM
              Conference on Information-Centric Networking (ICN),
              DOI 10.1145/2810156.2810176, September 2015,
              <https://doi.org/10.1145/2810156.2810176>.

   [Psaras2014]
              Psaras, I., Saino, L., Arumaithurai, M., Ramakrishnan, K.,
              and G. Pavlou, "Name-based replication priorities in
              disaster cases", IEEE Conference on Computer
              Communications Workshops,
              DOI 10.1109/INFCOMW.2014.6849271, April 2014,
              <https://doi.org/10.1109/INFCOMW.2014.6849271>.

   [Robitzsch2015]
              Robitzsch, S., Trossen, D., Theodorou, C., Barker, T., and
              A. Sathiaseel, "D2.1: Usage Scenarios and Requirements",
              H2020 project RIFE, public deliverable.

   [Seedorf2014]
              Seedorf, J., Kutscher, D., and F. Schneider,
              "Decentralised binding of self-certifying names to real-
              world identities for assessment of third-party messages in
              fragmented mobile networks", IEEE Conference on Computer
              Communications Workshops,
              DOI 10.1109/INFCOMW.2014.6849268, April 2014,
              <https://doi.org/10.1109/INFCOMW.2014.6849268>.

   [Seedorf2016]
              Seedorf, J., Kutscher, D., and B. Gill, "Decentralised
              Interest Counter Aggregation for ICN in Disaster
              Scenarios", IEEE Globecom Workshops,
              DOI 10.1109/GLOCOMW.2016.7848869, December 2016,
              <https://doi.org/10.1109/GLOCOMW.2016.7848869>.

   [Sourlas2015]
              Sourlas, V., Tassiulas, L., Psaras, I., and G. Pavlou,
              "Information resilience through user-assisted caching in
              disruptive Content-Centric Networks", IFIP Networking
              Conference, DOI 10.1109/IFIPNetworking.2015.7145301, May
              2015,
              <https://doi.org/10.1109/IFIPNetworking.2015.7145301>.

   [Tagami2016]
              Tagami, A., Yagyu, T., Sugiyama, K., Arumaithurai, M.,
              Nakamura, K., Hasegawa, T., Asami, T., and K.
              Ramakrishnan, "Name-based push/pull message dissemination
              for disaster message board", IEEE International Symposium
              on Local and Metropolitan Area Networks (LANMAN),
              DOI 10.1109/LANMAN.2016.7548855, June 2016,
              <https://doi.org/10.1109/LANMAN.2016.7548855>.

   [Trossen2015]
              Trossen, D., Reed, M., Riihijärvi, J., Georgiades, M.,
              Fotiou, N., and G. Xylomenos, "IP over ICN - The better
              IP?", 2European Conference on Networks and Communications
              (EuCNC), DOI 10.1109/EuCNC.2015.7194109, June 2015,
              <https://doi.org/10.1109/EuCNC.2015.7194109>.

   [Yoneki2007]
              Yoneki, E., Hui, P., Chan, S., and J. Crowcroft, "A socio-
              aware overlay for publish/subscribe communication in delay
              tolerant networks", Proceedings of the 10th ACM Symposium
              on Modeling, Analysis, and Simulation of Wireless and
              Mobile Systems, DOI 10.1145/1298126.1298166, October 2007,
              <https://doi.org/10.1145/1298126.1298166>.

Acknowledgment

   The authors would like to thank Ioannis Psaras for useful comments.
   Also, the authors are grateful to Christopher Wood and Daniel Corujo
   for valuable feedback and suggestions on concrete text for improving
   the document.  Further, the authors would like to thank Joerg Ott and
   Dirk Trossen for valuable comments and input, in particular,
   regarding existing work from the DTN community that is highly related
   to the ICN approaches suggested in this document.  Also, Akbar Rahman
   provided useful comments and suggestions, in particular, regarding
   existing disaster warning mechanisms in today's mobile phone
   networks.

   This document has been supported by the GreenICN project (GreenICN:
   Architecture and Applications of Green Information-Centric
   Networking), a research project supported jointly by the European
   Commission under its 7th Framework Program (contract no. 608518) and
   the National Institute of Information and Communications Technology
   (NICT) in Japan (contract no. 167).  The views and conclusions
   contained herein are those of the authors and should not be
   interpreted as necessarily representing the official policies or
   endorsements, either expressed or implied, of the GreenICN project,
   the European Commission, or the NICT.  More information is available
   at the project website: http://www.greenicn.org/.

   This document has also been supported by the Coordination Support
   Action entitled 'Supporting European Experts Presence in
   International Standardisation Activities in ICT' (StandICT.eu
   (https://standict.eu/)) funded by the European Commission under the
   Horizon 2020 Programme with Grant Agreement no. 780439.  The views
   and conclusions contained herein are those of the authors and should
   not be interpreted as necessarily representing the official policies
   or endorsements, either expressed or implied, of the European
   Commission.

Authors' Addresses

   Jan Seedorf
   HFT Stuttgart - Univ. of Applied Sciences
   Schellingstrasse 24
   70174 Stuttgart
   Germany

   Phone: +49 711 8926 2801
   Email: jan.seedorf@hft-stuttgart.de

   Mayutan Arumaithurai
   University of Göttingen
   Goldschmidt Str. 7
   37077 Göttingen
   Germany

   Phone: +49 551 39 172046
   Email: arumaithurai@informatik.uni-goettingen.de

   Atsushi Tagami
   KDDI Research Inc.
   2-1-15 Ohara, Fujimino, Saitama
   356-85025
   Japan

   Phone: +81 49 278 73651
   Email: tagami@kddi-research.jp

   K. K. Ramakrishnan
   University of California
   Riverside,  CA
   United States of America

   Email: kkrama@ucr.edu

   Nicola Blefari Melazzi
   University Tor Vergata
   Via del Politecnico, 1
   00133 Roma
   Italy

   Phone: +39 06 7259 7501
   Email: blefari@uniroma2.it