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