rfc8884xml2.original.xml		rfc8884.xml
			<?xml version='1.0' encoding='utf-8'?>
			<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
			<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info"
			docName="draft-irtf-icnrg-disaster-10" ipr="trust200902" obsoletes=""
			updates="" submissionType="IRTF" xml:lang="en" tocInclude="true"
			symRefs="true" sortRefs="true" version="3" number="8884" consensus="true">
			<front>
			<title abbrev="ICN in Disaster Scenarios">Research Directions for Using
			Information-Centric Networking (ICN) in Disaster Scenarios</title>
			<seriesInfo name="RFC" value="8884"/>
			<author fullname="Jan Seedorf" initials="J." surname="Seedorf">
			<organization abbrev="HFT Stuttgart - Univ. of Applied Sciences">HFT
			Stuttgart - Univ. of Applied Sciences</organization>
			<address>
			<postal>
			<street>Schellingstrasse 24</street>
			<code>70174</code>
			<city>Stuttgart</city>
			<country>Germany</country>
			</postal>
			<phone>+49 711 8926 2801</phone>
			<email>jan.seedorf@hft-stuttgart.de</email>
			</address>
			</author>
			<author fullname="Mayutan Arumaithurai" initials="M." surname="Arumaithurai"
			>
			<organization>University of Göttingen
			</organization>
			<address>
			<postal>
			<street>Goldschmidt Str. 7</street>
			<code>37077</code>
			<city>Göttingen
			</city>
			<country>Germany</country>
			</postal>
			<phone>+49 551 39 172046</phone>
			<email>arumaithurai@informatik.uni-goettingen.de</email>
			</address>
			</author>
			<author initials="A." surname="Tagami" fullname="Atsushi Tagami">
			<organization>KDDI Research Inc.</organization>
			<address>
			<postal>
			<street>2-1-15 Ohara, Fujimino</street>
			<code>356-85025</code>
			<region>Saitama</region>
			<country>Japan</country>
			</postal>
			<phone>+81 49 278 73651</phone>
			<email>tagami@kddi-research.jp</email>
			</address>
			</author>
			<author initials="K." surname="Ramakrishnan" fullname="K. K. Ramakrishnan">
			<organization>University of California</organization>
			<address>
			<postal>
			<street/>
			<city>Riverside</city>
			<code>CA</code>
			<country>United States of America</country>
			</postal>
			<email>kkrama@ucr.edu</email>
			</address>
			</author>
			<author initials="N." surname="Blefari Melazzi" fullname="Nicola Blefari Mel
			azzi">
			<organization>University Tor Vergata</organization>
			<address>
			<postal>
			<street>Via del Politecnico, 1</street>
			<city>Roma</city>
			<code>00133</code>
			<country>Italy</country>
			</postal>
			<phone>+39 06 7259 7501</phone>
			<email>blefari@uniroma2.it</email>
			</address>
			</author>
			<date month="October" year="2020"/>
			<area>IRTF</area>
			<workgroup>Information-Centric Networking</workgroup>
			<keyword>ICN</keyword>
			<abstract>
			<t>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).
			</t>
			</abstract>
			</front>
			<middle>
			<section numbered="true" toc="default">
			<name>Introduction</name>
			<t>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.
			</t>
			<t>
			Research and standardization approaches exist (for instance, see the work
			and discussions in the concluded IRTF DTN Research Group <xref
			target="dtnrg" format="default"/> and in the IETF DTN Working Group <xref
			target="dtnwg" format="default"/>). In addition, a published Experimental
			RFC in the IRTF Stream <xref target="RFC5050" format="default"/> 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 <xref target="usecases"
			format="default"/>). 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 <xref target="researchgap" format="default"/>.</t>
			<t>'Emergency Support and Disaster Recovery' is also listed among the
			ICN Baseline Scenarios in <xref target="RFC7476" format="default"/> 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' <xref target="RFC7476" format="default"/> . In this regard,
			this document complements <xref target="RFC7476" format="default"/> 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.
			</t>
			<t>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.
			</t>
			<t>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.
			</t>
			<t><xref target="disaster" format="default"/> gives some examples of
			what can be considered a large-scale disaster and what the effects of
			such disasters on communication networks are. <xref target="whyicn"
			format="default"/> outlines why ICN can be beneficial in such scenarios
			and provides a high-level overview on corresponding research
			challenges. <xref target="usecases" format="default"/> describes some
			concrete use cases and requirements for disaster scenarios. In <xref
			target="solutions" format="default"/>, some concrete ICN-based solutions
			approaches are outlined.
			</t>
			</section>
			<section anchor="disaster" numbered="true" toc="default">
			<name>Disaster Scenarios</name>
			<t>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).
			</t>
			<t>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'
			<xref target="cellbroadcast" format="default"/>), 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 trap
			ped
			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.
			</t>
			<t>Additionally, disasters caused by humans (i.e., disasters that are caus
			ed deliberately
			and willfully and have the element of human intent such as a terrorist att
			ack)
			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.
			</t>
			<t> 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.
			</t>
			</section>
			<section anchor="whyicn" numbered="true" toc="default">
			<name>Research Challenges and Benefits of ICN</name>
			<section anchor="challenges" numbered="true" toc="default">
			<name>High-Level Research Challenges</name>
			<t>Given a disaster scenario as described in <xref target="disaster"
			format="default"/>, on a high level, one can derive the following
			(incomplete) list of corresponding technical challenges:
			</t>
			<dl newline="true" spacing="normal">
			<dt>Enabling usage of functional parts of the infrastructure, even
			when these are disconnected from the rest of the network:</dt>
			<dd>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.</dd>
			<dt>Decentralized authentication, content integrity, and trust:</dt>
			<dd>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' <xref
			target="cellbroadcast" format="default"/> 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 ar
			e, 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.</dd >
			<dt>Delivering/obtaining information and traffic prioritization in
			congested networks: </dt>
			<dd>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 disaste
			r
			aftermath, it may be crucial to deliver certain information to
			recipients (e.g., warnings to citizens) with higher priority than
			other content.</dd>
			<dt>Delay/disruption-tolerant approach:</dt>
			<dd>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 t
			o
			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. </dd>
			<dt>Energy efficiency:</dt>
			<dd>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.</dd>
			<dt>Contextuality:</dt>
			<dd>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.</dd>
			</dl>
			</section>
			<section anchor="howicncanhelp" numbered="true" toc="default">
			<name>How ICN Can be Beneficial</name>
			<t>Several aspects of ICN make related approaches attractive
			candidates for addressing the challenges described in <xref
			target="challenges" format="default"/>. Below is an (incomplete) list
			of considerations why ICN approaches can be beneficial to address
			these challenges:</t>
			<dl newline="true" spacing="normal">
			<dt>Routing-by-name:</dt>
			<dd>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.</dd>
			<dt>Integrity and authentication of named data objects:</dt>
			<dd>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 <xref target="RFC6920" format="default"/>). 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 <xref target="RFC6920" sectionFormat="of" section="8.3"/>).
			</dd>
			<dt>Content-based access control:</dt>
			<dd>
			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 tha
			n 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.</dd>
			<dt>Caching:</dt>
			<dd>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).</dd>
			<dt>Sessionless:</dt>
			<dd>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.</dd>
			<dt>Potential to run traditional IP-based services (IP-over-ICN):</dt>
			<dd>While ICN and DTN promote the development of novel applications tha
			t
			fully utilize the new capabilities of the ICN/DTN network, work in
			<xref target="Trossen2015" format="default"/> 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.</dd>
			<dt>Opportunities for traffic engineering and traffic
			prioritization:</dt>
			<dd>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
			<xref target="Psaras2014" format="default"/>. In addition, as <xref
			target="Trossen2015" format="default"/>, 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.</dd>
			</dl>
			</section>
			<section anchor="researchgap" numbered="true" toc="default">
			<name>ICN as Starting Point vs. Existing DTN Solutions</name>
			<t>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 <xref target="dtnrg" format="default"/> and in the IETF DTN
			Working Group <xref target="dtnwg" format="default"/>). 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., <xref target="Greifenberg2008"
			format="default"/> and <xref target="Yoneki2007" format="default"/>
			propose the use of a pub/sub-based multicast distribution
			infrastructure for DTN-based opportunistic networking
			environments).</t>
			<t>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 <xref target="COPSS2011" format="default"/>,
			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 <xref target="Greifenberg2008"
			format="default"/> <xref target="Yoneki2007" format="default"/> .</t>
			<t>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.</t>
			</section>
			</section>
			<section anchor="usecases" numbered="true" toc="default">
			<name>Use Cases and Requirements</name>
			<t>This section describes some use cases for the aforementioned disaster
			scenario (as outlined in <xref target="disaster" format="default"/>) and
			discusses the corresponding technical requirements for enabling these
			use cases.</t>
			<dl newline="true" spacing="normal">
			<dt>Delivering Messages to Relatives/Friends:</dt>
			<dd><t>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 mobi
			le
			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.</t></dd>
			<dt>Spreading Crucial Information to Citizens:</dt>
			<dd>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.</dd>
			</dl>
			<t>It can be observed that different key use cases for disaster
			scenarios imply overlapping and similar technical requirements for
			fulfilling them. As discussed in <xref target="howicncanhelp"
			format="default"/>, ICN approaches are envisioned to be very suitable
			for addressing these requirements with actual technical solutions. In
			<xref target="Robitzsch2015" format="default"/>, 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.</t>
			</section>
			<section anchor="solutions" numbered="true" toc="default">
			<name>ICN-Based Research Approaches and Open Research Challenges</name>
			<t>This section outlines some ICN-based research approaches that aim at
			fulfilling the previously mentioned use cases and requirements (<xref
			target="suggested" format="default"/>). Most of these works provide
			proof-of-concept type solutions, addressing singular challenges. Thus,
			several open issues remain, which are summarized in <xref target="open"
			format="default"/>.</t>
			<section anchor="suggested" numbered="true" toc="default">
			<name>Suggested ICN-Based Research Approaches</name>
			<t>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 <xref target="disaster"
			format="default"/>), 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 <xref
			target="Gusev2015" format="default"/>, and b) delayed message delivery
			can very well include (recorded) voice messages.</t>
			<dl newline="true" spacing="normal">
			<dt>ICN 'data mules':</dt>
			<dd>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 <xref target="Tagami2016"
			format="default"/>.</dd>
			<dt>Priority-dependent or popularity-dependent, name-based
			replication:</dt>
			<dd>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 <xref target="Psaras2014"
			format="default"/>, 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 <xref target="Psaras2014" format="default"/>,
			evaluations show how this approach can be applied to the use case
			'Delivering Messages to Relatives/Friends' described in <xref
			target="usecases" format="default"/>. In <xref target="Seedorf2016"
			format="default"/>, 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.</dd>
			<dt>Information resilience through decentralized forwarding:</dt>
			<dd>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 <xref target="Sourlas2015"
			format="default"/> . The proposal in <xref target="Sourlas2015"
			format="default"/> 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 <xref target="challenges" format="default"/> .</dd>
			<dt>Energy efficiency:</dt>
			<dd>
			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 <xref target="COPSS2011"
			format="default"/>.</dd>
			<dt>Data-centric confidentiality and access control:</dt>
			<dd>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.</dd>
			<dt>Decentralized authentication of messages:</dt>
			<dd>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 <xref target="Seedorf2014"
			format="default"/>, in which concrete examples for fulfilling the
			use case 'Delivering Messages to Relatives/Friends' with this
			approach are also given.</dd>
			</dl>
			</section>
			<section anchor="open" numbered="true" toc="default">
			<name>Open Research Challenges</name>
			<t>The proposed solutions in <xref target="suggested"
			format="default"/> 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:</t>
			<ul spacing="normal">
			<li>Evaluating the proposed mechanisms (and their scalability) in
			realistic, large-scale testbeds with actual, mature implementations
			(compared to simulations or emulations).</li>
			<li>
			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.
			</li>
			<li>How can DTN and ICN approaches be best used for an optimal overall
			combination of techniques?</li>
			<li>How do data-centric encryption schemes scale and perform in
			large-scale, realistic evaluations?</li>
			<li>Building and testing real (i.e., not early-stage prototypes) ICN d
			ata
			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.</li>
			<li>How to derive concrete, name-based policies allowing prioritized
			spreading of information.
			</li>
			<li>Further investigating, developing, and verifying of mechanisms tha
			t address
			energy efficiency requirements for communication after a
			disaster.</li>
			<li>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.</li>
			</ul>
			</section>
			</section>
			<section anchor="security" numbered="true" toc="default">
			<name>Security Considerations</name>
			<t>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 <xref target="RFC7945" format="default"/>.</t>
			<t>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
			<xref target="challenges" format="default"/>). 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 <xref
			target="usecases" format="default"/>).</t>
			<t>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 <xref target="disaster"
			format="default"/>). 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.</t>
			<t>The use of data-centric security schemes, such as 'Ciphertext-Policy
			Attribute Based Encryption' (as mentioned in <xref target="suggested"
			format="default"/>), 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 disclos
			e
			sensitive information to a network-based attacker, even if such an
			attacker cannot decrypt the content itself.</t>
			<t>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 <xref target="solutions"
			format="default"/>).</t>
			</section>
			<section anchor="conclusion" numbered="true" toc="default">
			<name>Conclusion</name>
			<t>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.</t>
			<t>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.</t>
			<t>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).</t>
			</section>
			<section anchor="iana" numbered="true" toc="default">
			<name>IANA Considerations</name>
			<t>This document has no IANA actions.</t>
			</section>
			</middle>
			<back>
			<references>
			<name>References</name>
			<references>
			<name>Normative References</name>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.6920.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.5050.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.7476.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.7945.xml"/>
			</references>
			<references>
			<name>Informative References</name>
			<reference anchor="Psaras2014">
			<front>
			<title>Name-based replication priorities in disaster cases
			</title>
			<author fullname="Ioannis Psaras" initials="I." surname="Psaras">
			<organization/>
			</author>
			<author fullname="Lorenzo Saino" initials="L." surname="Saino">
			<organization/>
			</author>
			<author fullname="Mayutan Arumaithurai" initials="M." surname="Aruma
			ithurai">
			<organization/>
			</author>
			<author fullname="K.K. Ramakrishnan" initials="K." surname="Ramakris
			hnan">
			<organization/>
			</author>
			<author fullname="George Pavlou" initials="G." surname="Pavlou">
			<organization/>
			</author>
			<date month="April" year="2014"/>
			</front>
			<seriesInfo name="DOI" value="10.1109/INFCOMW.2014.6849271"/>
			<refcontent>IEEE Conference on Computer Communications Workshops</re
			fcontent>
			</reference>
			<reference anchor="cellbroadcast" target="https://en.wikipedia.org/w/ind
			ex.php?title=Cell_Broadcast&amp;oldid=972614007">
			<front>
			<title>Cell Broadcast</title>
			<author>
			<organization>Wikipedia</organization>
			</author>
			<date month="August" year="2020"></date>
			</front>
			</reference>
			<reference anchor="Seedorf2014">
			<front>
			<title>Decentralised binding of self-certifying names to
			real-world identities for assessment of third-party messages in
			fragmented mobile networks</title>
			<author fullname="Jan Seedorf" initials="J." surname="Seedorf">
			<organization/>
			</author>
			<author fullname="Dirk Kutscher" initials="D." surname="Kutscher">
			<organization/>
			</author>
			<author fullname="Fabian Schneider" initials="F." surname="Schneider
			">
			<organization/>
			</author>
			<date month="April" year="2014"/>
			</front>
			<seriesInfo name="DOI" value="10.1109/INFCOMW.2014.6849268"/>
			<refcontent>IEEE Conference on Computer Communications Workshops</refc
			ontent>
			</reference>
			<reference anchor="Seedorf2016">
			<front>
			<title>Decentralised Interest Counter Aggregation for ICN in Disaste
			r Scenarios
			</title>
			<author fullname="Jan Seedorf" initials="J." surname="Seedorf">
			<organization/>
			</author>
			<author fullname="Dirk Kutscher" initials="D." surname="Kutscher">
			<organization/>
			</author>
			<author fullname="Bilal Gill" initials="B." surname="Gill">
			<organization/>
			</author>
			<date month="December" year="2016"/>
			</front>
			<seriesInfo name="DOI" value="10.1109/GLOCOMW.2016.7848869"/>
			<refcontent>IEEE Globecom Workshops</refcontent>
			</reference>
			<reference anchor="COPSS2011">
			<front>
			<title>COPSS: An Efficient Content Oriented Publish/Subscribe System
			</title>
			<author fullname="Jiachen Chen" initials="J." surname="Chen">
			<organization/>
			</author>
			<author fullname="Mayutan Arumaithurai" initials="M." surname="Aruma
			ithurai">
			<organization/>
			</author>
			<author fullname="Lei Jiao" initials="L." surname="Jiao">
			<organization/>
			</author>
			<author fullname="Xiaoming Fu" initials="X." surname="Fu">
			<organization/>
			</author>
			<author fullname="K.K. Ramakrishnan" initials="K." surname="Ramakris
			hnan">
			<organization/>
			</author>
			<date month="October" year="2011"/>
			</front>
			<seriesInfo name="DOI" value="10.1109/ANCS.2011.27"/>
			<refcontent>Seventh ACM/IEEE Symposium on Architectures for
			Networking and Communications Systems (ANCS)</refcontent>
			</reference>
			<reference anchor="dtnwg" target="https://datatracker.ietf.org/wg/dtn/ab
			out/">
			<front>
			<title>Delay/Disruption Tolerant Networking (dtn)
			</title>
			<author>
			<organization>IETF</organization>
			</author>
			</front>
			</reference>
			<reference anchor="dtnrg" target="https://irtf.org/dtnrg">
			<front>
			<title>Delay-Tolerant Networking Research Group (DTNRG)
			</title>
			<author>
			<organization>IRTF</organization>
			</author>
			</front>
			</reference>
			<reference anchor="Robitzsch2015">
			<front>
			<title>D2.1: Usage Scenarios and Requirements</title>
			<author fullname="S Robitzsch" initials="S." surname="Robitzsch">
			<organization/>
			</author>
			<author fullname="Dirk Trossen" initials="D." surname="Trossen">
			<organization/>
			</author>
			<author fullname="Charalambos Theodorou" initials="C." surname="Theo
			dorou">
			<organization/>
			</author>
			<author fullname="Trevor Barker" initials="T." surname="Barker">
			<organization/>
			</author>
			<author fullname="Arjuna Sathiaseel" initials="A." surname="Sathiase
			el">
			<organization/>
			</author>
			<date/>
			</front>
			<refcontent>H2020 project RIFE, public deliverable</refcontent>
			</reference>
			<reference anchor="Tagami2016">
			<front>
			<title>Name-based push/pull message dissemination for disaster messa
			ge board
			</title>
			<author fullname="Atsushi Tagami" initials="A." surname="Tagami">
			<organization/>
			</author>
			<author fullname="Tomohiko Yagyu" initials="T." surname="Yagyu">
			<organization/>
			</author>
			<author fullname="Kohei Sugiyama" initials="K." surname="Sugiyama">
			<organization/>
			</author>
			<author fullname="Mayutan Arumaithurai" initials="M." surname="Aruma
			ithurai">
			<organization/>
			</author>
			<author fullname="Kenichi Nakamura" initials="K." surname="Nakamura"
			>
			<organization/>
			</author>
			<author fullname="Toru Hasegawa" initials="T." surname="Hasegawa">
			<organization/>
			</author>
			<author fullname="Tohru Asami" initials="T." surname="Asami">
			<organization/>
			</author>
			<author fullname="K. K. Ramakrishnan" initials="K." surname="Ramakri
			shnan">
			<organization/>
			</author>
			<date month="June" year="2016"/>
			</front>
			<seriesInfo name="DOI" value="10.1109/LANMAN.2016.7548855"/>
			<refcontent>IEEE International Symposium on Local and
			Metropolitan Area Networks (LANMAN)</refcontent>
			</reference>
			<reference anchor="Yoneki2007">
			<front>
			<title>A socio-aware overlay for publish/subscribe communication
			in delay tolerant networks</title>
			<author fullname="Eiko Yoneki" initials="E." surname="Yoneki">
			<organization/>
			</author>
			<author fullname="Pan Hui" initials="P." surname="Hui">
			<organization/>
			</author>
			<author fullname="ShuYan Chan" initials="S." surname="Chan">
			<organization/>
			</author>
			<author fullname="Jon Crowcroft" initials="J." surname="Crowcroft">
			<organization/>
			</author>
			<date month="October" year="2007"/>
			</front>
			<seriesInfo name="DOI" value="10.1145/1298126.1298166"/>
			<refcontent>Proceedings of the 10th ACM Symposium on Modeling,
			Analysis, and Simulation of Wireless and Mobile
			Systems</refcontent>
			</reference>
			<reference anchor="Greifenberg2008">
			<front>
			<title>Efficient Publish/Subscribe-Based Multicast for
			Opportunistic Networking with Self-Organized Resource Utilization
			</title>
			<author fullname="J Greifenberg" initials="J." surname="Greifenberg"
			>
			<organization/>
			</author>
			<author fullname="Dirk Kutscher" initials="D." surname="Kutscher">
			<organization/>
			</author>
			<date month="March" year="2008"/>
			</front>
			<seriesInfo name="DOI" value="10.1109/WAINA.2008.255"/>
			<refcontent>Advanced Information Networking and Applications - Worksho
			ps</refcontent>
			</reference>
			<reference anchor="Gusev2015">
			<front>
			<title>NDN-RTC: Real-Time Videoconferencing over Named Data Networki
			ng
			</title>
			<author fullname="Peter Gusev" initials="P." surname="Gusev">
			<organization/>
			</author>
			<author fullname="Jeff Burke" initials="J." surname="Burke">
			<organization/>
			</author>
			<date month="September" year="2015"/>
			</front>
			<seriesInfo name="DOI" value="10.1145/2810156.2810176"/>
			<refcontent>2nd ACM Conference on Information-Centric Networking
			(ICN)</refcontent>
			</reference>
			<reference anchor="Sourlas2015">
			<front>
			<title>Information resilience through user-assisted caching in
			disruptive Content-Centric Networks</title>
			<author fullname="Vasilis Sourlas" initials="V." surname="Sourlas">
			<organization/>
			</author>
			<author fullname="Leandros Tassiulas" initials="L." surname="Tassiul
			as">
			<organization/>
			</author>
			<author fullname="Ioannis Psaras" initials="I." surname="Psaras">
			<organization/>
			</author>
			<author fullname="George Pavlou" initials="G." surname="Pavlou">
			<organization/>
			</author>
			<date month="May" year="2015"/>
			</front>
			<seriesInfo name="DOI" value="10.1109/IFIPNetworking.2015.7145301"/>
			<refcontent>IFIP Networking Conference</refcontent>
			</reference>
			<reference anchor="Trossen2015">
			<front>
			<title>IP over ICN - The better IP?</title>
			<author fullname="Dirk Trossen" initials="D." surname="Trossen">
			<organization/>
			</author>
			<author fullname="Martin J. Reed " initials="M." surname="Reed">
			<organization/>
			</author>
			<author fullname="Janne Riihijärvi " initials="J." surname="Riihijär
			vi">
			<organization/>
			</author>
			<author fullname="Michael Georgiades" initials="M." surname="Georgia
			des">
			<organization/>
			</author>
			<author fullname="Nikos Fotiou" initials="N." surname="Fotiou">
			<organization/>
			</author>
			<author fullname="George Xylomenos" initials="G." surname="Xylomenos
			">
			<organization/>
			</author>
			<date month="June" year="2015"/>
			</front>
			<seriesInfo name="DOI" value="10.1109/EuCNC.2015.7194109"/>
			<refcontent>2European Conference on Networks and Communications
			(EuCNC)</refcontent>
			</reference>
			</references>
			</references>
			<section numbered="false" toc="default">
			<name>Acknowledgment</name>
			<t>The authors would like to thank <contact fullname="Ioannis Psaras"/>
			for useful comments. Also, the authors are grateful to <contact
			fullname="Christopher Wood"/> and <contact fullname="Daniel Corujo"/>
			for valuable feedback and suggestions on concrete text for
			improving the document. Further, the authors would like to thank
			<contact fullname="Joerg Ott"/> and <contact fullname="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, <contact
			fullname="Akbar Rahman"/>
			provided useful comments and suggestions, in particular, regarding
			existing disaster warning mechanisms in today's mobile phone
			networks.</t>
			<t>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 informati
			on
			is available at the project website: <eref
			target="http://www.greenicn.org/"/>. </t>
			<t>This document has also been supported by the Coordination Support
			Action entitled 'Supporting European Experts Presence in International
			Standardisation Activities in ICT' (<eref
			target="https://standict.eu/">StandICT.eu</eref>) funded by the European C
			ommission 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.</t>
			</section>
			</back>
			</rfc>
End of changes. 1 change blocks.
	lines changed or deleted		lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/