ICNRG
Internet Research Task Force (IRTF) J. Seedorf
Internet-Draft
Request for Comments: 8884 HFT Stuttgart - Univ. of Applied Sciences
Intended status:
Category: Informational M. Arumaithurai
Expires: August 2, 2020
ISSN: 2070-1721 University of Goettingen Göttingen
A. Tagami
KDDI Research Inc.
K. Ramakrishnan
University of California
N. Blefari Melazzi
University Tor Vergata
January 30,
October 2020
Research Directions for Using ICN Information-Centric Networking (ICN) in
Disaster Scenarios
draft-irtf-icnrg-disaster-10
Abstract
Information Centric
Information-Centric Networking (ICN) is a new paradigm where the
network provides users with named content, content instead of communication
channels between hosts. This document outlines some research
directions for Information Centric Networking 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 Internet-Draft document is submitted in full conformance with not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the
provisions Internet Research Task Force
(IRTF). The IRTF publishes the results of BCP 78 Internet-related research
and BCP 79.
Internet-Drafts are working documents 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 Engineering Research Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid
(IRTF). Documents approved for publication by the IRSG are not a maximum
candidate for any level of Internet Standard; see Section 2 of six months RFC
7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 2, 2020.
https://www.rfc-editor.org/info/rfc8884.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Disaster Scenarios . . . . . . . . . . . . . . . . . . . . . 4
3. Research Challenges and Benefits of ICN . . . . . . . . . . . 5
3.1. High-Level Research Challenges . . . . . . . . . . . . . 5
3.2. How ICN can Can be Beneficial . . . . . . . . . . . . . . . . 7
3.3. ICN as Starting Point vs. Existing DTN Solutions . . . . 8
4. Use Cases and Requirements . . . . . . . . . . . . . . . . . 9
5. ICN-based ICN-Based Research Approaches and Open Research Challenges . 10
5.1. Suggested ICN-based ICN-Based Research Approaches . . . . . . . . . 10
5.2. Open Research Challenges . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 15 Conclusion
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A.
Acknowledgment . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
This document summarizes some research challenges for coping with
natural or human-generated, large-scale disasters. In particular,
the document discusses potential research directions for applying
Information Centric
Information-Centric Networking (ICN) to address these challenges.
There are existing research
Research and standardization approaches exist (for instance, see further the
work and discussions in the concluded IRTF DTN Research Group [dtnrg]
and in the IETF DTN Working Group [dtnwg])
and an IRTF stream [dtnwg]). In addition, a published
Experimental RFC in the IRTF Stream [RFC5050] for Delay/Disruption discusses Delay-
Tolerant Networking (DTN), which is a key necessity for communicating
in the disaster scenarios we are considering in this document (see
further Section 3.1 ). 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 as key concepts suitable concepts, such as new naming schemes and innovative
multicast communication communication, which together enable many key (publish/
subscribe-based) essential
(publish/subscribe-based) use cases for communication after a
disaster (e.g. (e.g., message prioritisation, prioritization, one-to-many delivery of important
messages,
or group communication among rescue teams, see further and the use cases
discussed in Section 4 ). 4). One could add such features to existing DTN
protocols and solutions; however, in this document document, we explore the
use of ICN as a starting point for building a communication
architecture that supports (somewhat limited) communication
capabilities after a disaster. We discuss the relationship between
the ICN approaches (for enabling communication after a disaster)
discussed in this document with existing work from the DTN community
in more depth in Section 3.3 . 3.3.
'Emergency Support and Disaster Recovery' is also listed among the
ICN Baseline Scenarios in [RFC7476] as a potential scenario that 'can
be used as a base for the evaluation of different information-centric
networking (ICN) ICN approaches so
that they can be tested and compared against each other while
showcasing their own advantages' [RFC7476] . In this regard, this
document complements [RFC7476] by investigating the use of ICN
approaches for 'Emergency Support and Disaster Recovery' in depth and
discussing the relationship to existing work in the DTN community.
This document focuses on ICN-based approaches that can enable
communication after a disaster. These approaches reside mostly on
the networking network layer. Other solutions for 'Emergency Support and
Disaster Recovery', e.g., Recovery' (e.g., on the application layer, 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 ICN benefits on the networking network layer for users. However,
the discussion of applications or solutions outside of the
networking network
layer are outside the scope of this document.
This document represents the consensus of the Information-Centric
Networking Research Group (ICNRG); it is not an IETF product and it
does not define a standard. It has been reviewed extensively by the
ICN Research Group (RG) members active in the specific areas of work
covered by the document.
Section 2 gives some examples of what can be considered a large-scale
disaster and what the effects of such disasters on communication
networks are. Section 3 outlines why ICN can be beneficial in such
scenarios and provides a high-level overview on corresponding
research challenges. Section 4 describes some concrete use cases and
requirements for disaster scenarios. In Section 5 , 5, some concrete
ICN-based solutions approaches are outlined.
2. Disaster Scenarios
An enormous earthquake hit Northeastern Japan (Tohoku areas) on March
11, 2011, 2011 and caused extensive damages damages, including blackouts, fires,
tsunamis
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, residents and affected rescue
work, evacuation activities, and the supply chain for food and other
essential items. Even in the Tokyo area that area, which is 300km 300 km away from
the Tohoku area, more than 100,000 people became 'returner' refugees, '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
communication, including safety confirmation: confirmation. Besides (emergency)
phone calls, services in mobile networks commonly being used after a
disaster include network disaster SMS notifications (or SMS 'Cell
Broadcast' [cellbroadcast]), available in most cellular networks.
The aftermath of a disaster puts a high strain on available resources
due to the need for communication by everyone. Authorities Authorities, such as
the President/Prime-Minister, president or prime minister, local authorities, Police, police, fire
brigades, and rescue and medical personnel 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 wellbeing. well-being. Affected citizens would like to make
enquiries of
inquiries about food distribution centres, 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 communication, highlights the issue of fault-tolerance fault tolerance and
energy efficiency.
Additionally, disasters caused by humans such as a terrorist attack
may need to be considered, i.e. (i.e., disasters that are
caused deliberately and willfully and have the element of human intent.
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 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 predictable 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 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
Information-Centric Networks can be suitable, in conjunction with
application and middleware assistance.
3. Research Challenges and Benefits of ICN
3.1. High-Level Research Challenges
Given a disaster scenario as described in Section 2, on a high-level high level,
one can derive the following (incomplete) list of corresponding
technical challenges:
o
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, (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 networks, which are comprised of a
centralised
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.
o Decentralised
Decentralized authentication, content integrity, and trust:
In mobile networks, users are authenticated via central entities.
While special services important in a disaster scenario exist and
may work without authentication (such as SMS 'Cell Broadcast'
[cellbroadcast] or emergency calls), user-to-user (or user-to-
authorities) communication is normally not possible without being
authenticated via a central entity in the network. In order to
communicate in fragmented or disconnected parts of a mobile
network, the challenge of decentralising 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 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 model,
such as PGP). Pretty Good Privacy (PGP)). Note that blockchain-based
approaches are are, in most cases 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 presumably will presumably
not be available (or too excessive for the remaining
infrastructure) after a disaster.
o
Delivering/obtaining information and traffic prioritization in
congested networks:
Due to broken cables, failed routers, etc., it is likely that in a disaster scenario the
communication network has much less overall capacity for handling traffic.
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 as because, in the case of a disaster
aftermath, it may be crucial to deliver certain information to
recipients (e.g. (e.g., warnings to citizens) with higher priority than
other content.
o Delay/Disruption Tolerant Approach:
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. E.g., 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, end-to-end manner but would
also be helpful to the human recipient if it can be tranported transported in
a hop-by-hop fashion with some delay. For these kinds of use-cases, use
cases, it is sufficient to improve communication resilience in
order to deliver such important messages.
o
Energy Efficiency: 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.
o
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 used, and
many other contextual aspects are highly relevant for an efficient
realization of any rescue effort and, with it, the realization of
the required communication.
3.2. How ICN can Can be Beneficial
Several aspects of ICN make related approaches attractive candidates
for addressing the challenges described in Section 3.1 . 3.1. Below is an
(incomplete) list of considerations why ICN approaches can be
beneficial to address these challenges:
o
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 application-
layer servers (e.g. (e.g., DNS resolvers). In highly
decentralised decentralized
scenarios (e.g. (e.g., in infrastructureless, opportunistic
environments)
environments), the ICN routing-by-name paradigm effectively may
lead to a 'replication-by-name' approach, where content is
replicated depending on its name.
o
Integrity and Authentication 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 (see e.g. (e.g., see [RFC6920]). With such
approaches, object integrity of data retrieved from the network
can be verified without relying on a trusted third party or PKI.
In addition, given that the correct object name is known, such
schemes can also provide data origin authentication (see for instance Section 8.3. (for instance,
see the usage example in [RFC6920])
o Section 8.3 of [RFC6920]).
Content-based access control:
ICN promotes a data-centric communication model which that naturally
supports content-based security (e.g. (e.g., allowing access to content
only to a specific user or class of users) as users). In fact, in ICN - if desired - not ICN, it
is the communication
channel content itself that is secured (encrypted) but (encrypted), if desired,
rather than the content itself. 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.
o
Caching:
Caching content along a delivery path is an inherent concept in
ICN. Caching helps in handling huge amounts of
traffic, traffic and can
help to avoid congestion in the network (e.g. (e.g., congestion in
backhaul links can be avoided by delivering content from caches at
access nodes).
o
Sessionless:
ICN does not require full end-to-end connectivity. This feature
facilitates a seemless seamless aggregation between a normal network and a
fragmented network, which needs DTN-like message forwarding.
o
Potential to run traditional IP-based services (IP-over-ICN):
While ICN and DTN promote the development of novel applications
that fully utilize the new capabilities of the ICN/DTN network,
work in [Trossen2015] has shown that an ICN-enabled network can
transport IP-based services, either directly at IP or even at HTTP
level. With this, IP- and ICN/DTN-based services can coexist,
providing the necessary support of legacy applications to affected
users,
users while reaping any benefits from the native support for ICN
in future applications.
o
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 priority-based
replication depending on the scope of a given message [Psaras2014]
.
[Psaras2014]. In addition, as [Trossen2015] , [Trossen2015], among others, have
pointed out, the realization of ICN services and particularly of
IP-based services on top of ICN provide further traffic
engineering opportunities. The latter not only relate to the
utilization of cached content, as outlined before, but to the
ability to flexbily flexibly adapt to route changes (important in
unreliable infrastructure infrastructure, such as in disaster scenarios),
mobility support without anchor points (again, important when
parts of the infrastructure are likely to fail) fail), and the inherent
support for multicast and multihoming delivery.
3.3. ICN as Starting Point vs. Existing DTN Solutions
There has been quite some work in the DTN (Delay Tolerant (Delay-Tolerant Networking)
community on disaster communication (for instance, see further the work and
discussions in the concluded IRTF DTN Research Group [dtnrg] and in
the IETF DTN Working Group [dtnwg]). However, most DTN work lacks
important features features, such as publish/subscribe (pub/sub) capabilities,
caching, multicast delivery, and message prioritisation 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. (e.g., [Greifenberg2008] and
[Yoneki2007] propose the use of a pub/sub-based multicast
distribution infrastructure for DTN-based opportunistic networking
environments).
However, arguably ICN---having ICN -- having these intrinsic properties (as also
outlined above)---makes 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 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 end user can in principle
respond to an interest, c) built-in multi-cast multicast delivery implies
energy-efficient
energy-efficient, large-scale spreading of important information which that
is crucial in disaster scenarios, and d) pub/sub extension for
popular ICN implementations exist [COPSS2011] [COPSS2011], which are very
suitable for efficient group communication in disasters and provide
better reliability, timeliness timeliness, and scalability scalability, as compared to
existing pub/
sub pub/sub approaches in DTN [Greifenberg2008] [Yoneki2007] .
Finally, most DTN routing algorithms have been solely designed for
particular DTN scenarios. By extending ICN approaches for DTN-like
scenarios, one ensures that a solution works in regular (i.e. (i.e., well-
connected) settings just as well (which can be important in reality,
where a routing algorithm should work before and after a disaster).
It is thus reasonable to start with existing ICN approaches and
extend them with the necessary features needed in disaster scenarios.
In any case, solutions for disaster scenarios need a combination of
ICN-features and DTN-capabilities.
4. Use Cases and Requirements
This Section section describes some use cases for the aforementioned disaster
scenario (as outlined in Section 2 ) 2) and discusses the corresponding
technical requirements for enabling these use cases.
o
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.,
Earthquake, Tornado), 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 people must
be able to communicate with others in the same network fragment, 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.
o
Spreading Crucial Information to Citizens:
State authorities want to be able to convey important information (e.g. warnings,
(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 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: 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 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 DTN-like mechanisms for getting information from
disconnected island to another disconnected island.
It can be observed that different key use cases for disaster
scenarios imply overlapping and similar technical requirements for
fulfilling them. As discussed in Section 3.2 , 3.2, ICN approaches are
envisioned to be very suitable for addressing these requirements with
actual technical solutions. In [Robitzsch2015] , [Robitzsch2015], a more elaborate set
of requirements is provided that addresses, among disaster scenarios,
a communication infrastructure for communities facing several
geographic, economic economic, and political challenges.
5. ICN-based ICN-Based Research Approaches and Open Research Challenges
This section outlines some ICN-based research approaches that aim at
fulfilling the previously mentioned use cases and requirements
(Section 5.1). Most of these works provide proof-of-concept type
soluions,
solutions, addressing singular challenges. Thus, several open issues
remain
remain, which are summarized in Section 5.2.
5.1. Suggested ICN-based ICN-Based Research Approaches
The research community has investigated ICN-based solutions to
address the aforementioned challenges in disaster scenarios.
Overall, the focus is on delivery of messages and not real-time
communication. While most probably 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, see
networks as can be the case in the scenarios described in Section 2),
somewhat delayed message delivery appears to be inevitable, and full-duplex 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. (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 principle, ICN can support VoIP Voice over IP (VoIP) calls; thus, if
users are in close proximity, (duplex) voice communication via ICN is
possible [Gusev2015], and b) delayed message delivery can very well
include (recorded) voice messages.
o
ICN 'data mules':
To facilitate the exchange of messages between different network
fragments, mobile entitites entities can act as ICN 'data
mules' 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 pre-determined predetermined path (an ambulance going to and
from a hospital), a fixed path (drone/robot assigned specifically
to do so) so), or a completely random path (doctors moving from one
camp to another). An example of a many-
to-many many-to-many communication
service for fragmented networks based on ICN data mules has been
proposed in [Tagami2016].
o
Priority-dependent or popularity-dependent popularity-dependent, name-based
replication:
By allowing spatial and temporal scoping of named messages,
priority based
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 prioritisation prioritization of ICN messages in disasters, called 'NREP',
has been proposed [Psaras2014] , [Psaras2014], where ICN messages have
attributes
attributes, such as user-defined priority, space, and temporal- temporal
validity. These attributes are then taken into account when
prioritizing messages. In [Psaras2014] , [Psaras2014], evaluations show how this
approach can be applied to the use case 'Delivering Messages to
Relatives/Friends' decribed described in Section 4. In [Seedorf2016], a
scheme is presented that enables to estimate 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) 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.
o
Information Resilience resilience through Decentralised Forwarding: decentralized forwarding:
In a dynamic or disruptive environment, such as the aftermath of a
disaster, both users and content servers may dynamically join and
leave the network (due to mobility or network fragmentation).
Thus, users might attach to the network and request content when
the network is fragmented and the corresponding content origin is
not reachable. In order to increase information resilience,
content cached both in in-network caches and in end-user devices
should be exploited. A concrete approach for the exploitation of
content cached in user devices is presented in [Sourlas2015] . The
proposal in [Sourlas2015] includes enhancements to the NDN Named Data
Networking (NDN) router design, as well as an alternative Interest forwarding
Interest-forwarding scheme which that enables users to retrieve cached
content when the network is fragmented and the content origin is
not reachable. Evaluations show that this approach is a valid
tool for the retrieval of cached content in disruptive cases and
can be applied to tackle the challenges presented in Section 3.1 .
o
Energy Efficiency: efficiency:
A large-scale disaster causes can cause a large-scale
blackout and thus 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:
Priority explored, including priority
control, cell-zooming, cell zooming, and collaborative upload. Cell zooming switches-off
switches off some of the BSs because switching-off 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 end
devices delegate sending and receiving messages to and from a base station BS
to a representative end-device 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)} Publish/Subscribe System)
framework is envisioned [COPSS2011] .
o [COPSS2011].
Data-centric confidentiality and access control:
In ICN, the requested content is not anymore 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, or if extra information provided
by trusted entities is needed, this should be gathered through
offline, asynchronous, and non interactive 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), Encryption (CP-ABE)', allowing
a party to encrypt a content specifying a policy, which policy that consists in
a Boolean expression over attributes, attributes that must be satisfied by
those who want to decrypt such content. Such encryption schemes
tie confidentiality and access-control access control to the transferred data,
which can also be transmitted also 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.
o Decentralised
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 self-
certifying names lack a binding with a corresponding real-world
identity. Given the
decentralised decentralized nature of a disaster scenario,
a PKI-based approach for binding self-certifying names with real-world real-
world identities is not feasible. Instead, a Web-of-Trust Web of Trust can be
used to provide this binding. Not only are the cryptographic
signatures used within a
Web-of-Trust Web of Trust independent of any central authority;
authority, but there are also technical means for making the
inherent trust relationships of a
Web-of-Trust Web of Trust available to
network entities in a decentralised, decentralized, 'offline' fashion, such that
information received can be assessed based on these trust
relationships. A concrete scheme for such an approach has been
published in [Seedorf2014] , where also [Seedorf2014], in which concrete examples for
fulfilling the use case 'Delivering Messages to Relatives/Friends'
with this approach are also given.
5.2. Open Research Challenges
The proposed solutions in Section 5.1 investigate how ICN approaches
can
can, in principal 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:
o Evaluation of
* Evaluating the proposed mechanisms (and their scalability) in
realistic
realistic, large-scale testbeds with actual, mature
implementations (compared to simulations or emulations)
o Specifying emulations).
* To specify, for each mechanism suggested to suggested, what exact extent ICN
deployment in would be the network and at user
equipment is required or
would be necessary, necessary before and after a disaster.
o How disaster and to best use
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?
o
* How do data-centric encryption schemes scale and perform in large-
scale, realistic evaluations?
o Build
* Building and test testing real (i.e. (i.e., not early-stage prototypes) ICN
data mules by means of implementation and integration with lower lower-
layer hardware; conduct conducting evaluations of decentralised decentralized forwarding
schemes in real environments with these actual ICN data mules
o mules.
* How to derive concrete policies for ICN-style derive concrete, name-based policies allowing prioritized
spreading of information?
o information.
* Further investigate, develop, investigating, developing, and verify verifying of mechanisms
that address energy efficiency requirements for communication
after a disaster
o disaster.
* How to properly disseminate authenticated object names to nodes
(for decentralised decentralized integrity verification and authentication)
before a disaster, disaster or how to retrieve new authenticated object
names by nodes during a disaster? disaster.
6. Security Considerations
This document does not define a new protocol (or protocol extension)
or a particular mechanism, and therefore mechanism; therefore, it introduces no specific new
security considerations. General security considerations for
Information-Centric Networking -- ICN,
which also apply when using ICN
networking techniques to communicate after a disaster --
disaster, are discussed in [RFC7945].
The after-disaster communication scenario scenario, which is the focus of this
document
document, raises particular attention to decentralised decentralized
authentication, content integrity, and trust as key research
challenges (as outlined in Section 3.1). The corresponding use cases
and ICN-based research approaches discussed in this document thus
imply certain security requirements. In particular particular, data origin
authentication, data integrity, and access control are key
requirements for many use cases in the aftermath of a disaster (see
Section 4).
In principle, the kinds of disasters discussed in this document can
happen as a result of a natural disaster, accident accident, or by human-error. human error.
However, also intentional actions can also cause such a disaster (e.g., a
terrorist attack, as mentioned in Section 2). In this case, i.e., case (i.e.,
intentionally caused disasters by attackers, attackers), special attention needs
to be paid when re-enabling communications as temporary, somewhat un-
reliable
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 such an intentionally caused disaster are out of
scope of this document.
The use of data-centric security schemes schemes, such as 'Ciphertext-Policy
Attribute Based Encryption' (as mentioned in Section 5.1) 5.1), which
encrypt the data itself (and not the communication channel), in
principle
principle, allows for the transmission of such encrypted data over an
unsecured channel. However, still metadata about the encrypted data being
retrieved still arises. Such metadata may disclose sensitive
information to a network-based attacker 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 control, as well as recent works for
decentralised
decentralized authentication of messages in a disaster-struck
networking infrastructure with non-functional nonfunctional routing links and
limited communication capabilities (see Section 5).
7. Conclusion
This document has outlined some research directions for Information
Centric Networking (ICN) ICN with
respect to applying ICN approaches for coping with natural or human-generated, human-
generated, large-scale disasters. The document has described high-level high-
level research challenges for enabling communication after a disaster
has happened 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 ICN-
based approaches has been discussed.
Finally, the this document provided 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 more-detailed
challenges exist exist, and more research is necessary in all areas
discussed: efficient content distribution and routing in fragmented
networks, traffic prioritization, security, and energy-efficiency. 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: 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 towards toward standards for concrete ICN protocols that enable
interopability
interoperability among solutions from different vendors. These
protocols - -- currently being standardized as developed in the IRTF stream ICNRG as
Experimental specifications in the IRTF INCRG - Stream -- provide a good
foundation for deploying ICN-based ICN-based, disaster-aftermath communication
and thereby
addressing address key use cases that arise in such situations (as
outlined in this document).
8. IANA Considerations
This document requests has no IANA actions.
9. References
9.1. Normative References
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, DOI 10.17487/RFC5050, November
2007, <https://www.rfc-editor.org/info/rfc5050>.
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
Keranen, A., and P. Hallam-Baker, "Naming Things with
Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
<https://www.rfc-editor.org/info/rfc6920>.
[RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G.,
Tyson, G., Davies, E., Molinaro, A., and S. Eum,
"Information-Centric Networking: Baseline Scenarios",
RFC 7476, DOI 10.17487/RFC7476, March 2015,
<https://www.rfc-editor.org/info/rfc7476>.
[RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S.,
and G. Boggia, "Information-Centric Networking: Evaluation
and Security Considerations", RFC 7945,
DOI 10.17487/RFC7945, September 2016,
<https://www.rfc-editor.org/info/rfc7945>.
9.2. Informative References
[cellbroadcast]
Wikipedia, "Cell Broadcast - Wikipedia,
https://en.wikipedia.org/wiki/Cell_Broadcast", (online). Broadcast", August 2020,
<https://en.wikipedia.org/w/
index.php?title=Cell_Broadcast&oldid=972614007>.
[COPSS2011]
Chen, J., Arumaithurai, M., Jiao, L., Fu, X., and K.
Ramakrishnan, "COPSS: An Efficient Content Oriented
Publish/Subscribe System", Seventh ACM/IEEE Symposium on
Architectures for Networking and Communications Systems
(ANCS), 2011. DOI 10.1109/ANCS.2011.27, October 2011,
<https://doi.org/10.1109/ANCS.2011.27>.
[dtnrg] Fall, K. and J. Ott, IRTF, "Delay-Tolerant Networking Research Group - DTNRG", https://irtf.org/dtnrg. (DTNRG)",
<https://irtf.org/dtnrg>.
[dtnwg] Fall, K. and J. Ott, IETF, "Delay/Disruption Tolerant Networking
WG", https://tools.ietf.org/wg/dtn/. (dtn)",
<https://datatracker.ietf.org/wg/dtn/about/>.
[Greifenberg2008]
Greifenberg, J. and D. Kutscher, "Efficient publish/
subscribe-based multicast Publish/
Subscribe-Based Multicast for opportunistic networking Opportunistic Networking
with self-organized resource utilization", Self-Organized Resource Utilization", Advanced
Information Networking and Applications-Workshops, 2008. Applications - Workshops,
DOI 10.1109/WAINA.2008.255, March 2008,
<https://doi.org/10.1109/WAINA.2008.255>.
[Gusev2015]
Gusev, P. and J. Burke, "NDN-RTC: Real-Time
Videoconferencing over Named Data Networking", 2nd ACM
Conference on Information-Centric Networking (ICN 2015),
Sep. 30 - Oct. 2, San Francisco, CA, USA. (ICN),
DOI 10.1145/2810156.2810176, September 2015,
<https://doi.org/10.1145/2810156.2810176>.
[Psaras2014]
Psaras, I., Saino, L., Arumaithurai, M., Ramakrishnan, K.,
and G. Pavlou, "Name-Based Replication Priorities "Name-based replication priorities in
Disaster Cases", 2nd Workshop
disaster cases", IEEE Conference on Name Oriented Mobility
(NOM), 2014. Computer
Communications Workshops,
DOI 10.1109/INFCOMW.2014.6849271, April 2014,
<https://doi.org/10.1109/INFCOMW.2014.6849271>.
[Robitzsch2015]
Robitzsch, S., Trossen, D., Theodorou, C., Barker, T., and
A. Sathiaseel, "D2.1: Usage Scenarios and
Requirements"", Requirements",
H2020 project RIFE, public deliverable,
2015. deliverable.
[Seedorf2014]
Seedorf, J., Kutscher, D., and F. Schneider,
"Decentralised Binding binding of Self-Certifying Names self-certifying names to Real-
World Identities real-
world identities for Assessment assessment of Third-Party Messages third-party messages in
Fragmented Mobile Networks", 2nd Workshop
fragmented mobile networks", IEEE Conference on Name
Oriented Mobility (NOM), 2014. Computer
Communications Workshops,
DOI 10.1109/INFCOMW.2014.6849268, April 2014,
<https://doi.org/10.1109/INFCOMW.2014.6849268>.
[Seedorf2016]
Seedorf, J., Kutscher, D., and B. Gill, "Decentralised
Interest Counter Aggregation for ICN in Disaster
Scenarios", Workshop on Information Centric Networking
Solutions for Real World Applications (ICNSRA), 2016. IEEE Globecom Workshops,
DOI 10.1109/GLOCOMW.2016.7848869, December 2016,
<https://doi.org/10.1109/GLOCOMW.2016.7848869>.
[Sourlas2015]
Sourlas, V., Tassiulas, L., Psaras, I., and G. Pavlou,
"Information Resilience resilience through User-Assisted Caching user-assisted caching in
Disruptive
disruptive Content-Centric Networks", 14th IFIP
NETWORKING, Networking
Conference, DOI 10.1109/IFIPNetworking.2015.7145301, May 2015.
2015,
<https://doi.org/10.1109/IFIPNetworking.2015.7145301>.
[Tagami2016]
Tagami, A., Yagyu, T., Sugiyama, K., Arumaithurai, M.,
Nakamura, K., Hasegawa, T., Asami, T., and K.
Ramakrishnan, "Name-based Push/Pull Message Dissemination push/pull message dissemination
for Disaster Message Board", The 22nd disaster message board", IEEE International Symposium
on Local and Metropolitan Area Networks (LANMAN), 2016.
DOI 10.1109/LANMAN.2016.7548855, June 2016,
<https://doi.org/10.1109/LANMAN.2016.7548855>.
[Trossen2015]
Trossen, D., Reed, M., Riihijärvi, J., Georgiades, M.,
Fotiou, N., and G. Xylomenos, "IP over ICN - The better
IP?", 2015
European 2European Conference onNetworks on Networks and Communications
(EuCNC),
June/July DOI 10.1109/EuCNC.2015.7194109, June 2015, pp. 413 - 417.
<https://doi.org/10.1109/EuCNC.2015.7194109>.
[Yoneki2007]
Yoneki, E., Hui, P., Chan, S., and J. Crowcroft, "A socio-
aware overlay for publish/subscribe communication in delay
tolerant networks", Proceedings of the 10th ACM Symposium
on Modeling, Analysis, and Simulation of Wireless and
Mobile Systems, 2007.
Appendix A. DOI 10.1145/1298126.1298166, October 2007,
<https://doi.org/10.1145/1298126.1298166>.
Acknowledgment
The authors would like to thank Ioannis Psaras for useful comments.
Also, the authors are grateful to Christopher Wood and Daniel Corujo
for valuable feedback and suggestions on concrete text for improving
the document. Further, the authors would like to thank Joerg Ott and
Dirk Trossen for valuable comments and input, in particular particular,
regarding existing work from the DTN community which that is highly related
to the ICN approaches suggested in this document. Also, Akbar Rahman
provided useful comments and usggestions, suggestions, in particular 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
), 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 web site website: http://www.greenicn.org/.
This document has also been supported by the Coordination Support
Action entitled 'Supporting European Experts Presence in
International Standardisation Activities in ICT' (StandICT.eu
(https://standict.eu/)) funded by the European Commission under the
Horizon 2020 Programme with Grant Agreement no. 780439. The views
and conclusions contained herein are those of the authors and should
not be interpreted as necessarily representing the official policies
or endorsements, either expressed or implied, of the European
Commission.
Authors' Addresses
Jan Seedorf
HFT Stuttgart - Univ. of Applied Sciences
Schellingstrasse 24
Stuttgart
70174 Stuttgart
Germany
Phone: +49 711 8926 2801
Fax: +49 711 8926 2553
Email: jan.seedorf@hft-stuttgart.de
Mayutan Arumaithurai
University of Goettingen Göttingen
Goldschmidt Str. 7
Goettingen
37077 Göttingen
Germany
Phone: +49 551 39 172046
Fax: +49 551 39 14416
Email: arumaithurai@informatik.uni-goettingen.de
Atsushi Tagami
KDDI Research Inc.
2-1-15 Ohara Ohara, Fujimino, Saitama
356-85025
Japan
Phone: +81 49 278 73651
Fax: +81 49 278 7510
Email: tagami@kddi-research.jp
K. K. Ramakrishnan
University of California
Riverside
Riverside, CA
USA
United States of America
Email: kkramakrishnan@yahoo.com kkrama@ucr.edu
Nicola Blefari Melazzi
University Tor Vergata
Via del Politecnico, 1
Roma
00133 Roma
Italy
Phone: +39 06 7259 7501
Fax: +39 06 7259 7435
Email: blefari@uniroma2.it