RFC 8884

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

Okay bestie, let's get into this one 💅 It's an Informational doc from the IRTF, and it came out in October 2020. It was written by the Information-Centric Networking Research Group (ICNRG), and the squad of authors is J. Seedorf (HFT Stuttgart - Univ. of Applied Sciences), M. Arumaithurai (University of Göttingen), A. Tagami (KDDI Research Inc.), K. Ramakrishnan (University of California), and N. Blefari Melazzi (University Tor Vergata) 🫶. The ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates, so it's standing completely on its own 🦋

Abstract ✨

Okay so, Information-Centric Networking (ICN) is a newer paradigm where the network hands users named content instead of making them open up a channel between two hosts 🌸 This doc sketches out some research directions for using ICN to help cope with big disasters, whether they're natural or caused by humans 💖 It's a product of the Information-Centric Networking Research Group (ICNRG) 🔥

Status of This Memo 💅

Not gonna lie, this part is a bit formal, but it matters 🙈 This document is not an Internet Standards Track specification. It's published just for information 🍓

It's a product of the Internet Research Task Force (IRTF), which publishes the results of Internet-related research and development. Those results might not be suitable for deployment 💀 This RFC represents the consensus of the Information-Centric Networking Research Group of the IRTF. Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841 💜

If you want the latest on this doc, any errata, or how to send feedback, check 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) as they were in effect on the date of publication. Please review those documents carefully, because they describe your rights and restrictions with respect to this document 📜

Table of Contents 🦋

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

1. Introduction 🎀

So this doc basically summarizes some research challenges for coping with big, large-scale disasters, natural or human-made 😭 Specifically, it talks about research directions for applying ICN to those challenges 💅

There's already research and standardization work out there. You can check the concluded IRTF DTN Research Group [dtnrg] and the IETF DTN Working Group [dtnwg] 🌸 There's also a published Experimental RFC in the IRTF Stream, [RFC5050], which talks about Delay-Tolerant Networking (DTN). DTN is a key necessity for communicating in the disaster scenarios this doc is looking at 🔥 So "disconnection tolerance" can be achieved with these existing DTN approaches. BUT, and this is the lowkey tea ☕, these approaches can give you independence from existing communication infrastructure (which may not work anymore after a disaster has happened), while ICN brings something extra: new naming schemes and innovative multicast communication. Together, those enable a bunch of essential (publish/subscribe-based) use cases for communicating after a disaster, like message prioritization, one-to-many delivery of messages, group communication among rescue teams, and the use cases in Section 4 🦋 You could bolt those features onto existing DTN protocols and solutions. Still, this doc explores ICN as a starting point for building a communication architecture that supports (somewhat limited) communication after a disaster 🫶 We get into how ICN approaches relate to existing DTN community work in more depth in Section 3.3 ✨

Also, "Emergency Support and Disaster Recovery" is listed among the ICN Baseline Scenarios in [RFC7476], as a potential scenario that "can be used as a base for the evaluation of different ICN approaches so that they can be tested and compared against each other while showcasing their own advantages" [RFC7476] . So this doc complements [RFC7476] by digging deeper into how ICN approaches can handle "Emergency Support and Disaster Recovery," and by discussing how that connects to the DTN community 💖

This doc focuses on ICN-based approaches that enable communication after a disaster. These approaches mostly live on the network layer 🌈 Other solutions for "Emergency Support and Disaster Recovery" (for example, on the application layer) can complement the ICN-based networking approaches here and expand the solution space for users communicating after a disaster 💜 Honestly, the use cases in this doc would need applications that take advantage of ICN's network-layer benefits for users. But discussing applications or solutions outside the network layer is out of scope for this document 🙈

This doc 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 was reviewed extensively by the ICN Research Group (RG) members who are active in the specific areas the document covers 🧚

Here's the roadmap ✨ Section 2 gives examples of what counts as a large-scale disaster and how those disasters affect communication networks. Section 3 explains why ICN can be beneficial in these scenarios and gives a high-level overview of the research challenges. Section 4 describes concrete use cases and requirements for disaster scenarios. Then in Section 5, some concrete ICN-based solution approaches get outlined 👑

