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