idnits 2.17.1 draft-irtf-icnrg-challenges-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 2, 2015) is 3152 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-irtf-icnrg-videostreaming-04 -- Obsolete informational reference (is this intentional?): RFC 2002 (Obsoleted by RFC 3220) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5741 (Obsoleted by RFC 7841) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG D. Kutscher, Ed. 3 Internet-Draft NEC 4 Intended status: Informational S. Eum 5 Expires: March 5, 2016 NICT 6 K. Pentikousis 7 EICT 8 I. Psaras 9 UCL 10 D. Corujo 11 Universidade de Aveiro 12 D. Saucez 13 INRIA 14 T. Schmidt 15 HAW HAmburg 16 M. Waehlisch 17 FU Berlin 18 September 2, 2015 20 ICN Research Challenges 21 draft-irtf-icnrg-challenges-02 23 Abstract 25 This memo describes research challenges for Information-Centric 26 Networking (ICN), an approach to evolve the Internet infrastructure 27 to directly support information distribution by introducing uniquely 28 named data as a core Internet principle. Data becomes independent 29 from location, application, storage, and means of transportation, 30 enabling in-network caching and replication. ICN researcg challenges 31 include naming, security, routing, system scalability, mobility 32 management, wireless networking, transport services, in-network 33 caching, and network management. 35 This document is a product of the IRTF Information-Centric Networking 36 Research Group (ICNRG). 38 Status of this Memo 40 RFC Editor: please merge this with the xml2rfc-generated "status of 41 this memo" below. 43 This document is not an Internet Standards Track specification; it is 44 published for informational purposes. 46 This document is a product of the Internet Research Task Force 47 (IRTF). The IRTF publishes the results of Internet-related research 48 and development activities. These results might not be suitable for 49 deployment. This document has been reviewed, commented, and 50 discussed extensively for a period of nearly two years by the vast 51 majority of ICNRG members, which certainly exceeds 100 individuals. 52 It is the consensus of ICNRG that the research challenges described 53 in this document should be published in the IRTF Stream of the RFC 54 series. Documents approved for publication by the IRSG are not a 55 candidate for any level of Internet Standard; see Section 2 of RFC 56 5741 [RFC5741]. 58 Status of This Memo 60 This Internet-Draft is submitted in full conformance with the 61 provisions of BCP 78 and BCP 79. 63 Internet-Drafts are working documents of the Internet Engineering 64 Task Force (IETF). Note that other groups may also distribute 65 working documents as Internet-Drafts. The list of current Internet- 66 Drafts is at http://datatracker.ietf.org/drafts/current/. 68 Internet-Drafts are draft documents valid for a maximum of six months 69 and may be updated, replaced, or obsoleted by other documents at any 70 time. It is inappropriate to use Internet-Drafts as reference 71 material or to cite them other than as "work in progress." 73 This Internet-Draft will expire on March 5, 2016. 75 Copyright Notice 77 Copyright (c) 2015 IETF Trust and the persons identified as the 78 document authors. All rights reserved. 80 This document is subject to BCP 78 and the IETF Trust's Legal 81 Provisions Relating to IETF Documents 82 (http://trustee.ietf.org/license-info) in effect on the date of 83 publication of this document. Please review these documents 84 carefully, as they describe your rights and restrictions with respect 85 to this document. 87 Table of Contents 89 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 90 2. Problems with Information Distribution Today . . . . . . . . 5 91 3. ICN Terminology and Concepts . . . . . . . . . . . . . . . . 6 92 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 93 3.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 6 94 4. ICN Research Challenges . . . . . . . . . . . . . . . . . . . 8 95 4.1. Naming and Data Authenticity . . . . . . . . . . . . . . 8 96 4.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 10 97 4.2.1. Data Object Authentication . . . . . . . . . . . . . 10 98 4.2.2. Binding NDOs to Real World Identities . . . . . . . . 11 99 4.2.3. Traffic Aggregation and Filtering . . . . . . . . . . 11 100 4.2.4. State Overloading . . . . . . . . . . . . . . . . . . 12 101 4.2.5. Delivering Data Objects from Replicas . . . . . . . . 12 102 4.2.6. Cryptographic Robustness . . . . . . . . . . . . . . 12 103 4.2.7. Routing and Forwarding Information Bases . . . . . . 13 104 4.3. Routing and Resolution System Scalability . . . . . . . . 13 105 4.3.1. Route-By-Name Routing . . . . . . . . . . . . . . . . 13 106 4.3.2. Lookup-By-Name Routing . . . . . . . . . . . . . . . 14 107 4.3.3. Hybrid Routing . . . . . . . . . . . . . . . . . . . 15 108 4.4. Mobility Management . . . . . . . . . . . . . . . . . . . 15 109 4.5. Wireless Networking . . . . . . . . . . . . . . . . . . . 17 110 4.6. Rate and Congestion Control . . . . . . . . . . . . . . . 20 111 4.7. In-Network Caching . . . . . . . . . . . . . . . . . . . 21 112 4.7.1. Cache Placement . . . . . . . . . . . . . . . . . . . 21 113 4.7.2. Content Placement -- Content-to-Cache Distribution . 22 114 4.7.3. Request-to-Cache Routing . . . . . . . . . . . . . . 23 115 4.7.4. Staleness Detection of Cached NDOs . . . . . . . . . 24 116 4.8. Network Management . . . . . . . . . . . . . . . . . . . 24 117 4.9. Application Development . . . . . . . . . . . . . . . . . 26 118 4.9.1. Web Applications . . . . . . . . . . . . . . . . . . 27 119 4.9.2. Video Streaming and Download . . . . . . . . . . . . 27 120 4.9.3. Internet of Things . . . . . . . . . . . . . . . . . 28 121 5. Security Considerations . . . . . . . . . . . . . . . . . . . 29 122 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 123 7. Informative References . . . . . . . . . . . . . . . . . . . 29 124 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 32 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 127 1. Introduction 129 Distributing and manipulating named information is a major 130 application in the Internet today. In addition to web-based content 131 distribution, other distribution technologies (such as P2P and CDN) 132 have emerged and are promoting a communication model of accessing 133 data by name, regardless of origin server location. 135 In order to respond to the increasing traffic volume in the current 136 Internet for applications such as mobile video and cloud computing, a 137 set of disparate technologies and distribution services are applied 138 that leverage caching, replication and content distribution in 139 different specific ways. These approaches are currently deployed in 140 separate silos -- different CDN providers and P2P applications rely 141 on their own, often proprietary, distribution technologies. It is 142 not possible to uniquely and securely identify named information 143 independently of the distribution channel; and the different 144 distribution approaches are typically implemented as an overlay, 145 potentially leading to unnecessary inefficiency. 147 For example, creating and sharing multimedia content in a social 148 networking application today, typically requires uploading data 149 objects to centralized service provider platforms, from where it can 150 be accessed individually by other users. Even if content sharing is 151 intended to happen locally, e.g., in a local network or local area, 152 the actual communication will require interactions from any 153 interested user with the service provider. CDNs can alleviate the 154 situation only partly, because, due to organizational and economic 155 reasons, it is not common to deploy CDN gear ubiquitously. Moreover, 156 since CDNs and the respective communication sessions form overlays, 157 the actual communication, i.e., the requests for named content and 158 the actual responses, are largely invisible to the network, i.e., it 159 is not easily possible to optimize efficiency and performance. For 160 example, in a wireless access network, it is not possible to leverage 161 the inherent broadcast nature of the medium (and avoid duplicate 162 transmission of the same content) due to limitations from point-to- 163 point and overlay communication. 165 Information-centric networking (ICN) is an approach to evolve the 166 Internet infrastructure to directly support this use by introducing 167 named data as a core network-layer primitive. Data objects become 168 independent of location, application, storage, and means of 169 transportation, allowing for inexpensive and ubiquitous in-network 170 caching and replication. The expected benefits are improved 171 efficiency, better support for provenance verification and name- 172 content binding validation, better scalability with respect to 173 information/bandwidth demand and better robustness in challenging 174 communication scenarios. 176 ICN concepts can be deployed by retooling the protocol stack: name- 177 based data access can be implemented on top of the existing IP 178 infrastructure, e.g., by providing resource naming, ubiquitous 179 caching and corresponding transport services, or it can be seen as a 180 packet-level internetworking technology that would cause fundamental 181 changes to Internet routing and forwarding. In summary, ICN is 182 expected to evolve the Internet architecture towards a network model 183 that is more suitable for the current and future usage patterns. 185 This document presents the ICN research challenges that need to be 186 addressed in order to achieve these goals. These research challenges 187 are seen from a technical perspective, although business 188 relationships between Internet players will also influence 189 developments in this area. We leave business challenges for a 190 separate document, however. The objective of this memo is to 191 document the technical challenges and corresponding current 192 approaches and to expose requirements that should be addressed by 193 future research work. 195 2. Problems with Information Distribution Today 197 The best current practice to manage the above-mentioned growth in 198 terms of data volume and number of devices is to increase 199 infrastructure investment, employ application-layer overlays such as 200 CDNs, P2P applications, and M2M application platforms that cache 201 content, provide location-independent access to data and optimize 202 delivery. In principle, such platforms provide a service model of 203 accessing named data objects (NDOs) (e.g., replicated web resources, 204 M2M data in data centers) instead of a host-to-host packet delivery 205 service model. 207 However, since this functionality resides in overlays only, the full 208 potential of content distribution and M2M application platforms 209 cannot be leveraged as the network is not aware of data requests and 210 data transmissions. This has the following impact: 212 o data traffic can follow sub-optimal paths as it is effectively 213 routed depending on the overlay topology instead of the Internet 214 layer topology; 216 o network capabilities, such as multicast and broadcast, are largely 217 underutilized or not employed at all. As a result, request and 218 delivery for the same object have to be made multiple times; 220 o overlays typically require significant infrastructure support, 221 e.g., authentication portals, content storage, and applications 222 servers, making it often impossible to establish local, direct 223 communication; 225 o since the network is not aware of the nature of data objects, it 226 is unable to manage access and transmission (without layer 227 violations); 229 o provenance validation uses host authentication today. As such, 230 even if there are locally cached copies available, it is normally 231 not easily possible to validate their authenticity; and 233 o many applications follow their own approach to caching, 234 replication, transport, authenticity validation (if at all), 235 although they all share similar models for accessing named data 236 objects in the network. 238 3. ICN Terminology and Concepts 240 3.1. Terminology 242 Information-Centric Networking (ICN): A concept for communicating in 243 a network that provides accessing named data objects as a first 244 order service. See Section 3.2 for details. 246 Named Data Object (NDO): Addressable data unit in an information- 247 centric network that can represent a collection of bytes or a 248 piece of information. In ICN, each data object has a name bound 249 to it, and there are typically mechanisms to secure (and validate) 250 this binding. Different ICN approaches have different concepts 251 for how to map NDOs to individual units of transport. Within the 252 context of this document, an NDO is any data named object that can 253 be requested from the network. In this document we often use the 254 terms 'NDO' and 'data object' interchangeable. 256 Requestor: Entity in an ICN network that is sending a request for a 257 Named Data Object to the network. 259 3.2. Concepts 261 Fundamentally, ICN provides access to named data as a first-order 262 network service, i.e., the network is able to serve requests to named 263 data natively. That means, network nodes can receive requests for 264 named data and act as necessary, for example, by forwarding the 265 request to a suitable next-hop. Consequently, the network processes 266 requests for named data objects (and corresponding responses) 267 natively. Every network node on a path is enabled to perform 268 forwarding decisions, to cache objects etc. This enables the network 269 to forward such requests on optimal paths, employing the best 270 transmission technologies at every node, e.g., broadcast/multicast 271 transmission in wireless networks to avoid duplicate transmission of 272 both requests and responses. 274 In ICN there is a set of common concepts and node requirements beyond 275 this basic service model. Naming data objects is a key concept. In 276 general, ICN names represent neither network nodes nor interfaces -- 277 they represent NDOs independently of their location. Names do play a 278 key role in forwarding decisions and are used for matching requests 279 to responses: In order to provide better support for accessing copies 280 of NDOs regardless of their location, it is important to be able to 281 validate that a response actually delivers the bits that correspond 282 to an original request for named data. 284 Name-content binding validation is a fundamental security service in 285 ICN, and this is often achieved by establishing a verifiable binding 286 between the object name and the actual object or an identity that has 287 created the object. ICN can support other security services, such as 288 provenance validation, and encryption, depending on the details of 289 naming schemes, object models and assumptions on infrastructure 290 support. Security services such as name-content binding validation 291 are available to any node, i.e., not just the actual requestors. 292 This is an important feature, for enabling ingress gateways to check 293 object authenticity to prevent denial-of-service attacks. 295 Based on these fundamental properties it is possible to leverage 296 network storage ubiquitously: every ICN node can cache data objects 297 and respond to requests for such objects -- it is not required to 298 validate the authenticity of the node itself since name-content 299 bindings can be validated. Ubiquitous in-network storage can be used 300 for different purposes: it can enable sharing, i.e., the same object 301 copy can be delivered to multiple users/nodes as in today's proxy 302 caches and CDNs. It can also be used to make communication more 303 robust (and perform better) by enabling the network to answer 304 requests from local caches (instead of from origin servers). In case 305 of disruption (message not delivered), a node can resend the request, 306 and it could be answered by an on-path cache, i.e., on the other side 307 of the disrupted link. The network itself would thus support 308 retransmissions enabling shorter round-trip times and offloading 309 origin servers and other parts of the network. 311 The request/response model and ubiquitous in-network storage also 312 enable new options for implementing transport services, i.e., 313 reliable transmission, flow control, etc. First of all, a request/ 314 response model can enable receiver-driven transport regimes, i.e., 315 receivers (the requestors of NDOs) can control message sending rates 316 by regulating the request sending rate (assuming that every response 317 message has to be triggered by a request message). Retransmission 318 would be achieved by resending requests, e.g., after a timeout. 319 Because objects can be replicated, object transmission and transport 320 sessions would not necessarily have end-to-end semantics: requests 321 can be answered by caches, and a node can select one or multiple 322 next-hop destinations for a particular request depending on 323 configuration, observed performance or other criteria. 325 This receiver-driven communication model potentially enables new 326 interconnection and business models: a request for named data can be 327 linked to an interest of a requestor (or requesting network) in data 328 from another peer, which could suggest modeling peering agreements 329 and charging accordingly. 331 4. ICN Research Challenges 333 4.1. Naming and Data Authenticity 335 Naming data objects is as important for ICN as naming hosts is for 336 today's Internet. Fundamentally, ICN requires unique names for 337 individual NDOs, since names are used for identifying objects 338 independently of their location or container. In addition, since 339 NDOs can be cached anywhere, the origin cannot be trusted anymore 340 hence the importance to establish a verifiable binding between the 341 object and its name (name-data integrity) so that a requestor can be 342 sure that the received bits do correspond to the NDO originally 343 requested (object authenticity). Information about an object's 344 provenance, i.e., who generated or published it, is also useful to 345 associate to the name. 347 The above functions are fundamentally required for the information- 348 centric network to work reliably, otherwise neither network elements 349 nor requestors can trust object authenticity. Lack of this trust 350 enables several attacks including DoS attacks by injecting spoofed 351 content into the network. There are different ways to use names and 352 cryptography to achieve the desired functions [ICNNAMING] 353 [ICNSURVEY], and there are different ways to manage namespaces 354 correspondingly. 356 Two types of naming schemes have been proposed in the ICN literature: 357 hierarchical and flat namespaces. For example, a hierarchical scheme 358 may have a structure similar to current URIs, where the hierarchy is 359 rooted in a publisher prefix. Such hierarchy enables aggregation of 360 routing information, improving scalability of the routing system. In 361 some cases, names are human-readable, which makes it possible for 362 users to manually type in names, reuse, and, to some extent, map the 363 name to user intent. 365 The second general class of naming schemes follows a "self- 366 certifying" approach, meaning that the object's name-data integrity 367 can be verified without requiring a public key infrastructure (PKI) 368 or other third party to first establish trust in the key. Self- 369 certification is achieved, e.g., by binding the hash of the NDO 370 content to the object's name. For instance, this can be done by 371 directly embedding the hash of the content in the name. Another 372 option is an indirect binding, which embeds the public key of the 373 publisher in the name and signs the hash of the content with the 374 corresponding secret key. The resulting names are typically non- 375 hierarchical, or flat, although the publisher field could be employed 376 to create a structure which could facilitate route aggregation. 377 There are several design trade-offs for ICN naming, which affect 378 routing and security. Self-certifying names are not human readable 379 nor hierarchical. They can however provide some structure for 380 aggregation, for instance, a name part corresponding to a publisher. 382 Research challenges specific to naming include: 384 o Naming static data objects can be performed by using content 385 hashes as part of object names, so that publishers can calculate 386 the hash over existing data objects and requestors (or any ICN 387 node) can validate the name-content binding by re-calculating the 388 hash and comparing it to the name (component). [RFC6920] 389 specifies a concrete naming format for this. 391 o Naming dynamic objects refers to use cases where the name has to 392 be generated before the object is created. For example, this 393 could be the case for live streaming, when a publisher wants to 394 make the stream available by registering stream chunk names in the 395 network. One approach to this can be self-certified names as 396 described above. 398 o Requestor privacy protection can be a challenge in ICN as a direct 399 consequence of the accessing-named-data-objects paradigm: if the 400 network can "see" requests and responses, it can also log request 401 history for network segments or individual users, which can be 402 undesirable, especially since names are typically expected to be 403 long-lived. That is, even if the name itself does not reveal much 404 information, the assumption is that the name can be used to 405 retrieve the corresponding data objects in the future. 407 o Updating and versioning NDOs can be challenging because it can 408 contradict fundamental ICN assumptions: if an NDO can be 409 replicated and stored in in-network storage for later retrieval, 410 names have to be long-lived, and the name-content binding must not 411 change: updating an object (i.e., changing the content without 412 generating a new name) is not possible. Versioning is one 413 possible solution, but requires a naming scheme that supports it 414 (and a way for requestors to learn about versions). 416 o Managing accessibility: whereas in ICN the general assumption is 417 to enable ubiquitous access to NDOs, there can be relevant use 418 cases where access to objects should be restricted, for example to 419 a specific user group. There are different approaches for this, 420 such as object encryption (requiring key distribution and related 421 mechanisms) or the concept of scopes, e.g., based on names that 422 can only be used/resolved under some constraints. 424 4.2. Security 426 Security can take many different forms in ICN and instead of 427 discussing specific attacks or technical details, we propose here the 428 most important security challenges that come from the shift to 429 information-centric communications. Some challenges are well- 430 understood, and there are (sometimes multiple different) approaches 431 to address them, whereas other challenges are active research and 432 engineering topics. 434 4.2.1. Data Object Authentication 436 As mentioned in section Section 4.1, data object authentication is an 437 important ICN feature, since ICN data objects are retrieved not only 438 from an original copy holder but also from any caching point. Hence, 439 the communication channel endpoints to retrieve NDOs are not 440 trustable anymore and solutions widely used today such as TLS 441 [RFC5246] cannot be used as a general solution. Since data objects 442 can be maliciously modified, ICN should provide users with a security 443 mechanism to verify the origin and integrity of the data object, and 444 there are different ways to achieve this. 446 An efficient approach for static NDOs is providing a name-content- 447 binding by hashing an NDO and using the hash as a part of the 448 object's name. [RFC6920] provides a mechanism and a format for 449 representing a digest algorithm and the actual digest in a name 450 (amongst other information). 452 For dynamic objects where it is desirable to refer to an NDO by name 453 before the object has been created, public-key cryptography is often 454 applied, i.e., every NDO would be authenticated by means of a 455 signature performed by the data object publisher so that any data 456 object consumer can verify the validity of the data object based on 457 the signature. However, in order to verify the signature of an 458 object, the consumer must know the public key of the entity that 459 signed the object. 461 One research challenge is then to support a mechanism to distribute 462 the publisher's public keys to the consumers of data objects. There 463 are two main approaches to achieve this; one is based on an external 464 third party authority such as hierarchical Public Key Infrastructure 465 (PKI) [RFC5280] and the other is to adapt a self-certifying scheme. 466 The former, as the name implies, depends on an external third party 467 authority to distribute the public key of the publisher for the 468 consumers. In a self-certifying scheme, the public key (or a hash of 469 it) would be used as part of the name -- which is sufficient to 470 validate the object's authenticity. 472 In cases where information about the origin of a data object is not 473 available by other means, the object itself would have to incorporate 474 the necessary information to determine the object publisher, for 475 example with a certificate, that can be validated through the PKI. 476 Once the certificate is authenticated, its public key can be used to 477 authenticate the signed data object itself. 479 4.2.2. Binding NDOs to Real World Identities 481 In addition to validating NDO authenticity, it is still important to 482 bind real-world identities, e.g., a publisher identity, to objects, 483 so that a requestor can verify that a received object was actually 484 published by a certain source. 486 With hash-based and self-certifying names, real world-identity 487 bindings are not intrinsically established: the name provides the 488 hash of the NDO or of the public key that has been used to sign the 489 NDO. There needs to be another binding to a real world-identity if 490 that feature is requested. 492 If the object name directly provides the publisher name and if that 493 name is protected by a certificate that links to a PKI-like trust 494 chain, the object name itself can provide an intrinsic binding to a 495 real world identity. 497 Binding between NDOs and real world identities is essential but there 498 is no universal way to achieve it as it is all intrinsic to a 499 particular ICN approach. 501 4.2.3. Traffic Aggregation and Filtering 503 One request message to retrieve a data object can actually aggregate 504 requests coming from several consumers. This aggregation of requests 505 reduces the overall traffic but makes per-requestor filtering harder. 506 The challenge in this case is to provide a mechanism that allows 507 request aggregation and per-requestor filtering. A possible solution 508 is to indicate the set of requestors in the aggregated request such 509 that the response can indicate the subset of requestors allowed to 510 access the data object. However, this solution requires 511 collaboration from other nodes in the network and is not suitable for 512 caching. Another possible solution is to encrypt data objects and 513 ensure that only authorised consumers can decrypt them. This 514 solution does not preclude caching and does not require collaboration 515 from the network. However, it implies a mechanism to generate group 516 keys (e.g., different private keys can be used to decrypt the same 517 encrypted data object) [Chaum]. 519 4.2.4. State Overloading 521 ICN solutions that implement state on intermediate routers for 522 request routing or forwarding (e.g., CCN [CCN]) are subject to denial 523 of service attacks from overloading or superseding the internal state 524 of a router (e.g., 'interest flooding' [BACKSCATTER]). Additionally, 525 stateful forwarding can enable attack vectors such as resource 526 exhaustion or complexity attacks to the routing infrastructure. The 527 challenge is then to provision routers and construct internal state 528 in a way that alleviates sensibility to such attacks. The problem 529 becomes even harder, if the protocol does not provide information 530 about the origin of messages. Without origin, it is a particular 531 challenge to distinguish between regular (intense) use and misuse of 532 the infrastructure. 534 4.2.5. Delivering Data Objects from Replicas 536 A common capability of ICN solutions is data replication and in- 537 network storage. Delivering replicated data objects from caches 538 decouples content consumption from data sources, which leads to a 539 loss of control on (1) content access, and (2) content dissemination. 540 In a widely distributed, decentralized environment like the Internet, 541 this raises several challenges. 543 One group of challenges is related to content management. Without 544 access control, a content provider loses the means to count and 545 survey content consumption, to limit access scopes, to control or 546 know about the number of copies of its data in the network, or to 547 withdraw earlier publication reliably. Any non-cooperative or 548 desynchronized data cache may hinder an effective content management 549 policy. 551 Another group of challenges arises from potential traffic 552 amplifications in the decoupled environment. ICN solutions that 553 attempt to retrieve content from several replicas in parallel, or 554 decorrelated network routing states, but also distributed attackers 555 may simultaneously initiate the transmission of content from multiple 556 replicas towards the same destination (e.g., 'initiated overloads' or 557 'blockades' [BACKSCATTER]). Methods for mitigating such threats need 558 rigorous forwarding checks that require alignment with caching 559 procedures (e.g., on-path or off-path). 561 4.2.6. Cryptographic Robustness 563 Content producers sign their content to ensure the integrity of data 564 and to allow for data object authentication. This is a fundamental 565 requirement in ICN due to distributed caching. Publishers, who (a) 566 massively sign content, which is (b) long-lived, offer time and data 567 to an attacker for comprising cryptographic credentials. Signing 568 large amount of data eases common attacks that try to breach the key 569 of the publisher. Based on this observation, the following research 570 challenges emerge: 572 o To which extent does the content publication model conflict with 573 cryptographic limitations? 575 o How can we achieve a transparent re-signing without introducing 576 additional cryptographical weaknesses or key management overhead? 578 4.2.7. Routing and Forwarding Information Bases 580 In information-centric networks, one attack vector is to increase the 581 size of routing and forwarding information bases at ICN nodes, i.e., 582 attacking routing scalability in networks that rely on routing by 583 name. This is an intrinsic ICN security issue: possible mitigation 584 approaches include combining routing information authenticity 585 validation with filtering (e.g., maximum de-aggregation level 586 whenever applicable, black lists, etc.). 588 4.3. Routing and Resolution System Scalability 590 ICN routing is a process that finds an NDO based on its name 591 initially provided by a requestor. ICN routing may comprise three 592 steps: (1) name resolution, (2) discovery, and (3) delivery. The 593 name resolution step translates the name of the requested NDO into 594 its locator. The discovery step routes the request to data object 595 based on its name or locator. The last step (delivery) routes the 596 data object back to the requestor. Depending on how these steps are 597 combined, ICN routing schemes can be categorized as Route-By-Name 598 Routing (RBNR), Lookup-By-Name Routing (LBNR), and Hybrid Routing 599 (HR) as discussed in the following subsections. 601 4.3.1. Route-By-Name Routing 603 RBNR omits the first name resolution step as the name of the NDO is 604 directly used to route the request to the data object. Therefore, 605 routing information for each data object has to be maintained in the 606 routing table. Since the number of data objects is very large 607 (estimated as 10^11 back in 2007 [DONA] but this may be significantly 608 larger than that, e.g., 10^15 to 10^22), the size of routing tables 609 becomes a concern, as it can be proportional to the number of data 610 objects unless an aggregation mechanism is introduced. On the other 611 hand, RBNR reduces overall latency and simplifies the routing process 612 due to the omission of the resolution process. For the delivery 613 step, RBNR needs another identifier (ID) of either host or location 614 to forward the requested data object back to the requestor. 616 Otherwise, an additional routing mechanism has to be introduced, such 617 as bread-crumbs routing [BREADCRUMBS], in which each request leaves 618 behind a trail of breadcrumbs along its forwarding path, and then the 619 response is forwarded back to the requestor consuming the trail. 621 Challenges specific to RBNR include: 623 o How can we aggregate the names of data objects to reduce the 624 number of routing entries? 626 o How does a user learn the name which is designed for aggregation 627 by provider? For example, although we name our contribution as 628 "ICN research challenges", the IRTF (provider) may want to change 629 the name to "/IETF/IRTF/ICN/Research challenges" for aggregation. 630 In this case, how does a user learn the name "/IETF/IRTF/ICN/ 631 Research challenges" to retrieve the contribution initially named 632 "ICN research challenges" without any resolution process? 634 o Without introducing the name aggregation scheme, can we still 635 achieve scalable routing by taking advantage of topological 636 structure and distributed copies? For example, would employing 637 compact routing [COMPACT], random walk [RANDOM] or greedy routing 638 [GREEDY] work at Internet scale? 640 o How can we incorporate copies of a data object in in-network 641 caches in this routing scheme? 643 4.3.2. Lookup-By-Name Routing 645 LBNR uses the first name resolution step to translate the name of the 646 requesting data object into its locator. Then, the second discovery 647 step is carried out based on the locator. Since IP addresses could 648 be used as locators, the discovery step can depend on the current IP 649 infrastructure. The delivery step can be implemented similarly to IP 650 routing. The locator of the requestor is included in the request 651 message, and then the requested data object is delivered to the 652 requestor based on the locator. An instantiation of LBNR is [MDHT]. 654 Challenges specific to LBNR include: 656 o How can we build a scalable resolution system which provides 658 * Fast lookup: mapping the name of data object to its locators 659 (copies as well). 661 * Fast update: the location of data object is expected to change 662 frequently. Also, multiple data objects may change their 663 locations at the same time, e.g., data objects in a laptop. 665 o How can we incorporate copies of a data object in in-network 666 caches in this routing scheme? 668 4.3.3. Hybrid Routing 670 HR combines RBNR and LBNR to benefit from their advantages. For 671 instance, within a single administrative domain, e.g., an ISP, where 672 scalability issues can be addressed with network planning, RBNR can 673 be adopted to reduce overall latency by omitting the resolution 674 process. On the other hand, LBNR can be used to route between 675 domains which have their own prefix (locator). 677 A challenge specific to HR is: How can we design a scalable mapping 678 system which, given the name of a data object, should return a 679 destination domain locator so that a user request can be encapsulated 680 and forwarded to the domain? 682 4.4. Mobility Management 684 Mobility management has been an active field in host-centric 685 communications for more than two decades. In IETF in particular, 686 starting with [RFC2002], a multitude of enhancements to IP have been 687 standardized aiming to "allow transparent routing of IP datagrams to 688 mobile nodes in the Internet" [RFC5944]. In a nutshell, mobility 689 management for IP networks is locator-oriented and relies on the 690 concept of a mobility anchor as a foundation for providing always-on 691 connectivity to mobile nodes. Other standards organizations, such as 692 3GPP, have followed similar anchor-based approaches. Traffic to and 693 from the mobile node must flow through the mobility anchor, typically 694 using a set of tunnels, enabling the mobile node to remain reachable 695 while changing its point of attachment to the network. 697 Needless to say, an IP network which supports node mobility is more 698 complex than one that does not, as specialized network entities must 699 be introduced in the network architecture. This is reflected in the 700 control plane as well, which carries mobility-related signaling 701 messages, establishes and tears down tunnels and so on. While mobile 702 connectivity was an afterthought in IP, in ICN this is considered a 703 primary deployment environment. Most, if not all, ICN proposals 704 consider mobility from the very beginning, although at varying levels 705 of architectural and protocol detail. That said, no solution has so 706 far come forward with a definite answer on how to handle mobility in 707 ICN using native primitives. In fact, we observe that mobility 708 appears to be addressed on an ICN proposal-specific basis. That is, 709 there is no single paradigm solution, akin to tunneling through a 710 mobility anchor in host-centric networking, that can be applied 711 across different ICN proposals. For instance, although widely- 712 deployed mobile network architectures typically come with their own 713 network entities and associated protocols, they follow the same line 714 of design with respect to managing mobility. This design thinking, 715 which calls for incorporating mobility anchors, permeates in the ICN 716 literature too. 718 However, employing mobility anchors and tunneling is probably not the 719 best way forward in ICN research for mobile networking. 720 Fundamentally this approach is anything but information-centric and 721 location-independent. In addition, as argued in [SEEN], current 722 mobility management schemes anchor information retrieval not only at 723 a specific network gateway (e.g., home agent in Mobile IP) but due to 724 the end-to-end nature of host-centric communication also at a 725 specific correspondent node. However, once a change in the point of 726 attachment occurs, information retrieval from the original 727 "correspondent node" may be no longer optimal. This was shown in 728 [MANI], for example, where a simple mechanism that triggers the 729 discovery of new retrieval providers for the same data object, 730 following a change in the point of attachment, clearly outperforms a 731 tunnel-based approach like Mobile IP in terms of object download 732 times. The challenge here is how to capitalize on location 733 information while facilitating the use of ICN primitives which 734 natively support multicast and anycast. 736 ICN naming and name resolution, as well as the security features that 737 come along should natively support mobility. For example, CCN [CCN] 738 does not have the restriction of spanning tree routing, so it is able 739 to take advantage of multiple interfaces or adapt to the changes 740 produced by rapid mobility (i.e., there is no need to bind a layer 3 741 address with a layer 2 address). In fact, client mobility can be 742 simplified by allowing requests for new content to normally flow from 743 different interfaces, or through newly connected points of attachment 744 to the network. However, when the node moving is the (only) content 745 source, it appears that more complex network support might be 746 necessary, including forwarding updates and cache rebuilding. A case 747 in point is a conversation network service, such as a voice or video 748 call between two parties. The requirements in this case are more 749 stringent when support for seamless mobility is required, especially 750 when compared to content dissemination that is amenable to buffering. 751 Another parameter that needs to be paid attention to is the impact of 752 using different wireless access interfaces based on different 753 technologies, where the performance and link conditions can vary 754 widely depending of numerous factors. 756 In host-centric networking, mobility management mechanisms ensure 757 optimal handovers and (ideally) seamless transition from one point of 758 attachment to another. In ICN, however, the traditional meaning of 759 "point of attachment" no longer applies as communication is not 760 restrained by location-based access to data objects. Therefore, a 761 "seamless transition" in ICN ensures that content reception continues 762 without any perceptible change from the point of view of the ICN 763 application receiving that content. Moreover, this transition needs 764 to be executed in parallel with ICN content identification and 765 delivery mechanisms enabling scenarios, such as, preparation of the 766 content delivery process at the target connectivity point, prior to 767 the handover (to reduce link switch disturbances). Finally, these 768 mobility aspects can also be tightly coupled with network management 769 aspects, in respect to policy enforcement, link control and other 770 parameters necessary for establishing the node's link to the network. 772 In summary, the following research challenges on ICN mobility 773 management can be derived: 775 o How can mobility management take full advantage of native ICN 776 primitives? 778 o How do we avoid the need for mobility anchors in a network that by 779 design supports multicast, anycast and location-indepedent 780 information retrieval? 782 o How can content retrieval mechanisms interface with specific link 783 operations, such as identifying which links are available for 784 certain content? 786 o How can mobility be offered as a service, which is only activated 787 when the specific user/content/conditions require it? 789 o How can mobility management be coordinated between the node and 790 the network for optimization and policing procedures? 792 o How do we ensure that managing mobility does not introduce 793 scalability issues in ICN? 795 o How will the name resolution process be affected by rapid 796 topological changes, when the content source itself is mobile? 798 4.5. Wireless Networking 800 Today, all layer 2 (L2) wireless network radio access technologies 801 are developed with a clear assumption in mind: the waist of the 802 protocol stack is IP and it will be so for the foreseeable future. 803 By fixing the protocol stack waist, engineers can answer a large set 804 of questions, including how to handle conversational traffic (e.g., 805 voice calls) vs. web traffic, how to support multicast, and so on, in 806 a rather straightforward manner. Broadcast, on the other hand, which 807 is inherent in wireless communication is not fully taken advantage 808 of. On the contrary, researchers are often more concerned about 809 introducing mechanisms that ensure that "broadcast storms" do not 810 take down a network. The question of how can broadcast better serve 811 ICN needs has yet to be thoroughly investigated. 813 Wireless networking is often intertwined with mobility but this is 814 not always the case. In fact, empirical measurements often indicate 815 that many users tend to connect (and remain connected) to a single 816 Wi-Fi access point for considerable amounts of time. A case in 817 point, which is frequently cited in different variations in the ICN 818 literature, is access to a document repository during a meeting. For 819 instance, in a typical IETF working group meeting, a scribe takes 820 notes which are uploaded to a centralized repository (see Figure 1). 821 Subsequently, each meeting participant obtains a copy of the document 822 on their own devices for local use, annotation, and sharing with 823 colleagues that are not present at the meeting. Note that in this 824 example there is no node mobility and that it is not important 825 whether the document with the notes is uploaded in one go at the end 826 of the session or in a streaming-like fashion as is typical today 827 with online (cloud-based) document processing. 829 +---------------------+ 830 | Document Repository | 831 +---------------------+ 832 || 833 (Internet) 834 || 835 +--------------+ 836 | Access Point | 837 +--------------+ 838 / | \ 839 / | \ 840 / | \ 841 Scribe Participant 1 ... Participant N 843 Figure 1: Document sharing during a meeting 845 In this scenario we observe that the same data object bits 846 (corresponding to the meeting notes) need to traverse the wireless 847 medium at least N+1 times, where N is the number of meeting 848 participants obtaining a copy of the notes. In effect, a broadcast 849 medium is shoehorned into N+1 virtual unicast channels. One could 850 argue that wireless local connectivity is inexpensive, but this is 851 not the critical factor in this example. The actual information 852 exchange wastes N times the available network capacity, no matter 853 what is the spectral efficiency (or the economics) underlying the 854 wireless technology. This waste is a direct result of extending the 855 remote access paradigm from wired to wireless communication, 856 irrespective of the special characteristics of the latter. 858 It goes without saying that an ICN approach that does not take into 859 consideration the wireless nature of an interface will waste the same 860 amount of resources as a host-centric paradigm. In-network caching 861 at the wireless access point could reduce the amount of data carried 862 over the backhaul link but, if there is no change in the use of the 863 wireless medium, the NDO will still be carried over the wireless 864 ether N+1 times. Intelligent caching strategies, replica placement 865 cooperation and so on simply cannot alleviate this. On the other 866 hand, promiscuous interface operation and opportunistic caching would 867 maximize wireless network capacity utilization in this example. 869 Arguably, if one designs a future wireless access technology with an 870 information-centric "layer 3" in mind, many of the design choices 871 that are obvious in an all-IP architecture may no longer be valid. 872 Although this is clearly outside the scope of this document, a few 873 research challenges that the wider community may be interested in 874 include: 876 o Can we use wireless resources more frugally with the information- 877 centric paradigm than what is possible today in all-IP wireless 878 networks? 880 o In the context of wireless access, how can we leverage the 881 broadcast nature of the medium in an information-centric network? 883 o Would a wireless-oriented ICN protocol stack deliver significant 884 performance gains? How different would it be from a wired- 885 oriented ICN protocol stack? 887 o Is it possible that by changing the network paradigm to ICN we can 888 in practice increase the spectral efficiency (bits/s/Hz) of a 889 wireless network beyond what would be possible with today's host- 890 centric approaches? What would be the impact of doing so with 891 respect to energy consumption? 893 o Can wireless interface promiscuous operation coupled with 894 opportunistic caching increase ICN performance, and if so, by how 895 much? 897 o How can a conversational service be supported at least as 898 efficiently as today's state-of-the-art wireless networks deliver? 900 o What are the benefits from combining ICN with network coding in 901 wireless networks? 903 o How can MIMO and Coordinated Multipoint Transmission (CoMP) be 904 natively combined with ICN primitives in future cellular networks? 906 4.6. Rate and Congestion Control 908 ICN's receiver-driven communication model as described above creates 909 new opportunities for transport protocol design, as it does not rely 910 solely on end-to-end communication from a sender to a requestor. A 911 requested data object can be accessible in multiple different network 912 locations. A node can thus decide how to utilize multiple sources, 913 e.g., by sending parallel requests for the same NDO or by switching 914 sources (or next hops) in a suitable schedule for a series of 915 requests. 917 In this model, the requestor would control the data rate by first 918 regulating its request sending rate and next by performing source/ 919 next-hop selections. Challenges depend on the specific ICN approach, 920 but overall challenges for receiver-driven transport protocols (or 921 mechanisms, since dedicated protocols might not be required) include 922 flow and congestion control, fairness, network utilization, stability 923 (of data rates under stable conditions) an so on. [HRICP] describes 924 a request rate control protocol and corresponding design challenges. 926 As mentioned above, the ICN communication paradigm does not depend 927 strictly on end-to-end flows, as contents might be received from in- 928 network caches. The traditional concept of a flow is then somewhat 929 not valid as sub-flows, or flowlets, might be formed on the fly, when 930 fractions of an NDO are transmitted from in-network caches. For a 931 transport layer protocol this is challenging, as any measurement 932 related to this flow as traditionally done by transport protocols 933 such as TCP, can often prove misleading. For example, false RTT 934 measurements will lead to largely variable average and smooth RTT 935 values, which in turn will trigger false timeout expirations. 937 Furthermore, out-of-order delivery is expected to be common in a 938 scenario where parts of a data object are retrieved from in-network 939 caches, rather than from the origin server. Several techniques for 940 dealing with out-of-order delivery have been proposed in the past for 941 TCP, some of which could potentially be modified and re-used in the 942 context of ICN. Further research is needed in this direction though 943 to choose the right technique and adjust it according to the 944 requirements of the ICN architecture and transport protocol in use. 946 ICN offers routers the possibility to aggregate requests and can use 947 several paths, meaning that there is no such thing as a (dedicated) 948 end-to-end communication path, e.g., a router that receives two 949 requests for the same content at the same time only sends one request 950 to its neighbour. The aggregation of requests has a general impact 951 on transport protocol design. 953 Achieving rate fairness for requestors can be one challenge as it is 954 not possible to identify the number of requestors behind one 955 particular request. A second problem related to request aggregation 956 is the management of request retransmissions. Generally, it is 957 assumed that a router will not transmit a request if it transmitted 958 an identical request recently and because there is no information 959 about the requestor, the router cannot distinguish the initial 960 request from a retransmission from the same client. In such a 961 situation, how can routers adapt their timers to use the best of the 962 communication paths? Finally, aggregation of requests has an impact 963 on the server (publisher) side. The publisher has no way to 964 determine the number of clients actually consuming the content it is 965 producing. This shift of model influences the business model of the 966 server, e.g., how to implement pay-per-click, as discussed earlier in 967 Section 4.1. 969 NDOs can represent content used in different types of applications 970 with different QoS requirements, for example, interactive real-time 971 applications, media streaming, file download. Each of these 972 applications imposes different QoS requirements on different elements 973 in an information-centric network, e.g., regarding cache placement, 974 request-to-cache/source routing. Achieving the necessary QoS levels 975 in a shared network is an active ICN research topic. 977 4.7. In-Network Caching 979 Explicitly named data objects allow for caching at virtually any 980 network element, including routers, proxy caches and end-user 981 devices. In-network caching can therefore improve network 982 performance by fetching content from nodes geographically placed 983 closer to the end-user. Several issues that need further 984 investigation have been identified with respect to in-network 985 caching. In this section we list important challenges that relate to 986 the properties of the new ubiquitous caching system. 988 4.7.1. Cache Placement 990 The declining cost of fast memory gives the opportunity to deploy 991 caches in network routers and take advantage of cached NDOs. We 992 identify two approaches to in-network caching, namely, on-path and 993 off-path caching. Both approaches have to consider the issue of 994 cache location. Off-path caching is similar to traditional proxy- 995 caching or CDN server placement. Retrieval of contents from off-path 996 caches requires redirection of requests and, therefore, is closely 997 related to the Request-to-Cache Routing problem discussed later. 999 Off-path caches have to be placed in strategic points within a 1000 network in order to reduce the redirection delays and the number of 1001 detour hops to retrieve cached contents. Previous research on proxy- 1002 caching and CDN deployment is helpful in this case. 1004 On the other hand, on-path caching requires less network intervention 1005 and fits more neatly in ICN. However, on-path caching requires line- 1006 speed operation, which places more constraints on the design and 1007 operation of in-network caching elements. Furthermore, the gain of 1008 such a system of on-path in-network caches relies on opportunistic 1009 cache hits and has therefore been considered of limited benefit, 1010 given the huge amount of contents hosted in the Internet. For this 1011 reason, network operators might initially consider only a limited 1012 number of network elements to be upgraded to in-network caching 1013 elements. The decision on which nodes should be equipped with caches 1014 is an open issue and might be based, among others, on topological 1015 criteria, or traffic characteristics. These challenges relate to 1016 both the Content Placement Problem and the Request-to-Cache Routing 1017 Problem discussed below. 1019 In most cases, however, the driver for the implementation, deployment 1020 and operation of in-network caches will be its cost. Operating 1021 caches at line speed inevitably requires faster memories, which 1022 increase the implementation cost. Based on the capital to be 1023 invested, ISPs will need to make strategic decisions on the cache 1024 placement, which can be driven by several factors, such as: avoid 1025 inter-domain/expensive links, centrality of nodes, size of domain and 1026 the corresponding spatial locality of users, traffic patterns in a 1027 specific part of the network (e.g., university vs. business vs. 1028 fashion district of a city). 1030 4.7.2. Content Placement -- Content-to-Cache Distribution 1032 Given a number of on-path or off-path in-network caching elements, 1033 content-to-cache distribution will affect both the dynamics of the 1034 system, in terms of request redirections (mainly in case of off-path 1035 caches) and the gain of the system in terms of cache hits. A 1036 straightforward approach to content placement is on-path placement of 1037 contents as they travel from source to destination. This approach 1038 reduces the computation and communication overhead of placing content 1039 within the network but, on the other hand, might reduce the chances 1040 of hitting cached contents. This relates to the Request-to-Cache 1041 Routing problem discussed next. 1043 Furthermore, the number of replicas held in the system brings up 1044 resource management issues in terms of cache allocation. For 1045 example, continuously replicating data objects in all network 1046 elements results in redundant copies of the same objects. The issue 1047 of redundant replication has been investigated in the past for 1048 hierarchical web caches. However, in hierarchical web-caching, 1049 overlay systems coordination between the data and the control plane 1050 can guarantee increased performance in terms of cache hits. Line- 1051 speed, on-path in-network caching poses different requirements and 1052 therefore, new techniques need to be investigated. In this 1053 direction, reducing the redundancy of cached copies is a study item. 1054 However, the issue of coordinated content placement in on-path caches 1055 remains open. 1057 The Content-to-Cache Allocation problem relates also to the 1058 characteristics of the content to be cached. Popular content might 1059 need to be placed where it is going to be requested next. 1060 Furthermore, issues of "expected content popularity" or temporal 1061 locality need to be taken into account in designing in-network 1062 caching algorithms in order for some contents to be given priority 1063 (e.g., popular content vs. one-timers). The criteria as to which 1064 contents should be given priority in in-network content caches relate 1065 also to the business relationships between content providers and 1066 network operators. Business model issues will drive some of these 1067 decisions on content-to-cache distribution, but such issues are 1068 outside the scope of this note and are not discussed here further. 1070 4.7.3. Request-to-Cache Routing 1072 In order to take advantage of cached contents, requests have to be 1073 forwarded to the nodes that cache the corresponding contents. This 1074 challenge relates to name-based routing, discussed earlier. Requests 1075 should ideally follow the path to the cached NDO. However, 1076 instructions as to which content is cached where cannot be broadcast 1077 throughout the network. Therefore, the knowledge of a NDO location 1078 at the time of the request might either not exist, or it might not be 1079 accurate (i.e., contents might have been removed by the time a 1080 request is redirected to a specific node). 1082 Coordination between the data and the control planes to update 1083 information of cached contents has been considered, but in this case 1084 scalability issues arise. We therefore, have two options. We either 1085 have to rely on opportunistic caching, where requests are forwarded 1086 to a server and in case the NDOt is found on the path, then the 1087 content is fetched from this node instead of the origin server; or we 1088 employ cache-aware routing techniques. Cache-aware routing can 1089 either involve both the control and the data plane, or only one of 1090 them. Furthermore, cache-aware routing can be done in a domain-wide 1091 scale or can involve more than one individual Autonomous System (AS). 1092 In the latter case, business relationships between ASes might need to 1093 be exploited in order to build a scalable model. 1095 4.7.4. Staleness Detection of Cached NDOs 1097 Due to the largely distributed copies of NDOs in in-network caches, 1098 ICN should be able to provide a staleness verification algorithm 1099 which provides synchronization of NDOs located at their providers and 1100 in-network caching points. Two types of approaches can be considered 1101 for this problem, namely direct and indirect approaches. 1103 In the direct approach, each cache looks up certain information in 1104 the name of NDO, e.g., timestamp which directly indicates its 1105 staleness. This approach is applicable to some NDOs that come from 1106 machine-to-machine and Internet of Things scenarios, whose base 1107 operation relies on obtaining the latest version of that NDO (i.e., a 1108 soil sensor in a farm providing different continuous parameters that 1109 are sent to a display or green-house regulation system) [FRESHNESS]. 1111 In the indirect approach, each cache consults the publisher of the 1112 cached NDO about its staleness before serving it. This approach 1113 assumes that the NDO includes the publisher information which can be 1114 used to reach the publisher. It is suitable for the NDO whose 1115 expiration time is difficult to be set in advance, e.g., a web page 1116 which contains main text (that stays the same ever after) and the 1117 interactive sections such as comments or ads (that are updated 1118 irregularly). 1120 It is often argued that ignoring stale NDOs in caches and simply 1121 providing new names for updated NDOs might be sufficient rather than 1122 using a staleness verification algorithm to manage them. However, 1123 notifying the new names of updated NDOs to users is not a trivial 1124 task. Unless the update is informed to all users at the same time, 1125 some users would use the old name although intending to retrieve the 1126 updated NDO. 1128 One research challenge is how to design consistency and coherence 1129 models for caching NDOs along with their revision handling and 1130 updating protocols in a scalable manner. 1132 4.8. Network Management 1134 Managing networks has been a core craft in the IP-based host-centric 1135 paradigm ever since the technology was introduced in production 1136 networks. However, at the onset of IP, management was considered 1137 primarily as an add-on. Essential tools that are used daily by 1138 networkers, such as ping and traceroute, did not become widely 1139 available until more than a decade or so after IP was first 1140 introduced. Management protocols, such as SNMP, also became 1141 available much later than the original introduction of IP and many 1142 still consider them insufficient despite the years of experience we 1143 have running host-centric networks. Today, when new networks are 1144 deployed network management is considered a key aspect for any 1145 operator, a major challenge which is directly reflected in higher 1146 OPEX if not done well. If we want ICN to be deployed in 1147 infrastructure networks, development of management tools and 1148 mechanisms must go hand-in-hand with the rest of the architecture 1149 design. 1151 Although defining an FCAPS model for ICN is clearly outside the scope 1152 of this document, there is a need for creating basic tools early on 1153 while ICN is still in the design and experimentation phases that can 1154 evolve over time and help network operations centers (NOCs) to define 1155 policies, validate that they are indeed used in practice, be notified 1156 early on about failures, determine and resolve configuration 1157 problems. AAA as well as performance management, from a NOC 1158 perspective, will also need to be considered. Given the expectations 1159 for a large number of nodes and unprecedented traffic volumes, 1160 automating tasks, or even better employing self-management mechanisms 1161 are preferred. The main challenge here is that all tools we have at 1162 our disposal today are node-centric, end-to-end oriented, or assuming 1163 a packet-stream communication environment. Rethinking reachability 1164 and operational availability, for example, can yield significant 1165 insights into how information-centric networks will be managed in the 1166 future. 1168 With respect to network management we see three different aspects. 1169 First, any operator needs to manage all resources available in the 1170 network, which can range from node connectivity to network bandwidth 1171 availability to in-network storage to multi-access support. In ICN, 1172 users will also bring into the network significant resources in terms 1173 of network coverage extension, storage, and processing capabilities. 1174 DTN characteristics should also be considered to the degree that this 1175 is possible (e.g., content dissemination through data mules). 1176 Secondly, given that nodes and links are not at the center of an 1177 information-centric network, network management should capitalize on 1178 native ICN mechanisms. For example, in-network storage and name 1179 resolution can be used for monitoring, while native publish/subscribe 1180 functionality can be used for triggering notifications. Finally, 1181 management is also at the core of network controlling capabilities by 1182 allowing operating actions to be mediated and decided, triggering and 1183 activating networking procedures in an optimized way. For example, 1184 monitoring aspects can be conjugated with different management 1185 actions in a coordinated way, allowing network operations to flow in 1186 a concertated manner. 1188 However, the considerations on leveraging intrinsic ICN mechanisms 1189 and capabilities to support management operations go beyond a simple 1190 mapping exercise. In fact, this raises a series of challenges on its 1191 own and opens up new possibilities for both ICN and network 1192 management as a concept. For instance, naming mechanisms are central 1193 to ICN intrinsic operations, which are used to identify and reach 1194 content under different aspects (e.g., hierarchically structured vs. 1195 'flattish' names). In this way, ICN is decoupled from host-centric 1196 aspects on which traditional networking management schemes rely upon. 1197 As such, questions are raised which can be translated directly into 1198 challenges for network management capabilities, such as, for example 1199 how to address a node or a network segment in a ICN naming paradigm, 1200 how to identify which node is connected where, and if there is a 1201 host-centric protocol running from which the management process can 1202 also leverage upon. 1204 But, on the other hand, these same inherent ICN characteristics also 1205 allow us to look into network management through a new perspective. 1206 By centering its operations around NDOs, one can conceive new 1207 management operations addressing, for example, per-content management 1208 or access control, as well as analyzing performance per NDO instead 1209 of per link or node. Moreover, such considerations can also be used 1210 to manage operational aspects of ICN mechanisms themselves. For 1211 example, [NDN-MGMT] re-utilizes inherent content-centric capabilities 1212 of CCN to manage optimal link connectivity for nodes, in concert with 1213 a network optimization process. Conversely, how these content- 1214 centric aspects can otherwise influence and impact management in 1215 other areas (e.g., security, resilience) is also important, as 1216 exemplified by in [CCN-ACCESS], where access control mechanisms are 1217 integrated into a prototype of the [PURSUIT] architecture. 1219 The set of core research challenges on ICN management include: 1221 o Management and control of NDO reception at the requestor 1223 o Coordination of management information exchange and control 1224 between ICN nodes and ICN network control points 1226 o Identification of management and controlling actions and items 1227 through information naming 1229 o Relationship between NDOs and host entities identification, i.e., 1230 how to identify a particular link, interface, or flow that need to 1231 be managed. 1233 4.9. Application Development 1235 ICN can be applied to different application domains and is expected 1236 to provide benefits for application developers by providing a more 1237 suitable interface for application developers (in addition to the 1238 other ICN benefits described above). [RFC7476] provides an overview 1239 of relevant application domains at large. This section discusses 1240 opportunities and challenges for selected application types. 1242 4.9.1. Web Applications 1244 Intuitively, the ICN request/response communication style seems to be 1245 directly mappable to web communication over HTTP. NDO names could be 1246 the equivalent of URIs in today's web, proprietary and transparent 1247 caching could be obsoleted by ICN in-network caching, and developers 1248 could directly use an ICN request/response API to build applications. 1250 Research efforts such as [ICN2014-WEB-NDN] have analysed real-world 1251 web applications and ways to implement them in ICN. The most 1252 significant insight is that, REST-style web communication heavily 1253 relies on transmitting user/application context information in HTTP 1254 GET requests, which would have to be mapped to corresponding ICN 1255 messages. The challenge in ICN would be how to exactly achieve that 1256 mapping. This could be done to some degree by extending name formats 1257 or by extending message structure to include cookies and similar 1258 context information. The design decisions would need to consider 1259 overhead in routers (if larger GET/Interest messages would have to be 1260 stored in corresponding tables on routers, for example. 1262 Other challenges include the ability to return different results 1263 based on requestor-specific processing in the presence on immutable 1264 objects (and name-object bindings) in ICN and the ability for 1265 efficient bidirectional communication, which would require some 1266 mechanism to name and reach requestor applications. 1268 4.9.2. Video Streaming and Download 1270 One of ICN's prime application areas is video streaming and download 1271 where accessing named data, object-level security and in-network 1272 storage can fulfil requirements for both video streaming and 1273 download. The applicability and benefits of ICN to video has been 1274 demonstrated by several prototype developments 1275 [ICN2014-AHLGREN-VIDEO-DEMO]. 1277 [I-D.irtf-icnrg-videostreaming] discusses the opportunities and 1278 challenges for implementing today's' video services such as DASH- 1279 based streaming and download over ICN, considering performance 1280 requirements, relationship to peer-to-peer live streaming, IPTV and 1281 DRM. 1283 In addition to just porting today's video application from a host- 1284 centric paradigm to ICN there are also promising opportunities to 1285 leverage the ICN network services for redesigning and thus 1286 significantly enhancing video access and distribution 1288 [ICNRG-2015-01-WESTPHAL]. For example, ICN store and forward could 1289 be leveraged for rate adaptation to achieve maximum throughput and 1290 optimal QoE in scenarios with varying link properties, if capacity 1291 information is fed back to rate selection algorithms at senders. 1292 Other optimizations such as more aggressive prefetching could be 1293 performed in the network by leveraging visibility of chunk NDO names 1294 and NDO metadata in the network. Moreover, multi-source rate 1295 adaptation in combination with network coding could enable better 1296 quality of experience, for example in multi-interface/access 1297 scenarios where multiple paths from client to upstream caches exist 1298 [RFC7476]. 1300 4.9.3. Internet of Things 1302 The essence of ICN lies in the name based routing that enables users 1303 to retrieve NDOs by the names regardless of their locations. As 1304 discussed in [RFC7476], ICN is suitable for IoT applications, where 1305 users consume IoT data objects without maintaining secure connections 1306 to them. The basic put/get style APIs of ICN enable developers to 1307 build IoT applications in a simple and fast manner. 1309 [RFC7476] details IoT scenarios while on-going efforts such as 1310 [I-D.lindgren-icnrg-efficientiot], [I-D.zhang-iot-icn-challenges], 1311 [ICN2014-NDNWILD] describe the requirements and challenges of ICN for 1312 IoT. For instance, many IoT applications depend on a PUSH model 1313 where data transmission is initiated by the publisher, and so they 1314 can support various real-time applications such as emergency alarms. 1315 However, ICN does not support the PUSH model in a native manner due 1316 to its inherent requestor-driven data transmission mechanism. The 1317 challenge would be how to efficiently support the PUSH model in ICN, 1318 and so it provides publish/subscribe style APIs for IoT application 1319 developers. This could be done by introducing other types of 1320 identifiers such as a device identifier or by extending the current 1321 request/response communication style, which may increase overhead in 1322 ICN routers. 1324 Moreover, key characteristics of the ICN underlying operation also 1325 impact important aspects of IoT, such as caching at network 1326 forwarding entities (which raise issues, e.g., concerning the 1327 freshness of the information received from the cache in contrast to 1328 the last value generated by a sensor) as well as pushing content to 1329 specific nodes (e.g., for controlling them), which requires 1330 individual addressing for identification. 1332 5. Security Considerations 1334 This document does not impact the security of the Internet. ICN 1335 security-related questions related to ICN are discussed in 1336 Section 4.2. 1338 6. IANA Considerations 1340 This document presents no IANA considerations. 1342 7. Informative References 1344 [BACKSCATTER] 1345 Waehlisch, M., Schmidt, TC., and M. Vahlenkamp, 1346 "Backscatter from the Data Plane - Threats to Stability 1347 and Security in Information-Centric Network 1348 Infrastructure", Computer Networks Vol 57, No. 16, pp. 1349 3192-3206, November 2013. 1351 [BREADCRUMBS] 1352 Rosensweig, E. and J. Kurose, "Breadcrumbs: Efficient, 1353 Best-Effort Content Location in Cache Networks", In 1354 Proceedings of the IEEE INFOCOM 2009, April 2009. 1356 [CCN] Jacobson, , K, , D, , F, , H, , and L, "Networking Named 1357 Content", CoNEXT 2009 , December 2009. 1359 [CCN-ACCESS] 1360 Fotiou, N., Marias, G., and G. Polyzos, "Access control 1361 enforcement delegation for information-centric networking 1362 architectures", In Proceedings of the second edition of 1363 the ICN workshop on Information-centric networking (ICN 1364 '12). ACM, New York, NY, USA, 85-90., 2012. 1366 [Chaum] Chaum, D. and E. van Heijst, "Group signatures", In 1367 Proceedings of EUROCRYPT, 1991. 1369 [COMPACT] Cowen, L., "Compact routing with minimum stretch", In 1370 Journal of Algorithms, vol. 38, pp. 170--183, 2001. 1372 [DONA] Koponen, T., Ermolinskiy, A., Chawla, M., Kim, K., gon 1373 Chun, B., and S. Shenker, "A Data-Oriented (and Beyond) 1374 Network Architecture", In Proceedings of SIGCOMM 2007, 1375 August 2007. 1377 [FRESHNESS] 1378 Quevedo, J., Corujo, D., and R. Aguiar, "Consumer Driven 1379 Information Freshness Approach for Content Centric 1380 Networking", IEEE INFOCOM Workshop on Name-Oriented 1381 Mobility Toronto, Canada, 2014, May 2014. 1383 [GREEDY] Papadopoulos, F., Krioukov, D., Boguna, M., and A. Vahdat, 1384 "Greedy forwarding in dynamic scale-free networks embedded 1385 in hyperbolic metric spaces", In Proceedings of the IEEE 1386 INFOCOM, San Diego, USA, 2010. 1388 [HRICP] Carofiglio, G., Gallo, M., and L. Muscariello, "Joint hop- 1389 by-hop and receiver-driven interest control protocol for 1390 content-centric networks", In Proceedings of ACM SIGCOMM 1391 ICN 2012, DOI 10.1145/2342488.2342497, 2012. 1393 [I-D.irtf-icnrg-videostreaming] 1394 Lederer, S., cedric.westphal@huawei.com, c., Mueller, C., 1395 Detti, A., Corujo, D., Timmerer, C., Posch, D., 1396 aytav.azgin, a., and S. Liu, "Adaptive Video Streaming 1397 over ICN", draft-irtf-icnrg-videostreaming-04 (work in 1398 progress), August 2015. 1400 [I-D.lindgren-icnrg-efficientiot] 1401 Lindgren, A., Abdesslem, F., Ahlgren, B., Schelen, O., and 1402 A. Malik, "Applicability and Tradeoffs of Information- 1403 Centric Networking for Efficient IoT", draft-lindgren- 1404 icnrg-efficientiot-03 (work in progress), July 2015. 1406 [I-D.zhang-iot-icn-challenges] 1407 Zhang, Y., Raychadhuri, D., Grieco, L., Baccelli, E., 1408 Burke, J., Ravindran, R., and G. Wang, "ICN based 1409 Architecture for IoT - Requirements and Challenges", 1410 draft-zhang-iot-icn-challenges-02 (work in progress), 1411 August 2015. 1413 [ICN2014-AHLGREN-VIDEO-DEMO] 1414 Ahlgren, B., Jonasson, A., and B. Ohlman, "Demo Overview: 1415 HTTP Live Streaming over NetInf Transport", ACM SIGCOMM 1416 Information-Centric Networking Conference Paris, France, 1417 2014, September 2014. 1419 [ICN2014-NDNWILD] 1420 Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M. 1421 Waehlisch, "Information Centric Networking in the IoT: 1422 Experiments with NDN in the Wild", ACM SIGCOMM 1423 Information-Centric Networking Conference Paris, France, 1424 2014, September 2014. 1426 [ICN2014-WEB-NDN] 1427 Moiseenko, I., Stapp, M., and D. Oran, "Communication 1428 Patterns for Web Interaction in Named Data Networking", 1429 ACM SIGCOMM Information-Centric Networking Conference 1430 Paris, France, 2014, September 2014. 1432 [ICNNAMING] 1433 Ghodsi, A., Koponen, T., Rajahalme, J., Sarolahti, P., and 1434 S. Shenker, "Naming in Content-Oriented Architectures", In 1435 Proceedings ACM SIGCOMM Workshop on Information-Centric 1436 Networking (ICN), 2011. 1438 [ICNRG-2015-01-WESTPHAL] 1439 Westphal, C., "Video over ICN", IRTF ICNRG Meeting 1440 Cambridge, Massachusetts, USA, 2015, URI 1441 http://www.ietf.org/proceedings/interim/2015/01/13/icnrg/ 1442 slides/slides-interim-2015-icnrg-1-0.pptx, January 2015. 1444 [ICNSURVEY] 1445 Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D., 1446 and B. Ohlman, "A Survey of Information-Centric 1447 Networking", In Communications Magazine, IEEE , vol.50, 1448 no.7, pp.26-36, DOI 10.1109/MCOM.2012.6231276, 2012. 1450 [MANI] Pentikousis, K. and T. Rautio, "A multiaccess Network of 1451 Information", WoWMoM 2010, IEEE , June 2010. 1453 [MDHT] D'Ambrosio, M., Dannewitz, C., Karl, H., and V. 1454 Vercellone, "MDHT: A hierarchical name resolution service 1455 for information-centric networks", ACM SIGCOMM workshop on 1456 Information-centric networking Toronto, Canada, 2011, 1457 August 2011. 1459 [NDN-MGMT] 1460 Corujo, D., Aguiar, R., Vidal, I., and J. Garcia-Reinoso, 1461 "A named data networking flexible framework for management 1462 communications", Communications Magazine, IEEE , vol.50, 1463 no.12, pp.36-43 , December 2012. 1465 [PURSUIT] Fotiou et al., N., "Developing Information Networking 1466 Further: From PSIRP to PURSUIT", In Proceedings of Proc. 1467 BROADNETS. ICST, 2010. 1469 [RANDOM] Gkantsidis, C., Mihail, M., and A. Saberi, "Random walks 1470 in peer-to-peer networks: algorithms and evaluation", In 1471 Perform. Eval., vol. 63, pp. 241--263, 2006. 1473 [RFC2002] Perkins, C., Ed., "IP Mobility Support", RFC 2002, DOI 1474 10.17487/RFC2002, October 1996, 1475 . 1477 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1478 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 1479 RFC5246, August 2008, 1480 . 1482 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1483 Housley, R., and W. Polk, "Internet X.509 Public Key 1484 Infrastructure Certificate and Certificate Revocation List 1485 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1486 . 1488 [RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams, 1489 Headers, and Boilerplates", RFC 5741, DOI 10.17487/ 1490 RFC5741, December 2009, 1491 . 1493 [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", 1494 RFC 5944, DOI 10.17487/RFC5944, November 2010, 1495 . 1497 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1498 Keranen, A., and P. Hallam-Baker, "Naming Things with 1499 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 1500 . 1502 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 1503 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 1504 "Information-Centric Networking: Baseline Scenarios", RFC 1505 7476, DOI 10.17487/RFC7476, March 2015, 1506 . 1508 [SEEN] Pentikousis, K., "In search of energy-efficient mobile 1509 networking", Communications Magazine, IEEE, vol. 48, no. 1510 1, pp.95-103 , January 2010. 1512 Appendix A. Acknowledgments 1514 The authors would like to thank Georgios Karagiannis for providing 1515 suggestions on QoS research challenges and Dimitri Papadimitriou for 1516 feedback on the routing section. 1518 Authors' Addresses 1520 Dirk Kutscher (editor) 1521 NEC 1522 Kurfuersten-Anlage 36 1523 Heidelberg 1524 Germany 1526 Email: kutscher@neclab.eu 1528 Suyong Eum 1529 National Institute of Information and Communications Technology 1530 4-2-1, Nukui Kitamachi, Koganei 1531 Tokyo 184-8795 1532 Japan 1534 Phone: +81-42-327-6582 1535 Email: suyong@nict.go.jp 1537 Kostas Pentikousis 1538 EICT GmbH 1539 Torgauer Strasse 12-15 1540 Berlin 10829 1541 Germany 1543 Email: k.pentikousis@eict.de 1545 Ioannis Psaras 1546 University College London, Dept. of E.E. Eng. 1547 Torrington Place 1548 London WC1E 7JE 1549 United Kingdom 1551 Email: i.psaras@ucl.ac.uk 1553 Daniel Corujo 1554 Universidade de Aveiro 1555 Instituto de Telecomunicacoes, Campus Universitario de Santiago 1556 Aveiro P-3810-193 1557 Portugal 1559 Email: dcorujo@av.it.pt 1560 Damien Saucez 1561 INRIA 1562 2004 route des Lucioles - BP 93 1563 Sophia Antipolis 06902 Cedex 1564 France 1566 Email: damien.saucez@inria.fr 1568 Thomas C. Schmidt 1569 HAW HAmburg 1570 Berliner Tor 7 1571 Hamburg 20099 1572 Germany 1574 Email: t.schmidt@ieee.org 1576 Matthias Waehlisch 1577 FU Berlin 1578 Takustr. 9 1579 Berlin 14195 1580 Germany 1582 Email: waehlisch@ieee.org