2. Disaster Scenarios 🌸

Let's talk about the real stuff now 🥺 An enormous earthquake hit Northeastern Japan (Tohoku areas) on March 11, 2011. It caused extensive damage, including blackouts, fires, tsunamis, and a nuclear crisis 😭 The lack of information and means of communication isolated several Japanese cities. That hit residents' safety and well-being, and it messed with 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." These are people who couldn't reach their homes because there was no public transportation 🚉 (The Japanese government has estimated that more than 6.5 million people would become returner refugees if a catastrophic disaster like that hit the Tokyo area.) Yikes 💀

That earthquake also showed that the current network is vulnerable to disasters 🥀 Mobile phones have become lifelines for communication, including safety confirmation 📱 Besides (emergency) phone calls, mobile network services commonly used after a disaster include network disaster SMS notifications (or SMS "Cell Broadcast" [cellbroadcast]), which are available in most cellular networks 📣 The aftermath of a disaster puts a huge strain on available resources, because everyone needs to communicate at once 🌪️ Authorities like the president or prime minister, local authorities, police, fire brigades, and rescue and medical personnel want to tell citizens about possible shelters, food, or even impending danger 🚨 Relatives want to reach each other and find out how they're doing 💌 Affected citizens want to ask about food distribution centers and shelters, or report trapped and missing people to the authorities 🙏 And on top of all that, damage to communication equipment, plus the already heavy demand for communication, highlights the issues of fault tolerance and energy efficiency ⚡

Disasters caused by humans also need to be considered 😤 These are disasters caused deliberately and willfully, with an element of human intent, like a terrorist attack. In those cases, the perpetrators could be actively harming the network by launching a denial-of-service attack, or by monitoring the network passively to collect the information being exchanged, even after the main disaster has already happened 👀 Some natural disasters are predictable to a small extent using weather forecasting technologies, may have a slower onset, and happen in known geographical regions and seasons. Terrorist attacks, on the other hand, almost always happen suddenly, with no advance warning ⚠️ Still, natural and human-induced disasters have lots in common, especially around response and recovery, communication, search and rescue, and coordinating volunteers 🫶

Here's the tricky bit 🥹 Getting timely information out to everyone affected, both during and right after a disaster, is hard in the current world of global information aggregators (like Google, Yahoo, Bing, etc.). Those aggregators need to index vast amounts of specialized disaster-related information. Specialized coverage of the situation and timely dissemination are key to managing disaster situations successfully 💅 The authors believe that network infrastructure capabilities provided by Information-Centric Networks can be suitable here, in conjunction with application and middleware assistance ✨

3. Research Challenges and Benefits of ICN 💜

Up next: the research challenges and why ICN could be the move 👑 Stay tuned for the next part 🦋

3.1. High-Level Research Challenges

okay so bestie, picture a disaster, right? 🌪️ Given the scenario from Section 2, here's an (incomplete 💅) list of the tech challenges you'd basically be facing:

Enabling usage of functional parts of the infrastructure, even when these are disconnected from the rest of the network 🔌 Okay so, let's say parts of the network are still working after a disaster (cables/links, routers, mobile base stations, etc. 📡). It's super desirable to keep using those pieces for communication as much as possible. The problem? They can get cut off from the backhaul and turn into fragmented networks 💔. This is especially rough for today's mobile networks, which are centralized, meaning they need a connection to central entities in the core of the mobile network just to communicate 😩. But even fixed networks need access to a name resolution service to reach certain content, so it's not just a mobile problem, bestie.

