idnits 2.17.1 draft-irtf-icnrg-disaster-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 26, 2019) is 1606 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG J. Seedorf 3 Internet-Draft HFT Stuttgart - Univ. of Applied Sciences 4 Intended status: Informational M. Arumaithurai 5 Expires: May 29, 2020 University of Goettingen 6 A. Tagami 7 KDDI Research Inc. 8 K. Ramakrishnan 9 University of California 10 N. Blefari Melazzi 11 University Tor Vergata 12 November 26, 2019 14 Research Directions for Using ICN in Disaster Scenarios 15 draft-irtf-icnrg-disaster-09 17 Abstract 19 Information Centric Networking (ICN) is a new paradigm where the 20 network provides users with named content, instead of communication 21 channels between hosts. This document outlines some research 22 directions for Information Centric Networking with respect to 23 applying ICN approaches for coping with natural or human-generated, 24 large-scale disasters. This document is a product of the 25 Information-Centric Networking Research Group (ICNRG). 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 29, 2020. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Disaster Scenarios . . . . . . . . . . . . . . . . . . . . . 4 63 3. Research Challenges and Benefits of ICN . . . . . . . . . . . 5 64 3.1. High-Level Research Challenges . . . . . . . . . . . . . 5 65 3.2. How ICN can be Beneficial . . . . . . . . . . . . . . . . 7 66 3.3. ICN as Starting Point vs. Existing DTN Solutions . . . . 8 67 4. Use Cases and Requirements . . . . . . . . . . . . . . . . . 9 68 5. ICN-based Research Approaches and Open Research Challenges . 10 69 5.1. Suggested ICN-based Research Approaches . . . . . . . . . 10 70 5.2. Open Research Challenges . . . . . . . . . . . . . . . . 13 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 76 9.2. Informative References . . . . . . . . . . . . . . . . . 16 77 Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 18 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 80 1. Introduction 82 This document summarizes some research challenges for coping with 83 natural or human-generated, large-scale disasters. In particular, 84 the document discusses potential research directions for applying 85 Information Centric Networking (ICN) to address these challenges. 87 There are existing research approaches (for instance, see further the 88 work and discussions in the IETF DTN Working Group [dtnwg] ) and an 89 IETF specification [RFC5050] for Delay/Disruption Tolerant Networking 90 (DTN), which is a key necessity for communicating in the disaster 91 scenarios we are considering in this document (see further 92 Section 3.1 ). 'Disconnection tolerance' can thus be achieved with 93 these existing DTN approaches. However, while these approaches can 94 provide independence from an existing communication infrastructure 95 (which indeed may not work anymore after a disaster has happened), 96 ICN offers as key concepts suitable naming schemes and multicast 97 communication which together enable many key (publish/subscribe- 98 based) use cases for communication after a disaster (e.g. message 99 prioritisation, one-to-many delivery of important messages, or group 100 communication among rescue teams, see further Section 4 ). One could 101 add such features to existing DTN protocols and solutions; however, 102 in this document we explore the use of ICN as starting point for 103 building a communication architecture that supports (somewhat 104 limited) communication capabilities after a disaster. We discuss the 105 relationship between the ICN approaches (for enabling communication 106 after a disaster) discussed in this document with existing work from 107 the DTN community in more depth in Section 3.3 . 109 'Emergency Support and Disaster Recovery' is also listed among the 110 ICN Baseline Scenarios in [RFC7476] as a potential scenario that 'can 111 be used as a base for the evaluation of different information-centric 112 networking (ICN) approaches so that they can be tested and compared 113 against each other while showcasing their own advantages' [RFC7476] . 114 In this regard, this document complements [RFC7476] by investigating 115 the use of ICN approaches for 'Emergency Support and Disaster 116 Recovery' in depth and discussing the relationship to existing work 117 in the DTN community. 119 This document focuses on ICN-based approaches that can enable 120 communication after a disaster. These approaches reside mostly on 121 the networking layer. Other solutions for 'Emergency Support and 122 Disaster Recovery', e.g., on the application layer, may complement 123 the ICN-based networking approaches discussed in this document and 124 expand the solution space for enabling communications among users 125 after a disaster. In fact, addressing the use cases explored in this 126 document would require corresponding applications that would exploit 127 the discussed ICN-benefits on the networking layer for users. 128 However, the discussion of applications or solutions outside of the 129 networking layer are outside the scope of this document. 131 This document represents the consensus of the Information-Centric 132 Networking Research Group (ICNRG); it is not an IETF product and it 133 does not define a standard. It has been reviewed extensively by the 134 ICN Research Group (RG) members active in the specific areas of work 135 covered by the document. 137 Section 2 gives some examples of what can be considered a large-scale 138 disaster and what the effects of such disasters on communication 139 networks are. Section 3 outlines why ICN can be beneficial in such 140 scenarios and provides a high-level overview on corresponding 141 research challenges. Section 4 describes some concrete use cases and 142 requirements for disaster scenarios. In Section 5 , some concrete 143 ICN-based solutions approaches are outlined. 145 2. Disaster Scenarios 147 An enormous earthquake hit Northeastern Japan (Tohoku areas) on March 148 11, 2011, and caused extensive damages including blackouts, fires, 149 tsunamis and a nuclear crisis. The lack of information and means of 150 communication caused the isolation of several Japanese cities. This 151 impacted the safety and well-being of residents, and affected rescue 152 work, evacuation activities, and the supply chain for food and other 153 essential items. Even in the Tokyo area that is 300km away from the 154 Tohoku area, more than 100,000 people became 'returner' refugees, who 155 could not reach their homes because they had no means of public 156 transportation (the Japanese government has estimated that more than 157 6.5 million people would become returner refugees if such a 158 catastrophic disaster were to hit the Tokyo area). 160 That earthquake in Japan also showed that the current network is 161 vulnerable to disasters. Mobile phones have become the lifelines for 162 communication including safety confirmation: Besides (emergency) 163 phone calls, services in mobile networks commonly being used after a 164 disaster include network disaster SMS notifications (or SMS 'Cell 165 Broadcast' [cellbroadcast]), available in most cellular networks. 166 The aftermath of a disaster puts a high strain on available resources 167 due to the need for communication by everyone. Authorities such as 168 the President/Prime-Minister, local authorities, Police, fire 169 brigades, and rescue and medical personnel would like to inform the 170 citizens of possible shelters, food, or even of impending danger. 171 Relatives would like to communicate with each other and be informed 172 about their wellbeing. Affected citizens would like to make 173 enquiries of food distribution centres, shelters or report trapped 174 and missing people to the authorities. Moreover, damage to 175 communication equipment, in addition to the already existing heavy 176 demand for communication highlights the issue of fault-tolerance and 177 energy efficiency. 179 Additionally, disasters caused by humans such as a terrorist attack 180 may need to be considered, i.e. disasters that are caused 181 deliberately and willfully and have the element of human intent. In 182 such cases, the perpetrators could be actively harming the network by 183 launching a Denial-of-Service attack or by monitoring the network 184 passively to obtain information exchanged, even after the main 185 disaster itself has taken place. Unlike some natural disasters that 186 are to a small extent predictable using weather forecasting 187 technologies, may have a slower onset, and occur in known 188 geographical regions and seasons, terrorist attacks almost always 189 occur suddenly without any advance warning. Nevertheless, there 190 exist many commonalities between natural and human-induced disasters, 191 particularly relating to response and recovery, communication, search 192 and rescue, and coordination of volunteers. 194 The timely dissemination of information generated and requested by 195 all the affected parties during and the immediate aftermath of a 196 disaster is difficult to provide within the current context of global 197 information aggregators (such as Google, Yahoo, Bing etc.) that need 198 to index the vast amounts of specialized information related to the 199 disaster. Specialized coverage of the situation and timely 200 dissemination are key to successfully managing disaster situations. 201 We believe that network infrastructure capabilities provided by 202 Information Centric Networks can be suitable, in conjunction with 203 application and middleware assistance. 205 3. Research Challenges and Benefits of ICN 207 3.1. High-Level Research Challenges 209 Given a disaster scenario as described in Section 2, on a high-level 210 one can derive the following (incomplete) list of corresponding 211 technical challenges: 213 o Enabling usage of functional parts of the infrastructure, even 214 when these are disconnected from the rest of the network: Assuming 215 that parts of the network infrastructure (i.e. cables/links, 216 routers, mobile bases stations, ...) are functional after a 217 disaster has taken place, it is desirable to be able to continue 218 using such components for communication as much as possible. This 219 is challenging when these components are disconnected from the 220 backhaul, thus forming fragmented networks. This is especially 221 true for today's mobile networks which are comprised of a 222 centralised architecture, mandating connectivity to central 223 entities (which are located in the core of the mobile network) for 224 communication. But also in fixed networks, access to a name 225 resolution service is often necessary to access some given 226 content. 228 o Decentralised authentication, content integrity, and trust: In 229 mobile networks, users are authenticated via central entities. 230 While special services important in a disaster scenario exist and 231 may work without authentication (such as SMS 'Cell Broadcast' 232 [cellbroadcast] or emergency calls), user-to-user (or user-to- 233 authorities) communication is normally not possible without being 234 authenticated via a central entity in the network. In order to 235 communicate in fragmented or disconnected parts of a mobile 236 network, the challenge of decentralising user authentication 237 arises. Independently of the network being fixed or mobile, data 238 origin authentication and verifying the correctness of content 239 retrieved from the network is challenging when being 'offline' 240 (e.g. disconnected from servers of a security infrastructure such 241 as a PKI). As the network suddenly becomes fragmented or 242 partitioned, trust models may shift accordingly to the change in 243 authentication infrastructure being used (e.g., one may switch 244 from a PKI to a web-of-trust model such as PGP). Note that 245 blockchain-based approaches are in most cases likely not suitable 246 for the disaster scenarios considered in this document, as the 247 communication capabilities needed to find consensus for a new 248 block as well as for retrieving blocks at nodes presumably will 249 not be available (or too excessive for the remaining 250 infrastructure) after a disaster. 252 o Delivering/obtaining information and traffic prioritization in 253 congested networks: Due to broken cables, failed routers, etc., it 254 is likely that in a disaster scenario the communication network 255 has much less overall capacity for handling traffic. Thus, 256 significant congestion can be expected in parts of the 257 infrastructure. It is therefore a challenge to guarantee message 258 delivery in such a scenario. This is even more important as in 259 the case of a disaster aftermath, it may be crucial to deliver 260 certain information to recipients (e.g. warnings to citizens) with 261 higher priority than other content. 263 o Delay/Disruption Tolerant Approach: Fragmented networks make it 264 difficult to support direct end-to-end communication with small or 265 no delay. However, communication in general and especially during 266 a disaster can often tolerate some form of delay. E.g., in order 267 to know if someone's relatives are safe or not, a corresponding 268 emergency message need not necessarily be supported in an end-to- 269 end manner, but would also be helpful to the human recipient if it 270 can be tranported in a hop-by-hop fashion with some delay. For 271 these kinds of use-cases, it is sufficient to improve 272 communication resilience in order to deliver such important 273 messages. 275 o Energy Efficiency: Long-lasting power outages may lead to 276 batteries of communication devices running out, so designing 277 energy-efficient solutions is very important in order to maintain 278 a usable communication infrastructure. 280 o Contextuality: Like any communication in general, disaster 281 scenarios are inherently contextual. Aspects of geography, the 282 people affected, the rescue communities involved, the languages 283 being used and many other contextual aspects are highly relevant 284 for an efficient realization of any rescue effort and, with it, 285 the realization of the required communication. 287 3.2. How ICN can be Beneficial 289 Several aspects of ICN make related approaches attractive candidates 290 for addressing the challenges described in Section 3.1 . Below is an 291 (incomplete) list of considerations why ICN approaches can be 292 beneficial to address these challenges: 294 o Routing-by-name: ICN protocols natively route by named data 295 objects and can identify objects by names, effectively moving the 296 process of name resolution from the application layer to the 297 network layer. This functionality is very handy in a fragmented 298 network where reference to location-based, fixed addresses may not 299 work as a consequence of disruptions. For instance, name 300 resolution with ICN does not necessarily rely on the reachability 301 of application-layer servers (e.g. DNS resolvers). In highly 302 decentralised scenarios (e.g. in infrastructureless, opportunistic 303 environments) the ICN routing-by-name paradigm effectively may 304 lead to a 'replication-by-name' approach, where content is 305 replicated depending on its name. 307 o Integrity and Authentication of named data objects: ICN is built 308 around the concept of named data objects. Several proposals exist 309 for integrating the concept of 'self-certifying data' into a 310 naming scheme (see e.g. [RFC6920]). With such approaches, object 311 integrity of data retrieved from the network can be verified 312 without relying on a trusted third party or PKI. In addition, 313 given that the correct object name is known, such schemes can also 314 provide data origin authentication (see for instance Section 8.3. 315 in [RFC6920]) 317 o Content-based access control: ICN promotes a data-centric 318 communication model which naturally supports content-based 319 security (e.g. allowing access to content only to a specific user 320 or class of users) as in ICN - if desired - not the communication 321 channel is secured (encrypted) but the content itself. This 322 functionality could facilitate trusted communications among peer 323 users in isolated areas of the network where a direct 324 communication channel may not always or continuously exist. 326 o Caching: Caching content along a delivery path is an inherent 327 concept in ICN. Caching helps in handling huge amounts of 328 traffic, and can help to avoid congestion in the network (e.g. 329 congestion in backhaul links can be avoided by delivering content 330 from caches at access nodes). 332 o Sessionless: ICN does not require full end-to-end connectivity. 333 This feature facilitates a seemless aggregation between a normal 334 network and a fragmented network, which needs DTN-like message 335 forwarding. 337 o Potential to run traditional IP-based services (IP-over-ICN): 338 While ICN and DTN promote the development of novel applications 339 that fully utilize the new capabilities of the ICN/DTN network, 340 work in [Trossen2015] has shown that an ICN-enabled network can 341 transport IP-based services, either directly at IP or even at HTTP 342 level. With this, IP- and ICN/DTN-based services can coexist, 343 providing the necessary support of legacy applications to affected 344 users, while reaping any benefits from the native support for ICN 345 in future applications. 347 o Opportunities for traffic engineering and traffic prioritization: 348 ICN provides the possibility to perform traffic engineering based 349 on the name of desired content. This enables priority based 350 replication depending on the scope of a given message [Psaras2014] 351 . In addition, as [Trossen2015] , among others, have pointed out, 352 the realization of ICN services and particularly of IP-based 353 services on top of ICN provide further traffic engineering 354 opportunities. The latter not only relate to the utilization of 355 cached content, as outlined before, but to the ability to flexbily 356 adapt to route changes (important in unreliable infrastructure 357 such as in disaster scenarios), mobility support without anchor 358 points (again, important when parts of the infrastructure are 359 likely to fail) and the inherent support for multicast and 360 multihoming delivery. 362 3.3. ICN as Starting Point vs. Existing DTN Solutions 364 There has been quite some work in the DTN (Delay Tolerant Networking) 365 community on disaster communication (for instance, see further the 366 work and discussions in the IETF DTN Working Group [dtnwg] ). 367 However, most DTN work lacks important features such as publish/ 368 subscribe (pub/sub) capabilities, caching, multicast delivery, and 369 message prioritisation based on content types, which are needed in 370 the disaster scenarios we consider. One could add such features to 371 existing DTN protocols and solutions, and indeed individual proposals 372 for adding such features to DTN protocols have been made (e.g. 373 [Greifenberg2008] [Yoneki2007] propose the use of a pub/sub-based 374 multicast distribution infrastructure for DTN-based opportunistic 375 networking environments). 377 However, arguably ICN---having these intrinsic properties (as also 378 outlined above)---makes a better starting point for building a 379 communication architecture that works well before and after a 380 disaster. For a disaster-enhanced ICN system this would imply the 381 following advantages: a) ICN data mules would have built-in caches 382 and can thus return content for interests straight on, b) requests do 383 not necessarily need to be routed to a source (as with existing DTN 384 protocols), instead any data mule or end-user can in principle 385 respond to an interest, c) built-in multi-cast delivery implies 386 energy-efficient large-scale spreading of important information which 387 is crucial in disaster scenarios, and d) pub/sub extension for 388 popular ICN implementations exist [COPSS2011] which are very suitable 389 for efficient group communication in disasters and provide better 390 reliability, timeliness and scalability as compared to existing pub/ 391 sub approaches in DTN [Greifenberg2008] [Yoneki2007] . 393 Finally, most DTN routing algorithms have been solely designed for 394 particular DTN scenarios. By extending ICN approaches for DTN-like 395 scenarios, one ensures that a solution works in regular (i.e. well- 396 connected) settings just as well (which can be important in reality, 397 where a routing algorithm should work before and after a disaster). 398 It is thus reasonable to start with existing ICN approaches and 399 extend them with the necessary features needed in disaster scenarios. 400 In any case, solutions for disaster scenarios need a combination of 401 ICN-features and DTN-capabilities. 403 4. Use Cases and Requirements 405 This Section describes some use cases for the aforementioned disaster 406 scenario (as outlined in Section 2 ) and discusses the corresponding 407 technical requirements for enabling these use cases. 409 o Delivering Messages to Relatives/Friends: After a disaster 410 strikes, citizens want to confirm to each other that they are 411 safe. For instance, shortly after a large disaster (e.g., 412 Earthquake, Tornado), people have moved to different refugee 413 shelters. The mobile network is not fully recovered and is 414 fragmented, but some base stations are functional. This use case 415 imposes the following high-level requirements: a) People must be 416 able to communicate with others in the same network fragment, b) 417 people must be able to communicate with others that are located in 418 different fragmented parts of the overall network. More 419 concretely, the following requirements are needed to enable the 420 use case: a) a mechanism for a scalable message forwarding scheme 421 that dynamically adapts to changing conditions in disconnected 422 networks, b) DTN-like mechanisms for getting information from 423 disconnected island to another disconnected island, c) source 424 authentication and content integrity so that users can confirm 425 that the messages they receive are indeed from their relatives or 426 friends and have not been tampered with, and d) the support for 427 contextual caching in order to provide the right information to 428 the right set of affected people in the most efficient manner. 430 o Spreading Crucial Information to Citizens: State authorities want 431 to be able to convey important information (e.g. warnings, or 432 information on where to go or how to behave) to citizens. These 433 kinds of information shall reach as many citizens as possible. 434 i.e. Crucial content from legal authorities shall potentially 435 reach all users in time. The technical requirements that can be 436 derived from this use case are: a) source authentication and 437 content integrity, such that citizens can confirm the correctness 438 and authenticity of messages sent by authorities, b) mechanisms 439 that guarantee the timeliness and loss-free delivery of such 440 information, which may include techniques for prioritizing certain 441 messages in the network depending on who sent them, and c) DTN- 442 like mechanisms for getting information from disconnected island 443 to another disconnected island. 445 It can be observed that different key use cases for disaster 446 scenarios imply overlapping and similar technical requirements for 447 fulfilling them. As discussed in Section 3.2 , ICN approaches are 448 envisioned to be very suitable for addressing these requirements with 449 actual technical solutions. In [Robitzsch2015] , a more elaborate 450 set of requirements is provided that addresses, among disaster 451 scenarios, a communication infrastructure for communities facing 452 several geographic, economic and political challenges. 454 5. ICN-based Research Approaches and Open Research Challenges 456 This section outlines some ICN-based research approaches that aim at 457 fulfilling the previously mentioned use cases and requirements 458 (Section 5.1). Most of these works provide proof-of-concept type 459 soluions, addressing singular challenges. Thus, several open issues 460 remain which are summarized in Section 5.2. 462 5.1. Suggested ICN-based Research Approaches 464 The research community has investigated ICN-based solutions to 465 address the aforementioned challenges in disaster scenarios. 466 Overall, the focus is on delivery of messages and not real-time 467 communication. While most probably users would like to conduct real- 468 time voice/video calls after a disaster, in the extreme scenario we 469 consider (with users being scattered over different fragmented 470 networks, see Section 2), somewhat delayed message delivery appears 471 to be inevitable, and full-duplex real-time communication seems 472 infeasible to achieve (unless users are in close proximity). Thus, 473 the assumption is that - for a certain amount of time at least (i.e. 474 the initial period until the regular communication infrastructure has 475 been repaired) - users would need to live with message delivery and 476 publish/subscribe services but without real-time communication. 477 Note, however, that a) in principle ICN can support VoIP calls; thus, 478 if users are in close proximity, (duplex) voice communication via ICN 479 is possible [Gusev2015], and b) delayed message delivery can very 480 well include (recorded) voice messages. 482 o ICN 'data mules': To facilitate the exchange of messages between 483 different network fragments, mobile entitites can act as ICN 'data 484 mules' which are equipped with storage space and move around the 485 disaster-stricken area gathering information to be disseminated. 486 As the mules move around, they deliver messages to other 487 individuals or points of attachment to different fragments of the 488 network. These 'data mules' could have a pre-determined path (an 489 ambulance going to and from a hospital), a fixed path (drone/robot 490 assigned specifically to do so) or a completely random path 491 (doctors moving from one camp to another). An example of a many- 492 to-many communication service for fragmented networks based on ICN 493 data mules has been proposed in [Tagami2016]. 495 o Priority-dependent or popularity-dependent name-based replication: 496 By allowing spatial and temporal scoping of named messages, 497 priority based replication depending on the scope of a given 498 message is possible. Clearly, spreading information in disaster 499 cases involves space and time factors that have to be taken into 500 account as messages spread. A concrete approach for such scope- 501 based prioritisation of ICN messages in disasters, called 'NREP', 502 has been proposed [Psaras2014] , where ICN messages have 503 attributes such as user-defined priority, space, and temporal- 504 validity. These attributes are then taken into account when 505 prioritizing messages. In [Psaras2014] , evaluations show how 506 this approach can be applied to the use case 'Delivering Messages 507 to Relatives/Friends' decribed in Section 4. In [Seedorf2016], a 508 scheme is presented that enables to estimate the popularity of ICN 509 interest messages in a completely decentralized manner among data 510 mules in a scenario with random, unpredictable movements of ICN 511 data mules. The approach exploits the use of nonces associated 512 with end user requests, common in most ICN architectures. It 513 enables for a given ICN data mule to estimate the overall 514 popularity (among end-users) of a given ICN interest message. 515 This enables data mules to optimize content dissemination with 516 limited caching capabilities by prioritizing interests based on 517 their popularity. 519 o Information Resilience through Decentralised Forwarding: In a 520 dynamic or disruptive environment, such as the aftermath of a 521 disaster, both users and content servers may dynamically join and 522 leave the network (due to mobility or network fragmentation). 523 Thus, users might attach to the network and request content when 524 the network is fragmented and the corresponding content origin is 525 not reachable. In order to increase information resilience, 526 content cached both in in-network caches and in end-user devices 527 should be exploited. A concrete approach for the exploitation of 528 content cached in user devices is presented in [Sourlas2015] . The 529 proposal in [Sourlas2015] includes enhancements to the NDN router 530 design, as well as an alternative Interest forwarding scheme which 531 enables users to retrieve cached content when the network is 532 fragmented and the content origin is not reachable. Evaluations 533 show that this approach is a valid tool for the retrieval of 534 cached content in disruptive cases and can be applied to tackle 535 the challenges presented in Section 3.1 . 537 o Energy Efficiency: A large-scale disaster causes a large-scale 538 blackout and thus a number of base stations (BSs) will be operated 539 by their batteries. Capacities of such batteries are not large 540 enough to provide cellular communication for several days after 541 the disaster. In order to prolong the batteries' life from one 542 day to several days, different techniques need to be explored: 543 Priority control, cell-zooming, and collaborative upload. Cell 544 zooming switches-off some of the BSs because switching-off is the 545 only way to reduce power consumed at the idle time. In cell 546 zooming, areas covered by such inactive BSs are covered by the 547 active BSs. Collaborative communication is complementary to cell 548 zooming and reduces power proportional to a load of a BS. The 549 load represents cellular frequency resources. In collaborative 550 communication, end-devices delegate sending and receiving messages 551 to and from a base station to a representative end-device of which 552 radio propagation quality is better. The design of an ICN-based 553 publish/subscribe protocol that incorporates collaborative upload 554 is ongoing work. In particular, the integration of collaborative 555 upload techniques into the COPSS (Content Oriented Publish/ 556 Subscribe System)} framework is envisioned [COPSS2011] . 558 o Data-centric confidentiality and access control: In ICN, the 559 requested content is not anymore associated to a trusted server or 560 an endpoint location, but it can be retrieved from any network 561 cache or a replica server. This call for 'data-centric' security, 562 where security relies on information exclusively contained in the 563 message itself, or, if extra information provided by trusted 564 entities is needed, this should be gathered through offline, 565 asynchronous, and non interactive communication, rather than from 566 an explicit online interactive handshake with trusted servers. 567 The ability to guarantee security without any online entities is 568 particularly important in disaster scenarios with fragmented 569 networks. One concrete cryptographic technique is 'Ciphertext- 570 Policy Attribute Based Encryption' (CP-ABE), allowing a party to 571 encrypt a content specifying a policy, which consists in a Boolean 572 expression over attributes, that must be satisfied by those who 573 want to decrypt such content. Such encryption schemes tie 574 confidentiality and access-control to the transferred data, which 575 can be transmitted also in an unsecured channel. These schemes 576 enable the source to specify the set of nodes allowed to later on 577 decrypt the content during the encryption process. 579 o Decentralised authentication of messages: Self-certifying names 580 provide the property that any entity in a distributed system can 581 verify the binding between a corresponding public key and the 582 self-certifying name without relying on a trusted third party. 583 Self-certifying names thus provide a decentralized form of data 584 origin authentication. However, self-certifying names lack a 585 binding with a corresponding real-world identity. Given the 586 decentralised nature of a disaster scenario, a PKI-based approach 587 for binding self-certifying names with real-world identities is 588 not feasible. Instead, a Web-of-Trust can be used to provide this 589 binding. Not only are the cryptographic signatures used within a 590 Web-of-Trust independent of any central authority; there are also 591 technical means for making the inherent trust relationships of a 592 Web-of-Trust available to network entities in a decentralised, 593 'offline' fashion, such that information received can be assessed 594 based on these trust relationships. A concrete scheme for such an 595 approach has been published in [Seedorf2014] , where also concrete 596 examples for fulfilling the use case 'Delivering Messages to 597 Relatives/Friends' with this approach are given. 599 5.2. Open Research Challenges 601 The proposed solutions in Section 5.1 investigate how ICN approaches 602 can in principal address some of the outlined challenges. However, 603 several research challenges remain open and still need to be 604 addressed. The following (incomplete) list summarizes some 605 unanswered research questions and items that are being investigated 606 by researchers: 608 o Evaluation of the proposed mechanisms (and their scalability) in 609 realistic large-scale testbeds with actual, mature implementations 610 (compared to simulations or emulations) 612 o Specifying for each mechanism suggested to what exact extent ICN 613 deployment in the network and at user equipment is required or 614 would be necessary, before and after a disaster. 616 o How to best use DTN and ICN approaches for an optimal overall 617 combination of techniques? 619 o How do data-centric encryption schemes scale and perform in large- 620 scale, realistic evaluations? 622 o Build and test real (i.e. not early-stage prototypes) ICN data 623 mules by means of implementation and integration with lower layer 624 hardware; conduct evaluations of decentralised forwarding schemes 625 in real environments with these actual ICN data mules 627 o How to derive concrete policies for ICN-style name-based 628 prioritized spreading of information? 630 o Further investigate, develop, and verify mechanisms that address 631 energy efficiency requirements for communication after a disaster 633 o How to properly disseminate authenticated object names to nodes 634 (for decentralised integrity verification and authentication) 635 before a disaster, or how to retrieve new authenticated object 636 names by nodes during a disaster? 638 6. Security Considerations 640 This document does not define a new protocol (or protocol extension) 641 or a particular mechanism, and therefore introduces no specific new 642 security considerations. General security considerations for 643 Information-Centric Networking -- which also apply when using ICN 644 networking techniques to communicate after a disaster -- are 645 discussed in [RFC7945]. 647 The after-disaster communication scenario which is the focus of this 648 document raises particular attention to decentralised authentication, 649 content integrity, and trust as key research challenges (as outlined 650 in Section 3.1). The corresponding use cases and ICN-based research 651 approaches discussed in this document thus imply certain security 652 requirements. In particular data origin authentication, data 653 integrity, and access control are key requirements for many use cases 654 in the aftermath of a disaster (see Section 4). 656 In principle, the kinds of disasters discussed in this document can 657 happen as a result of a natural disaster, accident or by human-error. 658 However, also intentional actions can cause such a disaster (e.g., a 659 terrorist attack, as mentioned in Section 2). In this case, i.e., 660 intentionally caused disasters by attackers, special attention needs 661 to be paid when re-enabling communications as temporary, somewhat un- 662 reliable communications with potential limited security features may 663 be anticipated and abused by attackers (e.g., to circulate false 664 messages to cause further intentional chaos among the human 665 population). Potential solutions on how to cope with intentionally 666 caused disasters by attackers and on how to enable a secure 667 communications infrastructure after such an intentionally caused 668 disaster are out of scope of this document. 670 This document has summarized research directions for addressing these 671 challenges and requirements, such as efforts in data-centric 672 confidentiality and access control as well as recent works for 673 decentralised authentication of messages in a disaster-struck 674 networking infrastructure with non-functional routing links and 675 limited communication capabilities (see Section 5). 677 7. Conclusion 679 This document has outlined some research directions for Information 680 Centric Networking (ICN) with respect to applying ICN approaches for 681 coping with natural or human-generated, large-scale disasters. The 682 document has described high-level research challenges for enabling 683 communication after a disaster has happened as well as a general 684 rationale why ICN approaches could be beneficial to address these 685 challenges. Further, concrete use cases have been described and how 686 these can be addressed with ICN-based approaches has been discussed. 688 Finally, the document provided an overview of examples of existing 689 ICN-based solutions that address the previously outlined research 690 challenges. These concrete solutions demonstrate that indeed the 691 communication challenges in the aftermath of a disaster can be 692 addressed with techniques that have ICN paradigms at their base, 693 validating our overall reasoning. However, further, more detailed 694 challenges exist and more research is necessary in all areas 695 discussed: efficient content distribution and routing in fragmented 696 networks, traffic prioritization, security, and energy-efficiency. 697 An incomplete, high-level list of such open research challenges has 698 concluded the document. 700 In order to deploy ICN-based solutions for disaster-aftermath 701 communication in actual mobile networks, standardized ICN baseline 702 protocols are a must: It is unlikely to expect all user equipment in 703 a large-scale mobile network to be from the same vendor. In this 704 respect, the work being done in the IRTF ICNRG is very useful as it 705 works towards standards for concrete ICN protocols that enable 706 interopability among solutions from different vendors. These 707 protocols - currently being standardized in the IRTF INCRG - provide 708 a good foundation for deploying ICN-based disaster-aftermath 709 communication and thereby addressing key use cases that arise in such 710 situations (as outlined in this document). 712 8. IANA Considerations 714 This document requests no IANA actions. 716 9. References 718 9.1. Normative References 720 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 721 Specification", RFC 5050, DOI 10.17487/RFC5050, November 722 2007, . 724 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 725 Keranen, A., and P. Hallam-Baker, "Naming Things with 726 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 727 . 729 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 730 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 731 "Information-Centric Networking: Baseline Scenarios", 732 RFC 7476, DOI 10.17487/RFC7476, March 2015, 733 . 735 [RFC7945] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., 736 and G. Boggia, "Information-Centric Networking: Evaluation 737 and Security Considerations", RFC 7945, 738 DOI 10.17487/RFC7945, September 2016, 739 . 741 9.2. Informative References 743 [cellbroadcast] 744 Wikipedia, "Cell Broadcast - Wikipedia, 745 https://en.wikipedia.org/wiki/Cell_Broadcast", (online). 747 [COPSS2011] 748 Chen, J., Arumaithurai, M., Jiao, L., Fu, X., and K. 749 Ramakrishnan, "COPSS: An Efficient Content Oriented 750 Publish/Subscribe System", Seventh ACM/IEEE Symposium on 751 Architectures for Networking and Communications Systems 752 (ANCS), 2011. 754 [dtnwg] Fall, K. and J. Ott, "Delay/Disruption Tolerant Networking 755 WG", https://tools.ietf.org/wg/dtn/. 757 [Greifenberg2008] 758 Greifenberg, J. and D. Kutscher, "Efficient publish/ 759 subscribe-based multicast for opportunistic networking 760 with self-organized resource utilization", Advanced 761 Information Networking and Applications-Workshops, 2008. 763 [Gusev2015] 764 Gusev, P. and J. Burke, "NDN-RTC: Real-Time 765 Videoconferencing over Named Data Networking", 2nd ACM 766 Conference on Information-Centric Networking (ICN 2015), 767 Sep. 30 - Oct. 2, San Francisco, CA, USA. 769 [Psaras2014] 770 Psaras, I., Saino, L., Arumaithurai, M., Ramakrishnan, K., 771 and G. Pavlou, "Name-Based Replication Priorities in 772 Disaster Cases", 2nd Workshop on Name Oriented Mobility 773 (NOM), 2014. 775 [Robitzsch2015] 776 Robitzsch, S., Trossen, D., Theodorou, C., Barker, T., and 777 A. Sathiaseel, "D2.1: Usage Scenarios and 778 Requirements"", H2020 project RIFE, public deliverable, 779 2015. 781 [Seedorf2014] 782 Seedorf, J., Kutscher, D., and F. Schneider, 783 "Decentralised Binding of Self-Certifying Names to Real- 784 World Identities for Assessment of Third-Party Messages in 785 Fragmented Mobile Networks", 2nd Workshop on Name 786 Oriented Mobility (NOM), 2014. 788 [Seedorf2016] 789 Seedorf, J., Kutscher, D., and B. Gill, "Decentralised 790 Interest Counter Aggregation for ICN in Disaster 791 Scenarios", Workshop on Information Centric Networking 792 Solutions for Real World Applications (ICNSRA), 2016. 794 [Sourlas2015] 795 Sourlas, V., Tassiulas, L., Psaras, I., and G. Pavlou, 796 "Information Resilience through User-Assisted Caching in 797 Disruptive Content-Centric Networks", 14th IFIP 798 NETWORKING, May 2015. 800 [Tagami2016] 801 Tagami, A., Yagyu, T., Sugiyama, K., Arumaithurai, M., 802 Nakamura, K., Hasegawa, T., Asami, T., and K. 803 Ramakrishnan, "Name-based Push/Pull Message Dissemination 804 for Disaster Message Board", The 22nd IEEE International 805 Symposium on Local and Metropolitan Area Networks 806 (LANMAN), 2016. 808 [Trossen2015] 809 Trossen, D., "IP over ICN - The better IP?", 2015 810 European Conference onNetworks and Communications (EuCNC), 811 June/July 2015, pp. 413 - 417. 813 [Yoneki2007] 814 Yoneki, E., Hui, P., Chan, S., and J. Crowcroft, "A socio- 815 aware overlay for publish/subscribe communication in delay 816 tolerant networks", Proceedings of the 10th ACM Symposium 817 on Modeling, Analysis, and Simulation of Wireless and 818 Mobile Systems, 2007. 820 Appendix A. Acknowledgment 822 The authors would like to thank Ioannis Psaras for useful comments. 823 Also, the authors are grateful to Christopher Wood and Daniel Corujo 824 for valuable feedback and suggestions on concrete text for improving 825 the document. Further, the authors would like to thank Joerg Ott and 826 Dirk Trossen for valuable comments and input, in particular regarding 827 existing work from the DTN community which is highly related to the 828 ICN approaches suggested in this document. Also, Akbar Rahman 829 provided useful comments and usggestions, in particular regarding 830 existing disaster warning mechanisms in today's mobile phone 831 networks. 833 This document has been supported by the GreenICN project (GreenICN: 834 Architecture and Applications of Green Information Centric Networking 835 ), a research project supported jointly by the European Commission 836 under its 7th Framework Program (contract no. 608518) and the 837 National Institute of Information and Communications Technology 838 (NICT) in Japan (contract no. 167). The views and conclusions 839 contained herein are those of the authors and should not be 840 interpreted as necessarily representing the official policies or 841 endorsements, either expressed or implied, of the GreenICN project, 842 the European Commission, or NICT. More information is available at 843 the project web site http://www.greenicn.org/. 845 Authors' Addresses 847 Jan Seedorf 848 HFT Stuttgart - Univ. of Applied Sciences 849 Schellingstrasse 24 850 Stuttgart 70174 851 Germany 853 Phone: +49 711 8926 2801 854 Fax: +49 711 8926 2553 855 Email: jan.seedorf@hft-stuttgart.de 856 Mayutan Arumaithurai 857 University of Goettingen 858 Goldschmidt Str. 7 859 Goettingen 37077 860 Germany 862 Phone: +49 551 39 172046 863 Fax: +49 551 39 14416 864 Email: arumaithurai@informatik.uni-goettingen.de 866 Atsushi Tagami 867 KDDI Research Inc. 868 2-1-15 Ohara 869 Fujimino, Saitama 356-85025 870 Japan 872 Phone: +81 49 278 73651 873 Fax: +81 49 278 7510 874 Email: tagami@kddi-research.jp 876 K. K. Ramakrishnan 877 University of California 878 Riverside CA 879 USA 881 Email: kkramakrishnan@yahoo.com 883 Nicola Blefari Melazzi 884 University Tor Vergata 885 Via del Politecnico, 1 886 Roma 00133 887 Italy 889 Phone: +39 06 7259 7501 890 Fax: +39 06 7259 7435 891 Email: blefari@uniroma2.it