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