Decentralized authentication, content integrity, and trust 🔐 In mobile networks, users get authenticated by central entities. Some special services that matter a lot in a disaster can work without authentication (like SMS 'Cell Broadcast' [cellbroadcast] or emergency calls 📞), but user-to-user (or user-to-authorities) communication normally isn't possible without being authenticated through a central entity in the network. So if you're trying to communicate in fragmented or disconnected parts of a mobile network, you suddenly need to decentralize user authentication. Whether the network is fixed or mobile, verifying data origin and checking that retrieved content is correct can be hard when you're 'offline' (potentially cut off from content publishers, and from the security infrastructure servers that provide missing certificates in a certificate chain or up-to-date info on revoked keys/certificates 🙃). When the network suddenly splits up, trust models may have to shift along with the change in authentication infrastructure. For example, you might switch from a PKI to a web-of-trust model, like Pretty Good Privacy (PGP) 🗝️. Also, blockchain-based approaches are, in most cases, likely not suitable for the disaster scenarios considered in this document 🙅‍♀️. The reason: the communication capabilities needed to find consensus for a new block, and to retrieve blocks at nodes, presumably won't be available (or will be way too excessive for the remaining infrastructure) after a disaster.

Delivering/obtaining information and traffic prioritization in congested networks 🚦 Broken cables, failed routers, etc. mean the network probably has a lot less overall capacity for handling traffic during a disaster 😭. So significant congestion can be expected in parts of the infrastructure, and it's a real challenge to guarantee message delivery. It matters even more because, after a disaster, it may be crucial to get certain information to recipients (like warnings to citizens ⚠️) with higher priority than other content.

Delay/disruption-tolerant approach ⏳ Fragmented networks make it hard to support direct end-to-end communication with small or no delay. But communication in general, and especially during a disaster, can often tolerate some delay 🌷. For example, if you want to know whether someone's relatives are safe, the emergency message doesn't necessarily need end-to-end support. It would still be helpful to the human recipient if it gets transported hop-by-hop with some delay 🐢. For these kinds of use cases, improving communication resilience is enough to deliver such important messages 🫶.

Energy efficiency 🔋 Long power outages can drain the batteries of communication devices, so designing energy-efficient solutions is very important to keep a usable communication infrastructure alive ⚡.

Contextuality 🌍 Like any communication, disaster scenarios are inherently contextual 🧠. Geography, the people affected, the rescue communities involved, the languages being used, and many other contextual aspects are highly relevant for an efficient rescue effort, and therefore for the communication that the effort requires 💜.

3.2. How ICN Can be Beneficial

ICN has several aspects that make related approaches attractive candidates for tackling the challenges from Section 3.1 ✨. Below is an (incomplete 🙈) list of reasons why ICN approaches can be beneficial for these challenges:

Routing-by-name 🏷️ ICN protocols natively route by named data objects and can identify objects by name, which effectively moves name resolution from the application layer to the network layer 🦋. This is so handy in a fragmented network, where location-based, fixed addresses may stop working because of disruptions 💀. For instance, name resolution with ICN doesn't necessarily rely on application-layer servers being reachable (like DNS resolvers). In highly decentralized scenarios (for example, infrastructureless, opportunistic environments), the ICN routing-by-name paradigm may effectively lead to a 'replication-by-name' approach, where content gets 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 'self-certifying data' into a naming scheme (see, e.g., [RFC6920]) 🧾. With approaches like these, you can verify object integrity of data retrieved from the network without relying on a trusted third party or PKI 🙌. Plus, if the correct object name is known, such schemes can also provide data origin authentication (check out the usage example in Section 8.3 of [RFC6920]) 👀.

Content-based access control 🔑 ICN promotes a data-centric communication model that naturally supports content-based security, like allowing access to content only for a specific user or class of users 💅. Here it's the content itself that gets secured (encrypted, if desired), rather than the communication channel 🎀. This could make trusted communication easier 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 handle huge amounts of traffic and can help avoid congestion in the network. For example, congestion in backhaul links can be avoided by delivering content from caches at access nodes 🚀.

Sessionless 🌙 ICN doesn't require full end-to-end connectivity 🙅‍♀️. This makes it easier to seamlessly aggregate a normal network with a fragmented network that needs DTN-like message forwarding 🧩.

Potential to run traditional IP-based services (IP-over-ICN) 🎀 ICN and DTN promote novel applications that fully use the new capabilities of ICN/DTN networks, and work in [Trossen2015] has shown that an ICN-enabled network can transport IP-based services, either directly at IP or even at HTTP level 😮. So IP-based and ICN/DTN-based services can coexist 🤝, giving affected users support for legacy applications while still reaping the benefits of native ICN support in future applications 💖.

