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