doc: Add RFC documents

1 files changed, 952 insertions, 0 deletions

diff --git a/doc/rfc/rfc8884.txt b/doc/rfc/rfc8884.txt
new file mode 100644
index 0000000..abdbe85
--- /dev/null
+++ b/doc/rfc/rfc8884.txt
@@ -0,0 +1,952 @@
+
+
+
+
+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