Opportunities for traffic engineering and traffic prioritization 🎯 ICN lets you do traffic engineering based on the name of the desired content 📛. This enables priority-based replication depending on the scope of a given message [Psaras2014] 💫. As [Trossen2015], among others, have pointed out, ICN services, and especially IP-based services running on top of ICN, give even more traffic engineering opportunities 🧁. These relate not only to using cached content (as mentioned before), but also to flexibly adapting to route changes (important in unreliable infrastructure, like in disaster scenarios 🌪️), mobility support without anchor points (again important, since parts of the infrastructure are likely to fail 💥), and inherent support for multicast and multihoming delivery 🌟.

---

3.3. ICN as Starting Point vs. Existing DTN Solutions

there has been quite some work in the DTN (Delay-Tolerant Networking) community on disaster communication 📚 (see, for instance, 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 like publish/subscribe (pub/sub) capabilities, caching, multicast delivery, and message prioritization based on content types, which are needed in the disaster scenarios we're looking at 😤. People could add these features to existing DTN protocols and solutions, and individual proposals for doing so have indeed been made (e.g., [Greifenberg2008] and [Yoneki2007] propose using a pub/sub-based multicast distribution infrastructure for DTN-based opportunistic networking environments) 🙌.

However, arguably ICN makes a better starting point 🌟, since it has these intrinsic properties (as outlined above). It's a better base for building a communication architecture that works well before and after a disaster 🌈. For a disaster-enhanced ICN system, this would mean the following advantages 👑:

• a) ICN data mules would have built-in caches and can thus return content for interests straight on 🧺,
• b) requests don't necessarily need to be routed to a source (unlike 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 extensions for popular ICN implementations exist [COPSS2011], which are very suitable for efficient group communication in disasters and provide better reliability, timeliness, and scalability compared to existing pub/sub approaches in DTN [Greifenberg2008] [Yoneki2007] 💜.

Finally, most DTN routing algorithms were solely designed for particular DTN scenarios 🤔. By extending ICN approaches for DTN-like scenarios, you make sure a solution works just as well in regular (i.e., well-connected) settings 💖. This matters in reality, because a routing algorithm should work before and after a disaster 🫶. So it's reasonable to start with existing ICN approaches and extend them with the 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 ✨

Okay bestie, this section is where we get into real use cases for the disaster scenario from Section 2 and the technical requirements needed to make them work 🫶 This is the good stuff.

Delivering Messages to Relatives/Friends:

So after a disaster hits (think earthquake or tornado 😭), people get separated and end up in different refugee shelters. The mobile network isn't fully back yet and it's all fragmented, but some base stations are still working 📡 This use case has two high-level needs: a) people must be able to talk to others in the same network fragment, and b) people must be able to talk to others in different fragmented parts of the overall network.

Concretely, the requirements are: 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 users can confirm that messages are actually from their relatives or friends and haven't been tampered with 🔐, and d) support for contextual caching, so the right information reaches the right set of affected people in the most efficient manner 💖

Spreading Crucial Information to Citizens:

State authorities want to get important info (warnings, where to go, how to behave) to citizens 📢 This info shall reach as many citizens as possible. In other words, crucial content from legal authorities shall potentially reach all users in time. The technical requirements that come out of this are: a) source authentication and content integrity, so 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 one disconnected island to another disconnected island 🌊

It's giving a pattern, periodt 💅 Different key use cases for disaster scenarios end up needing overlapping and similar technical requirements. As discussed in Section 3.2, ICN approaches are envisioned to be a very good fit for addressing these requirements with actual technical solutions ✨ Also, [Robitzsch2015] goes much deeper and lays out a more elaborate set of requirements. It covers, among disaster scenarios, a communication infrastructure for communities facing several geographic, economic, and political challenges 🌈

5. ICN-Based Research Approaches and Open Research Challenges 🔬

Next up are some ICN-based research approaches that aim to fulfill the use cases and requirements we just covered (see Section 5.1) 🧚 Real talk, most of these works are proof-of-concept type solutions that tackle singular challenges one at a time. So there are still several open issues left over, and those are summarized in Section 5.2 🦋

