Research Directions for Using Information-Centric Networking (ICN) in Disaster ScenariosHFT Stuttgart - Univ. of Applied SciencesSchellingstrasse 2470174StuttgartGermany+49 711 8926 2801jan.seedorf@hft-stuttgart.deUniversity of GöttingenGoldschmidt Str. 737077Göttingen
Germany+49 551 39 172046arumaithurai@informatik.uni-goettingen.deKDDI Research Inc.2-1-15 Ohara, Fujimino356-85025SaitamaJapan+81 49 278 73651tagami@kddi-research.jpUniversity of CaliforniaRiversideCAUnited States of Americakkrama@ucr.eduUniversity Tor VergataVia del Politecnico, 1Roma00133Italy+39 06 7259 7501blefari@uniroma2.it
IRTF
Information-Centric NetworkingICNInformation-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
.
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
() 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
. Introduction
. Disaster Scenarios
. Research Challenges and Benefits of ICN
. High-Level Research Challenges
. How ICN Can be Beneficial
. ICN as Starting Point vs. Existing DTN Solutions
. Use Cases and Requirements
. ICN-Based Research Approaches and Open Research Challenges
. Suggested ICN-Based Research Approaches
. Open Research Challenges
. Security Considerations
. Conclusion
. IANA Considerations
. References
. Normative References
. Informative References
Acknowledgment
Authors' Addresses
IntroductionThis 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 and in the IETF DTN Working Group ). In addition, a published Experimental
RFC in the IRTF Stream 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 ). 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 .'Emergency Support and Disaster Recovery' is also listed among the
ICN Baseline Scenarios in 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' . In this regard,
this document complements 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.
gives some examples of
what can be considered a large-scale disaster and what the effects of
such disasters on communication networks are. outlines why ICN can be beneficial in such scenarios
and provides a high-level overview on corresponding research
challenges. describes some
concrete use cases and requirements for disaster scenarios. In , some concrete ICN-based solutions
approaches are outlined.
Disaster ScenariosAn 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'
), 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.
Research Challenges and Benefits of ICNHigh-Level Research ChallengesGiven a disaster scenario as described in , 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' 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.
How ICN Can be BeneficialSeveral aspects of ICN make related approaches attractive
candidates for addressing the challenges described in . 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 ). 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 ).
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
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
. In addition, as , 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.
ICN as Starting Point vs. Existing DTN SolutionsThere 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 and in the IETF DTN
Working Group ). 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., and
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 ,
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 .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.Use Cases and RequirementsThis section describes some use cases for the aforementioned disaster
scenario (as outlined in ) 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 , ICN approaches are envisioned to be very suitable
for addressing these requirements with actual technical solutions. In
, 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.ICN-Based Research Approaches and Open Research ChallengesThis section outlines some ICN-based research approaches that aim at
fulfilling the previously mentioned use cases and requirements (). Most of these works provide
proof-of-concept type solutions, addressing singular challenges. Thus,
several open issues remain, which are summarized in .Suggested ICN-Based Research ApproachesThe 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 ), 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 , 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 .
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 , 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 ,
evaluations show how this approach can be applied to the use case
'Delivering Messages to Relatives/Friends' described in . In , 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 . The proposal in 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 .
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 .
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 , in which concrete examples for fulfilling the
use case 'Delivering Messages to Relatives/Friends' with this
approach are also given.
Open Research ChallengesThe proposed solutions in 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.
Security ConsiderationsThis 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 .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
). 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 ).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 ). 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 ), 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 ).ConclusionThis 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).IANA ConsiderationsThis document has no IANA actions.ReferencesNormative ReferencesBundle Protocol SpecificationThis document describes the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN).This document was produced within the IRTF's Delay Tolerant Networking Research Group (DTNRG) and represents the consensus of all of the active contributors to this group. See http://www.dtnrg.org for more information. This memo defines an Experimental Protocol for the Internet community.Naming Things with HashesThis document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and binary and human-speakable formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols.Information-Centric Networking: Baseline ScenariosThis document aims at establishing a common understanding about a set of scenarios that can be used as a base for the evaluation of different information-centric networking (ICN) approaches so that they can be tested and compared against each other while showcasing their own advantages. Towards this end, we review the ICN literature and document scenarios which have been considered in previous performance evaluation studies. We discuss a variety of aspects that an ICN solution can address. This includes general aspects, such as, network efficiency, reduced complexity, increased scalability and reliability, mobility support, multicast and caching performance, real-time communication efficiency, energy consumption frugality, and disruption and delay tolerance. We detail ICN-specific aspects as well, such as information security and trust, persistence, availability, provenance, and location independence.This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).Information-Centric Networking: Evaluation and Security ConsiderationsThis document presents a number of considerations regarding evaluating Information-Centric Networking (ICN) and sheds some light on the impact of ICN on network security. It also surveys the evaluation tools currently available to researchers in the ICN area and provides suggestions regarding methodology and metrics.Informative ReferencesCell BroadcastWikipediaCOPSS: An Efficient Content Oriented Publish/Subscribe SystemSeventh ACM/IEEE Symposium on Architectures for
Networking and Communications Systems (ANCS)Delay-Tolerant Networking Research Group (DTNRG)IRTFDelay/Disruption Tolerant Networking (dtn)IETFEfficient Publish/Subscribe-Based Multicast for Opportunistic Networking with Self-Organized Resource UtilizationAdvanced Information Networking and Applications - WorkshopsNDN-RTC: Real-Time Videoconferencing over Named Data Networking2nd ACM Conference on Information-Centric Networking
(ICN)Name-based replication priorities in disaster casesIEEE Conference on Computer Communications WorkshopsD2.1: Usage Scenarios and RequirementsH2020 project RIFE, public deliverableDecentralised binding of self-certifying names to real-world identities for assessment of third-party messages in fragmented mobile networksIEEE Conference on Computer Communications WorkshopsDecentralised Interest Counter Aggregation for ICN in Disaster ScenariosIEEE Globecom WorkshopsInformation resilience through user-assisted caching in disruptive Content-Centric NetworksIFIP Networking ConferenceName-based push/pull message dissemination for disaster message boardIEEE International Symposium on Local and
Metropolitan Area Networks (LANMAN)IP over ICN - The better IP?2European Conference on Networks and Communications
(EuCNC)A socio-aware overlay for publish/subscribe communication in delay tolerant networksProceedings of the 10th ACM Symposium on Modeling,
Analysis, and Simulation of Wireless and Mobile
SystemsAcknowledgmentThe authors would like to thank
for useful comments. Also, the authors are grateful to and
for valuable feedback and suggestions on concrete text for
improving the document. Further, the authors would like to thank
and
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,
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: . This document has also been supported by the Coordination Support
Action entitled 'Supporting European Experts Presence in International
Standardisation Activities in ICT' (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' AddressesHFT Stuttgart - Univ. of Applied SciencesSchellingstrasse 2470174StuttgartGermany+49 711 8926 2801jan.seedorf@hft-stuttgart.deUniversity of GöttingenGoldschmidt Str. 737077Göttingen
Germany+49 551 39 172046arumaithurai@informatik.uni-goettingen.deKDDI Research Inc.2-1-15 Ohara, Fujimino356-85025SaitamaJapan+81 49 278 73651tagami@kddi-research.jpUniversity of CaliforniaRiversideCAUnited States of Americakkrama@ucr.eduUniversity Tor VergataVia del Politecnico, 1Roma00133Italy+39 06 7259 7501blefari@uniroma2.it