idnits 2.17.1 draft-seedorf-icn-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 (March 3, 2015) is 3340 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 NEC 4 Intended status: Informational M. Arumaithurai 5 Expires: September 4, 2015 University of Goettingen 6 A. Tagami 7 KDDI R&D Labs 8 K. Ramakrishnan 9 University of California 10 N. Blefari Melazzi 11 University Tor Vergata 12 March 3, 2015 14 Using ICN in disaster scenarios 15 draft-seedorf-icn-disaster-03 17 Abstract 19 Information Centric Networking is a new paradigm where the network 20 provides users with named content, instead of communication channels 21 between hosts. This document outlines some research directions for 22 Information Centric Networking (ICN) with respect to applying ICN 23 approaches for coping with natural or human-generated, large-scale 24 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 http://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 September 4, 2015. 43 Copyright Notice 45 Copyright (c) 2015 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 (http://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 . . . . . . . . . . . . . . . . 5 65 4. Use Cases and Requirements . . . . . . . . . . . . . . . . . 6 66 5. Solution Design . . . . . . . . . . . . . . . . . . . . . . . 7 67 6. The GreenICN Project . . . . . . . . . . . . . . . . . . . . 9 68 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 71 8.2. Informative References . . . . . . . . . . . . . . . . . 10 72 Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 This document summarizes some research challenges for coping with 78 natural or human-generated, large-scale disasters. Further, the 79 document discusses potential directions for applying Information 80 Centric Networking (ICN) to address these challenges. 82 Section 2 gives some examples of what can be considered a large-scale 83 disaster and what the effects of such disasters on communication 84 networks are. Section 3 outlines why ICN can be beneficial in such 85 scenarios and provides a high-level overview on corresponding 86 research challenges. Section 4 describes some concrete use cases and 87 requirements for disaster scenarios. In Section 5, some concrete 88 ICN-based solutions approaches are outlined. Related research 89 activities are ongoing in the GreenICN research project; Section 6 90 provides an overview of this project. 92 2. Disaster Scenarios 94 An enormous earthquake hit Northeastern Japan (Tohoku areas) on March 95 11, 2011, and caused extensive damages including blackouts, fires, 96 tsunamis and a nuclear crisis. The lack of information and means of 97 communication caused the isolation of several Japanese cities. This 98 impacted the safety and well-being of residents, and affected rescue 99 work, evacuation activities, and the supply chain for food and other 100 essential items. Even in the Tokyo area that is 300km away from the 101 Tohoku area, more than 100,000 people became 'returner' refugees, who 102 could not reach their homes because they had no means of public 103 transportation (the Japanese government has estimated that more than 104 6.5 million people would become returner refugees if such a 105 catastrophic disaster were to hit the Tokyo area). 107 That earthquake in Japan also showed that the current network is 108 vulnerable against disasters and that mobile phones have become the 109 lifelines for communication including safety confirmation. The 110 aftermath of a disaster puts a high strain on available resources due 111 to the need for communication by everyone. Authorities such as the 112 President/Prime-Minister, local authorities, Police, fire brigades, 113 and rescue and medical personnel would like to inform the citizens of 114 possible shelters, food, or even of impending danger. Relatives 115 would like to communicate with each other and be informed about their 116 wellbeing. Affected citizens would like to make enquiries of food 117 distribution centres, shelters or report trapped, missing people to 118 the authorities. Moreover, damage to communication equipment, in 119 addition to the already existing heavy demand for communication 120 highlights the issue of fault-tolerance and energy efficiency. 122 Additionally, disasters caused by humans such as a terrorist attack 123 may need to be considered, i.e. disasters that are caused 124 deliberately and willfully and have the element of human intent. In 125 such cases, the perpetrators could be actively harming the network by 126 launching a Denial-of-Service attack or by monitoring the network 127 passively to obtain information exchanged, even after the main 128 disaster itself has taken place. Unlike some natural disasters that 129 are predictable using weather forecasting technologies and have a 130 slower onset and occur in known geographical regions and seasons, 131 terrorist attacks may occur suddenly without any advance warning. 132 Nevertheless, there exist many commonalities between natural and 133 human-induced disasters, particularly relating to response and 134 recovery, communication, search and rescue, and coordination of 135 volunteers. 137 The timely dissemination of information generated and requested by 138 all the affected parties during and the immediate aftermath of a 139 disaster is difficult to provide within the current context of global 140 information aggregators (such as Google, Yahoo, Bing etc.) that need 141 to index the vast amounts of specialized information related to the 142 disaster. Specialized coverage of the situation and timely 143 dissemination are key to successfully managing disaster situations. 144 We believe that network infrastructure capability provided by 145 Information Centric Networks can be suitable, in conjunction with 146 application and middleware assistance. 148 3. Research Challenges and Benefits of ICN 150 3.1. High-Level Research Challenges 152 Given a disaster scenario as described in Section 2, on a high-level 153 one can derive the following (incomplete) list of corresponding 154 technical challenges: 156 o Enabling usage of functional parts of the infrastructure, even 157 when these are disconnected from the rest of the network: Assuming 158 that parts of the network infrastructure (i.e. cables/links, 159 routers, mobile bases stations, ...) are functional after a 160 disaster has taken place, it is desirable to be able to continue 161 using such components for communication as much as possible. This 162 is challenging when these components are disconnected from the 163 backhaul, thus forming fragmented networks. This is especially 164 true for today's mobile networks which are comprised of a 165 centralised architecture, mandating connectivity to central 166 entities (which are located in the core of the mobile network) for 167 communication. But also in fixed networks, access to a name 168 resolution service is often necessary to access some given 169 content. 171 o Decentralised authentication: In mobile networks, users are 172 authenticated via central entities. In order to communicate in 173 fragmented or disconnected parts of a mobile network, the 174 challenge of decentralising such user authentication arises. 175 Independently of the network being fixed or mobile, data origin 176 authentication of content retrieved from the network is 177 challenging when being 'offline' (e.g. disconnected from servers 178 of a security infrastructure such as a PKI). 180 o Delivering/obtaining information in congested networks: Due to 181 broken cables, failed routers, etc., it is likely that in a 182 disaster scenario the communication network has much less overall 183 capacity for handling traffic. Thus, significant congestion can 184 be expected in parts of the infrastructure. It is therefore a 185 challenge to guarantee message delivery in such a scenario. This 186 is even more important as in the case of a disaster aftermath, it 187 may be crucial to deliver certain information to recipients (e.g. 188 warnings to citizens). 190 o Delay/Disruption Tolerant Approach: Fragmented networks makes it 191 difficult to support end-to-end communication. However, 192 communication in general and especially during disaster can 193 tolerate some form of delay. E.g. in order to know if his/her 194 relatives are safe or a 'SOS' call need not be supported in an 195 end-to-end manner. It is sufficient to improve communication 196 resilience in order to deliver such important messages. 198 o Energy Efficiency: Long-lasting power outages may lead to 199 batteries of communication devices running out, so designing 200 energy-efficient solutions is very important in order to maintain 201 a usable communication infrastructure. 203 The list above is most likely incomplete; future revisions of this 204 document intend to add additional challenges to the list. 206 3.2. How ICN can be Beneficial 208 Several aspects of ICN make related approaches attractive candidates 209 for addressing the challenges described in Section 3.1. Below is an 210 (incomplete) list of considerations why ICN approaches can be 211 beneficial to address these challenges: 213 o Routing-by-name: ICN protocols natively route by named data 214 objects and can identify objects by names, effectively moving the 215 process of name resolution from the application layer to the 216 network layer. This functionality is very handy in a fragmented 217 network where reference to location-based, fixed addresses may not 218 work as a consequence of disruptions. For instance, name 219 resolution with ICN does not necessarily rely on the reachability 220 of application-layer servers (e.g. DNS resolvers). In highly 221 decentralised scenarios (e.g. in infrastructureless, opportunistic 222 environments) the ICN routing-by-name paradigm effectively may 223 lead to a 'replication-by-name' approach, where content is 224 replicated depending on its name. 226 o Authentication of named data objects: ICN is built around the 227 concept of named data objects. Several proposals exist for 228 integrating the concept of 'self-certifying data' into a naming 229 scheme (see e.g. [RFC6920]). With such approaches, the origin of 230 data retrieved from the network can be authenticated without 231 relying on a trusted third party or PKI. 233 o Content-based access control: ICN can regulate access to data 234 objects (e.g. only to a specific user or class of users) by means 235 of content-based security; this functionality could facilitate 236 trusted communications among peer users in isolated areas of the 237 network. 239 o Caching: Caching content along a delivery path is an inherent 240 concept in ICN. Caching helps in handling huge amounts of 241 traffic, and can help to avoid congestion in the network (e.g. 242 congestion in backhaul links can be avoided by delivering content 243 from caches at access nodes). 245 o Sessionless: ICN does not require full end-to-end connectivity. 246 This feature facilitates a seemless aggregation between a normal 247 network and a fragmented network, which needs DTN-like message 248 forwarding. 250 The list above is most likely incomplete; future revisions of this 251 document intend to add more considerations to the list and to argue 252 in more detail why ICN is suitable for addressing the aforementioned 253 research challenges. 255 4. Use Cases and Requirements 257 This Section describes some use cases for the aforementioned disaster 258 scenario (as outlined in Section 2) and discusses the corresponding 259 technical requirements for enabling these use cases. 261 o Delivering Messages to Relatives/Friends: After a disaster 262 strikes, citizens want to confirm to each other that they are 263 safe. For instance, shortly after a large disaster (e.g., 264 Earthquake, Tornado), people have moved to different refugee 265 shelters. The mobile network is not fully recovered and is 266 fragmented, but some base stations are functional. This use case 267 imposes the following high-level requirements: a) People must be 268 able to communicate with others in the same network fragment, b) 269 people must be able to communicate with others that are located in 270 different fragmented parts of the overall network. More 271 concretely, the following requirements are needed to enable the 272 use case: a) a mechanism for scalable message forwarding scheme 273 that dynamically adapts to changing conditions in disconnected 274 networks, b) DTN-like mechanisms for getting information from 275 disconnected island to another disconnected island, and c) data 276 origin authentication so that users can confirm that the messages 277 they receive are indeed from their relatives or friends. 279 o Spreading Crucial Information to Citizens: State authorities want 280 to be able to convey important information (e.g. warnings, or 281 information on where to go or how to behave) to citizens. These 282 kinds of information shall reach as many citizens as possible. 284 i.e. Crucial content from legal authorities shall potentially 285 reach all users in time. The technical requirements that can be 286 derived from this use case are: a) Data origin authentication, 287 such that citizens can confrim the authenticity of messages sent 288 by authorities, b) mechanisms that guarantee the timeliness and 289 loss-free delivery of such information, which may include 290 techniques for prioritizing certain messages in the network 291 depending on who sent them, and c) DTN-like mechanisms for getting 292 information from disconnected island to another disconnected 293 island. 295 It can be observed that different key use cases for disaster 296 scenarios imply overlapping and similar technical requirements for 297 fulfilling them. As discussed in Section 3.2, ICN approaches are 298 envisioned to be very suitable for addressing these requirements with 299 actual technical solutions. 301 5. Solution Design 303 This Section outlines some ICN-based approaches that aim at 304 fulfilling the previously mentioned use cases and requirements. 306 o ICN 'data mules': To facilitate the exchange of messages between 307 different network fragments, mobile entitites can act as ICN 'data 308 mules' which are equipped with storage space and move around the 309 disaster-stricken area gathering information to be disseminated. 310 As the mules move around, they deliver messages to other 311 individuals or points of attachment to different fragments of the 312 network. These 'data mules' could have a pre-determined path (an 313 ambulance going to and fro from a hospital), a fixed path (drone/ 314 robot assigned specifically to do so) or a completely random path 315 (doctors moving from one camp to another). 317 o Priority dependent Name-based replication: By allowing spatial and 318 temporal scoping of named messages, priority based replication 319 depending on the scope of a given message is possible. Clearly, 320 spreading information in disaster cases involves space and time 321 factors that have to be taken into account as messages spread. A 322 concrete approach for such scope-based prioritisation of ICN 323 messages in disasters, called 'NREP', has been proposed 324 [Psaras2014], where ICN messages have attributes such as user- 325 defined priority, space, and temporal-validity. These attributes 326 are then taken into account when prioritizing messages. In 327 [Psaras2014], evaluations show how this approach can be applied to 328 the use case 'Delivering Messages to Relatives/Friends' decribed 329 in Section 4 331 o Energy Efficiency: A large-scale disaster causes a large-scale 332 blackout and thus a number of base stations (BSs) will be operated 333 by their batteries. Capacities of such batteries are not large 334 enough to provide cellular communication for several days after 335 the disaster. In order to prolong the batteries' life from one 336 day to several days, different techniques need to be explored: 337 Priority control, cell-zooming, and collaborative upload. Cell 338 zooming switches-off some of the BSs because switching-off is the 339 only way to reduce power consumed at the idle time. In cell 340 zooming, areas covered by such inactive BSs are covered by the 341 active BSs. Collaborative communication is complementary to cell 342 zooming and reduces power proportional to a load of a BS. The 343 load represents cellular frequency resources. In collaborative 344 communication, end-devices delegate sending and receiving messages 345 to and from a base station to a representative end-device of which 346 radio propagation quality is better. The design of an ICN-based 347 publish/subscribe protocol that incorporates collaborative upload 348 is ongoing work. In particular, the integration of collaborative 349 upload techniques into the COPSS (Content Oriented Publish/ 350 Subscribe System)} framework is envisioned [COPSS2011]. 352 o Data-centric confidentiality and access control: In ICN, the 353 requested content is not anymore associated to a trusted server or 354 an endpoint location, but it can be retrieved from any network 355 cache or a replica server. This call for 'data-centric' security, 356 where security relies on information exclusively contained in the 357 message itself, or, if extra information provided by trusted 358 entities is needed, this should be gathered through offline, 359 asynchronous, and non interactive communication, rather than from 360 an explicit online interactive handshake with trusted servers. 361 The ability to guarantee security without any online entities is 362 particularly important in disaster scenarios with fragmented 363 networks. One concrete cryptographic technique is 'Ciphertext- 364 Policy Attribute Based Encryption' (CP-ABE), allowing a party to 365 encrypt a content specifying a policy, which consists in a Boolean 366 expression over attributes, that must be satisfied by those who 367 want to decrypt such content. Such encryption schemes tie 368 confidentiality and access-control to the transferred data, which 369 can be transmitted also in an unsecured channel, enabling the 370 source to specify the set of nodes allowed to decrypt. 372 o Decentralised authentication of messages: Self-certifying names 373 provide the property that any entity in a distributed system can 374 verify the binding between a corresponding public key and the 375 self-certifying name without relying on a trusted third party. 376 Self-certifying names thus provide a decentralized form of data 377 origin authentication. However, self-certifying names lack a 378 binding with a corresponding real-world identity. Given the 379 decentralised nature of a disaster scenario, a PKI-based approach 380 for binding self-certifying names with real-world identities is 381 not feasible. Instead, a Web-of-Trust can be used to provide this 382 binding. Not only are the cryptograohic signatures used within a 383 Web-of-Trust independent of any central authority; there are also 384 technical means for making the inherent trust relationships of a 385 Web-of-Trust available to network entities in a decentralised, 386 'offline' fashion, such that information received can be assessed 387 based on these trust relationships. A concrete scheme for such an 388 approach has been published in [Seedorf2014], where also concrete 389 examples for fulfilling the use case 'Delivering Messages to 390 Relatives/Friends' with this approach are given. 392 6. The GreenICN Project 394 This section provides a brief overview of the GreenICN project. You 395 can find more information at the project web site 396 http://www.greenicn.org/ 398 The recently formed GreenICN project, funded by the EU and Japan, 399 aims to accelerate the practical deployment of ICN, addressing how 400 ICN networks and devices can operate in a highly scalable and energy- 401 efficient way. The project will exploit the designed infrastructure 402 to support multiple applications including the following two broad 403 exemplary scenarios: 1) The aftermath of a disaster, e.g. hurricane, 404 earthquake, tsunami, or a human-generated network breakdown when 405 energy and communication resources are at a premium and it is 406 critical to efficiently distribute disaster notification and critical 407 rescue information. Key to this is the ability to exploit fragmented 408 networks with only intermittent connectivity, the potential 409 exploitation of multiple modalities of communication and use of 410 query/response and pub/sub approaches; 2) Scalable, efficient pub/sub 411 video delivery, a key requirement in both normal and disaster 412 situations. 414 GreenICN will expose a functionality-rich API to spur the creation of 415 new applications and services expected to drive industry and 416 consumers, with special focus on the EU and Japanese environments, 417 into ICN adoption. Our team, comprising researchers with diverse 418 expertise, system and network equipment manufacturers, device 419 vendors, a startup, and mobile telecommunications operators, is very 420 well positioned to design, prototype and deploy GreenICN technology, 421 and validate usability and performance of real-world GreenICN 422 applications, contributing to create a new, low-energy, Information- 423 Centric global communications infrastructure. We also plan to make 424 contributions to standards bodies to further the adoption of ICN 425 technologies. 427 7. Conclusion 429 This document outlines some research directions for Information 430 Centric Networking (ICN) with respect to applying ICN approaches for 431 coping with natural or human-generated, large-scale disasters. The 432 document describes high-level research challenges as well as a 433 general rationale why ICN approaches could be beneficial to address 434 these challenges. One main objective of this document is to gather 435 feedback from the ICN community within the IETF and IRTF regarding 436 how ICN approaches can be suitable to solve the presented research 437 challenges. Future revisions of this draft intend to include 438 additional research challenges and to discuss what implications this 439 research area has regarding related, future IETF standardisation. 441 8. References 443 8.1. Normative References 445 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 446 Keranen, A., and P. Hallam-Baker, "Naming Things with 447 Hashes", RFC 6920, April 2013. 449 8.2. Informative References 451 [COPSS2011] 452 Chen, J., Arumaithurai, M., Jiao, L., Fu, X., and K. 453 Ramakrishnan, "COPSS: An Efficient Content Oriented 454 Publish/Subscribe System", Seventh ACM/IEEE Symposium on 455 Architectures for Networking and Communications Systems 456 (ANCS), 2011, . 458 [Psaras2014] 459 Psaras, I., Saino, L., Arumaithurai, M., Ramakrishnan, K., 460 and G. Pavlou, "Name-Based Replication Priorities in 461 Disaster Cases", 2nd Workshop on Name Oriented Mobility 462 (NOM), 2014, . 464 [Seedorf2014] 465 Seedorf, J., Kutscher, D., and F. Schneider, 466 "Decentralised Binding of Self-Certifying Names to Real- 467 World Identities for Assessment of Third-Party Messages in 468 Fragmented Mobile Networks", 2nd Workshop on Name Oriented 469 Mobility (NOM), 2014, . 471 Appendix A. Acknowledgment 473 The authors would like to thank Ioannis Psaras for useful comments. 475 This document has been supported by the GreenICN project (GreenICN: 476 Architecture and Applications of Green Information Centric Networking 477 ), a research project supported jointly by the European Commission 478 under its 7th Framework Program (contract no. 608518) and the 479 National Institute of Information and Communications Technology 480 (NICT) in Japan (contract no. 167). The views and conclusions 481 contained herein are those of the authors and should not be 482 interpreted as necessarily representing the official policies or 483 endorsements, either expressed or implied, of the GreenICN project, 484 the European Commission, or NICT. 486 Authors' Addresses 488 Jan Seedorf 489 NEC 490 Kurfuerstenanlage 36 491 Heidelberg 69115 492 Germany 494 Phone: +49 6221 4342 221 495 Fax: +49 6221 4342 155 496 Email: seedorf@neclab.eu 498 Mayutan Arumaithurai 499 University of Goettingen 500 Goldschmidt Str. 7 501 Goettingen 37077 502 Germany 504 Phone: +49 551 39 172046 505 Fax: +49 551 39 14416 506 Email: arumaithurai@informatik.uni-goettingen.de 508 Atsushi Tagami 509 KDDI R&D Labs 510 2-1-15 Ohara 511 Fujimino, Saitama 356-85025 512 Japan 514 Phone: +81 49 278 73651 515 Fax: +81 49 278 7510 516 Email: tagami@kddilabs.jp 517 K. K. Ramakrishnan 518 University of California 519 Riverside CA 520 USA 522 Email: kkramakrishnan@yahoo.com 524 Nicola Blefari Melazzi 525 University Tor Vergata 526 Via del Politecnico, 1 527 Roma 00133 528 Italy 530 Phone: +39 06 7259 7501 531 Fax: +39 06 7259 7435 532 Email: blefari@uniroma2.it