5.1. Suggested ICN-Based Research Approaches ✨

Okay so the research community has been going all in on ICN-based fixes for the messy challenges we covered earlier 🌪️. The main focus is on delivering messages, not real-time chatting 💀. Most people would obviously love live voice or video calls after a disaster, but when users are scattered across fragmented networks (like the scenarios in Section 2), a bit of delay is kind of unavoidable. Full-duplex real-time comms seem basically infeasible, unless people are right next to each other 🫶. So for a while, at least (the initial period until the regular comms infrastructure gets repaired), users have to live with message delivery and publish/subscribe services but without real-time calls 😭.

Note though!! a) in principle, ICN can support VoIP calls, so if people are close together, duplex voice communication via ICN is possible [Gusev2015] 🎧, and b) delayed message delivery can totally include recorded voice messages 🎙️.

ICN 'data mules'

To swap messages between network fragments, mobile entities can act as ICN 'data mules' 🚐. They're equipped with storage space and roam around the disaster zone collecting info to spread. As they move, they drop messages off with people or attachment points on other fragments 📬. A data mule could follow a predetermined path (an ambulance going to and from a hospital 🚑), a fixed path (a drone or robot assigned specifically to do this 🤖), or a completely random path (doctors hopping from one camp to another 🩺). A many-to-many communication service for fragmented networks based on ICN data mules was proposed in [Tagami2016] 🦋.

Priority-dependent or popularity-dependent, name-based replication

By letting named messages be scoped in space and time, priority-based replication depending on a message's scope becomes possible 📍⏰. Spreading info in a disaster clearly involves space and time factors, and those need to be taken into account as messages spread. A concrete approach for this scope-based prioritization of ICN messages, called 'NREP', was proposed in [Psaras2014] 👑. ICN messages there carry attributes such as user-defined priority, space, and temporal validity, and those attributes get factored in when messages are prioritized. [Psaras2014] evaluates how this approach applies to the use case 'Delivering Messages to Relatives/Friends' from Section 4 💌.

[Seedorf2016] is another big one 🧠. It presents a scheme for estimating the popularity of ICN interest messages in a completely decentralized way among data mules, in a scenario with random, unpredictable mule movements. The approach uses nonces attached to end user requests, which are common in most ICN architectures 🔢. This lets a given ICN data mule estimate the overall popularity (among end users) of a given ICN interest message. Data mules can then 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 like the aftermath of a disaster, both users and content servers may join and leave the network (due to mobility or network fragmentation) 🌀. So users might attach to the network and request content while it's fragmented and the content origin isn't reachable 😬. To boost information resilience, content cached both in in-network caches and in end-user devices should be exploited 💾. A concrete approach for exploiting content cached in user devices is presented in [Sourlas2015]. Its proposal includes enhancements to the Named Data Networking (NDN) router design, plus an alternative Interest-forwarding scheme that lets users retrieve cached content when the network is fragmented and the content origin is not reachable 🙌. Evaluations show this is a valid tool for retrieving cached content in disruptive cases, and it can tackle the challenges presented in Section 3.1 🎯.

Energy efficiency

A large-scale disaster can cause a large-scale blackout 🕯️, so a number of base stations (BSs) will be running on their batteries. The capacity of those batteries isn't large enough to keep cellular communication going for several days after the disaster 🪫. To stretch battery 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 cut the power consumed at idle time 💤. The areas covered by those inactive BSs get covered by the active BSs instead 📡. Collaborative communication is complementary to cell zooming and reduces power in proportion to a BS's load, where the load represents cellular frequency resources 📶. In collaborative communication, end devices hand off sending and receiving messages to and from a BS over to a representative end device with better radio propagation quality 🤝. The design of an ICN-based publish/subscribe protocol that incorporates collaborative upload is ongoing work, and integrating collaborative upload techniques into the COPSS (Content Oriented Publish/Subscribe System) framework is envisioned [COPSS2011] 🌈.

Data-centric confidentiality and access control

In ICN, requested content is no longer tied to a trusted server or an endpoint location. It can be retrieved from any network cache or a replica server 🗃️. This calls for 'data-centric' security, where security relies exclusively on information contained in the message itself. If extra information from trusted entities is needed, it should be gathered through offline, asynchronous, and noninteractive communication, rather than an explicit online interactive handshake with trusted servers 🙅‍♀️. Guaranteeing security without any online entities is a huge deal in disaster scenarios with fragmented networks 💅. One concrete cryptographic technique is 'Ciphertext-Policy Attribute Based Encryption (CP-ABE)', which lets a party encrypt content with a policy: a Boolean expression over attributes that must be satisfied by anyone who wants to decrypt it 🔐. These schemes tie confidentiality and access control to the transferred data itself, which can even travel over an unsecured channel 🫣. They also let the source specify, during encryption, the set of nodes allowed to decrypt the content later on 👑.

Decentralized authentication of messages

Self-certifying names let any entity in a distributed system verify the binding between a public key and the self-certifying name, without relying on a trusted third party 🪪. That gives a decentralized form of data origin authentication. The catch? Self-certifying names lack a binding to a real-world identity 😵. In a decentralized disaster scenario, a PKI-based approach for binding self-certifying names to real-world identities isn't feasible 🙅‍♀️. Instead, a Web of Trust can provide that binding 🕸️. The cryptographic signatures used in a Web of Trust don't depend on any central authority, and there are technical means to make its inherent trust relationships available to network entities in a decentralized, 'offline' fashion. That way, received information can be assessed based on those trust relationships 🧁. A concrete scheme for this approach was published in [Seedorf2014], which also gives concrete examples of fulfilling the use case 'Delivering Messages to Relatives/Friends' this way 💖.

5.2. Open Research Challenges 🔭

The solutions proposed in Section 5.1 show how ICN approaches can, in principle, address some of the outlined challenges. However, several research challenges are still open and need addressing 🧩. The following (incomplete) list sums up some unanswered research questions and items that researchers are currently investigating 📝:

• Evaluating the proposed mechanisms (and their scalability) in realistic, large-scale testbeds with actual, mature implementations (compared to simulations or emulations) 🧪.
• Specifying, for each suggested mechanism, what user equipment would be required or necessary before and after a disaster, and to what extent ICN should be deployed in the network 📱.
• Figuring out how DTN and ICN approaches can best be used together for an optimal overall combination of techniques 🤔.
• Finding out how 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 through implementation and integration with lower-layer hardware, and conducting evaluations of decentralized forwarding schemes in real environments with these actual ICN data mules 🚚.
• Working out how to derive concrete, name-based policies that allow prioritized spreading of information 🏷️.
• Further investigating, developing, and verifying mechanisms that address energy efficiency requirements for communication after a disaster 🔋.
• Figuring out how to properly disseminate authenticated object names to nodes (for decentralized integrity verification and authentication) before a disaster, or how nodes can retrieve new authenticated object names during a disaster 🪄.

Okay that's the vibe for this part, bestie! 🎀

6. Security Considerations ✨

This document doesn't define a new protocol (or protocol extension) or a particular mechanism, so it introduces no specific new security considerations 🔒. General security considerations for ICN, which also apply when you're using ICN techniques to communicate after a disaster, are discussed in [RFC7945] 🧠.

The after-disaster communication scenario is the main focus here, and it puts a spotlight on decentralized authentication, content integrity, and trust as key research challenges (as outlined in Section 3.1) 👀. So the use cases and ICN-based research approaches in this document imply certain security requirements 💅. Honestly, data origin authentication, data integrity, and access control are the big ones for lots of use cases in the aftermath of a disaster (see Section 4) 🫶.

Okay, so the disasters we're talking about can happen because of a natural disaster, an accident, or human error 🌪️. But intentional actions can also cause one (e.g., a terrorist attack, as mentioned in Section 2) 😭. In that case, where attackers are the ones causing the disaster on purpose, you have to be extra careful when you turn communications back on 🚨. Temporary, somewhat unreliable communications with potential limited security features might get abused by attackers 💀. They could circulate false messages to cause even more intentional chaos among people, use this less secure infrastructure to refine their targeting, or track how security and police forces are responding 🙈. Potential solutions for coping with intentionally caused disasters by attackers, and for enabling a secure communications infrastructure after one, are out of scope for this document 🚫.

The use of data-centric security schemes, like 'Ciphertext-Policy Attribute Based Encryption' (as mentioned in Section 5.1), is a big deal 🔐. These schemes encrypt the data itself, not the communication channel, so in principle they allow encrypted data to be sent over an unsecured channel ✨. Still, metadata about the encrypted data being retrieved still shows up 👀. That metadata can reveal sensitive information to a network-based attacker, even if the attacker can't decrypt the content itself 😬.

This document has summarized research directions for tackling these challenges and requirements 🧩. That includes efforts in data-centric confidentiality and access control, plus recent work on decentralized authentication of messages in a disaster-struck networking infrastructure, where routing links aren't working properly and communication capabilities are limited (see Section 5) 🦋.

---

7. Conclusion 🎀

This document has outlined some research directions for ICN when it comes to using ICN approaches to cope with large-scale disasters, whether they're natural or human-generated 🌍. It described the high-level research challenges for enabling communication after a disaster has happened, plus a general rationale for why ICN approaches could be beneficial for tackling them 💡. It also described concrete use cases and discussed how those can be addressed with ICN-based approaches 🙌.

Finally, the document gave an overview of examples of existing ICN-based solutions that address the research challenges we outlined earlier 🏆. These concrete solutions show that the communication challenges in the aftermath of a disaster really can be addressed with techniques built on ICN paradigms, which backs up our overall reasoning 👑. But there are more-detailed challenges out there too, and more research is needed in every area we discussed: efficient content distribution and routing in fragmented networks, traffic prioritization, security, and energy efficiency 🌈. The document wrapped up with an incomplete, high-level list of those open research challenges 📝.

To deploy ICN-based solutions for disaster-aftermath communication in actual mobile networks, standardized ICN baseline protocols are a must 🔥. You can't expect all user equipment in a large-scale mobile network to come from the same vendor 📱. That's why the work being done in the IRTF ICNRG is so useful: it works toward standards for concrete ICN protocols that enable interoperability among solutions from different vendors 🫶. These protocols are currently being developed in the IRTF ICNRG as Experimental specifications in the IRTF Stream, and they provide a good foundation for deploying ICN-based disaster-aftermath communication, which addresses key use cases in those situations (as outlined in this document) 💖.

---

8. IANA Considerations 🌸

This document has no IANA actions.

---

9. References 📚

9.1. Normative References 💜

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

[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, <https://www.rfc-editor.org/info/rfc6920>.

[RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., Tyson, G., Davies, E., Molinaro, A., and S. Eum, "Information-Centric Networking: Baseline Scenarios", RFC 7476, DOI 10.17487/RFC7476, March 2015, <https://www.rfc-editor.org/info/rfc7476>.

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

9.2. Informative References 🦋

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Acknowledgments 🫶

okay bestie, we have to give a shoutout to the people who made this doc happen 💖 The authors want to thank Ioannis Psaras for his useful comments ✨ They also owe a huge thank you to Christopher Wood and Daniel Corujo for valuable feedback and for suggestions on concrete text that made the document better 🙌 Joerg Ott and Dirk Trossen get a massive thank you too, for their valuable comments and input, especially on existing work from the DTN community that is highly related to the ICN approaches suggested in this document 🧚 And Akbar Rahman gets flowers 🌸 for useful comments and suggestions, particularly about existing disaster warning mechanisms in today's mobile phone networks 📱

The funding tea is next, and it's a whole thing 💜

This document has been supported by the GreenICN project (GreenICN: Architecture and Applications of Green Information-Centric Networking) 🌿 This is 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 in here belong to the authors, and they should not be read as necessarily representing the official policies or endorsements, either expressed or implied, of the GreenICN project, the European Commission, or the NICT 🙈 You can find more info at the project website: http://www.greenicn.org/ 🌈

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

---

Authors' Addresses 💌

Meet the squad! Here's where you can find each of them 🦋

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

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

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

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

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

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

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

Email: kkrama@ucr.edu

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

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

That's the whole crew, periodt 🎀✨