idnits 2.17.1 draft-irtf-icnrg-challenges-00.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 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 (September 01, 2014) is 3524 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2002 (Obsoleted by RFC 3220) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Kutscher, Ed. 3 Internet-Draft NEC 4 Intended status: Standards Track S. Eum 5 Expires: March 5, 2015 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 01, 2014 20 ICN Research Challenges 21 draft-irtf-icnrg-challenges-00 23 Abstract 25 This memo describes research challenges for Information-Centric 26 Networking. Information-Centric Networking is an approach to evolve 27 the Internet infrastructure to directly support information 28 distribution by introducing uniquely named data as a core Internet 29 principle. Data becomes independent from location, application, 30 storage, and means of transportation, enabling in-network caching and 31 replication. Challenges include naming, security, routing, system 32 scalability, mobility management, wireless networking, transport 33 services, in-network caching, and network management. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on March 5, 2015. 51 Copyright Notice 53 Copyright (c) 2014 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Problems with Information Distribution Today . . . . . . . . . 5 67 3. ICN Terminology and Concepts . . . . . . . . . . . . . . . . . 6 68 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4. ICN Research Challenges . . . . . . . . . . . . . . . . . . . 8 71 4.1. Naming and data authenticity . . . . . . . . . . . . . . . 8 72 4.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 4.2.1. Data Object Authentication . . . . . . . . . . . . . . 10 74 4.2.2. Binding NDOs to Real-World Identities . . . . . . . . 11 75 4.2.3. Traffic aggregation and filtering . . . . . . . . . . 11 76 4.2.4. State overloading . . . . . . . . . . . . . . . . . . 12 77 4.2.5. Delivering data objects from replicas . . . . . . . . 12 78 4.2.6. Cryptographic robustness . . . . . . . . . . . . . . . 13 79 4.2.7. Routing and forwarding information bases . . . . . . . 13 80 4.3. Routing and Resolution System Scalability . . . . . . . . 13 81 4.3.1. Route-By-Name Routing (RBNR) . . . . . . . . . . . . . 13 82 4.3.2. Lookup-By-Name Routing (LBNR) . . . . . . . . . . . . 14 83 4.3.3. Hybrid Routing (HR) . . . . . . . . . . . . . . . . . 15 84 4.4. Mobility Management . . . . . . . . . . . . . . . . . . . 15 85 4.5. Wireless Networking . . . . . . . . . . . . . . . . . . . 17 86 4.6. Transport Services . . . . . . . . . . . . . . . . . . . . 20 87 4.7. In-Network Caching . . . . . . . . . . . . . . . . . . . . 21 88 4.7.1. Cache Placement . . . . . . . . . . . . . . . . . . . 21 89 4.7.2. Content Placement -- Content-to-Cache Distribution . . 22 90 4.7.3. Request-to-Cache Routing . . . . . . . . . . . . . . . 23 91 4.7.4. Staleness Detection of Cached NDOs . . . . . . . . . . 24 92 4.8. Network Management . . . . . . . . . . . . . . . . . . . . 24 93 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 94 6. Informative References . . . . . . . . . . . . . . . . . . . . 27 95 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 29 96 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 29 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 99 1. Introduction 101 Distributing and manipulating named information is a major 102 application in the Internet today. In addition to web-based content 103 distribution, other distribution technologies (such as P2P and CDN) 104 have emerged and are promoting a communication model of accessing 105 data by name, regardless of origin server location. 107 In order to respond to increasing traffic volume in the current 108 Internet for applications such as mobile video and cloud computing, a 109 set of disparate technologies and distribution services are applied 110 that employ caching, replication and content distribution in 111 different specific ways. These approaches are currently deployed in 112 separate silos -- different CDN providers and P2P applications rely 113 on their own, often proprietary, distribution technologies. It is 114 not possible to uniquely and securely identify named information 115 independently of the distribution channel; and the different 116 distribution approaches are typically implemented as an overlay, 117 potentially leading to unnecessary inefficiency. 119 For example, creating and sharing multimedia content in a social 120 networking application today, typically requires uploading data 121 objects to centralized service provider platforms, from where it can 122 be accessed individually by other users. Even if content sharing is 123 intended to happen locally, e.g., in a local network or local area, 124 the actual communication will require interactions from any 125 interested user with the service provider. CDNs can alleviate the 126 situation only partly, because, due to organizational and economic 127 reasons, it is not common to deploy CDN gear ubiquitously. Moreover, 128 since CDNs and the respective communication sessions form overlays, 129 the actual communication, i.e., the requests for named content and 130 the actual responses, are largely invisible to the network, i.e., it 131 is not easily possible to optimize efficiency and performance. For 132 example in a wireless access network, it is not possible to leverage 133 the inherent broadcast nature of the medium (and avoid duplicate 134 transmission of the same content) due to limitations from point-to- 135 point and overlay communication. 137 Information-centric networking (ICN) is an approach to evolve the 138 Internet infrastructure to directly support this use by introducing 139 named data as a core network-layer primitive. Data objects become 140 independent of location, application, storage, and means of 141 transportation, allowing for inexpensive and ubiquitous in-network 142 caching and replication. The expected benefits are improved 143 efficiency, better support for provenance verification and name- 144 content binding validation, better scalability with respect to 145 information/bandwidth demand and better robustness in challenging 146 communication scenarios. 148 ICN concepts can be deployed by retooling the protocol stack: name- 149 based data access can be implemented on top of the existing IP 150 infrastructure, e.g., by providing resource naming, ubiquitous 151 caching and corresponding transport services, or it can be seen as a 152 packet-level internetworking technology that would cause fundamental 153 changes to Internet routing and forwarding. In summary, ICN is 154 expected to evolve the Internet architecture towards a network model 155 that is more suitable for the current and future use patterns. 157 This document presents the ICN research challenges that need to be 158 addressed in order to achieve these goals. These research challenges 159 are seen from a technical perspective, although business 160 relationships between Internet players will also influence 161 developments in this area. We leave business challenges for a 162 separate document, however. The objective of this note is to 163 document the technical challenges and corresponding current 164 approaches and to expose requirements that should be addressed by 165 future research work. 167 2. Problems with Information Distribution Today 169 The best current practice to manage the above-mentioned growth in 170 terms of data volume and number of devices is to increase 171 infrastructure investment, employ application-layer overlays such as 172 CDNs, P2P applications, and M2M application platforms that cache 173 content, provide location-independent access to data, and optimize 174 its delivery. In principle, such platforms provide a service model 175 of accessing named data objects (NDOs) (e.g., replicated web 176 resources, M2M data in data centers) instead of a host-to-host packet 177 delivery service model. 179 However, since this functionality resides in overlays only, the full 180 potential of content distribution and M2M application platforms 181 cannot be leveraged as the network is not aware of data requests and 182 data transmissions. This has the following impact: 184 o data traffic typically follows sub-optimal paths as it is 185 effectively routed depending on the overlay topology instead of 186 the Internet layer topology; 188 o network capabilities, such as multicast and broadcast, are largely 189 underutilized or not employed at all. As a result, request and 190 delivery for the same object have to be made multiple times; 192 o overlays typically require significant infrastructure support, 193 e.g., authentication portals, content storage, and applications 194 servers, making it often impossible to establish local, direct 195 communication; 197 o since the network is not aware of the nature of data objects, it 198 is unable to manage access and transmission (without layer 199 violations); 201 o provenance validation uses host authentication today. As such, 202 even if there are locally cached copies available, it is normally 203 not easily possible to validate their authenticity; and 205 o many applications follow their own approach to caching, 206 replication, transport, authenticity validation (if at all), 207 although they all share similar models for accessing named data 208 objects in the network. 210 3. ICN Terminology and Concepts 212 3.1. Terminology 214 Information-Centric Networking (ICN) A concept for communicating in 215 a network that provides accessing named data objects as a first 216 order service. See Section 3.2 for details. 218 Named Data Object (NDO): Addressable data unit in an ICN that can 219 represent a collection of bytes or a piece of information. In 220 ICN, each data object has a name bound to it, and there are 221 typically mechanisms to secure (and validate) this binding. 222 Different ICN approaches have different concepts for how to map 223 NDOs to individual units of transport. Within the context of this 224 document, an NDO is any named object that can be requested from 225 the network. 227 Requestor: Entitiy in an ICN network that is sending a request for a 228 Named Data Object to the network. 230 3.2. Concepts 232 Fundamentally, ICN is providing access to named data as a first-order 233 network service, i.e., the network is able to serve requests to named 234 data natively. That means, network nodes can receive requests for 235 named data and act as necessary, for example, by forwarding the 236 request to a suitable next-hop. Consequently, the network processes 237 requests for named data objects (and corresponding responses) 238 natively. Every network node on a path is enabled to perform 239 forwarding decisions, to cache objects etc. This enables the network 240 to forward such requests on optimal paths, employing the best 241 transmission technologies at every node, e.g., broadcast/multicast 242 transmission in wireless networks to avoid duplicate transmission of 243 both requests and responses. 245 In ICN there is a set of common concepts and node requirements beyond 246 this basic service model. Naming data objects is a key concept. In 247 general, ICN names represent neither network nodes nor interfaces -- 248 they represent NDOs independently of their location. Names do play a 249 key role in forwarding decisions and are used for matching requests 250 to responses: In order to provide better support for accessing copies 251 of NDOs regardless of their location, it is important to be able to 252 validate that a response actually delivers the bits that correspond 253 to an original request for named data. 255 Name-content binding validation is a fundamental security service in 256 ICN, and this is often achieved by establishing a verifiable binding 257 between the object name and the actual object or an identity that has 258 created the object. ICN can support other security services, such as 259 provenance validation, encryption -- depending on the details of 260 naming schemes, object models and assumptions on infrastructure 261 support. Security services such as name-content binding validation 262 are available to any node, i.e., not just the actual receivers. This 263 is an important feature, for enabling ingress gateways to check 264 object authenticity to prevent denial-of-service attacks. 266 Based on these fundamental properties it is possible to leverage 267 network storage ubiquitously: every node and every device can cache 268 data objects and respond to requests for such objects -- it is not 269 required to validate the authenticity of the node itself since name- 270 content bindings can be validated. Ubiquitous in-network storage can 271 be used for different purposes: it can enable sharing, i.e., the same 272 object copy can be delivered to multiple users/nodes as in today's 273 proxy caches and CDNs. It can also be used to make communication 274 more robust (and perform better) by enabling the network to answer 275 requests from local caches (instead of from origin servers). In case 276 of disruption (message not delivered), a node can re-send the 277 request, and it could be answered by an on-path cache, i.e., on the 278 other side of the disrupted link. The network itself would thus 279 support retransmissions -- enabling shorter round-trip times and 280 offloading origin servers and other parts of the network. 282 The request/response model and ubiquitous in-network storage also 283 enable new options for implementing transport services, i.e., 284 reliable transmission, flow control, etc. First of all, a request/ 285 response model can enable receiver-driven transport regimes, i.e., 286 receivers (the requestors of NDOs) can control message sending rates 287 by regulating the request sending rate (assuming that every response 288 message has to be triggered by a request message). Retransmission 289 would be achieved by re-sending requests, e.g., after a timeout. 291 Because objects can be replicated, object transmission and transport 292 sessions would not necessarily have end-to-end semantics: requests 293 can be answered by caches, and a node can select one or multiple 294 next-hop destinations for a particular request -- depending on 295 configuration, observed performance or other criteria. 297 This receiver-driven communication model potentially enables new 298 interconnection and business models: a request for named data can be 299 linked to an interest of a requestor (or requesting network) in data 300 from another peer, which could suggest modeling peering agreements 301 and charging accordingly. 303 4. ICN Research Challenges 305 4.1. Naming and data authenticity 307 Naming data objects is as important for ICN as naming hosts is for 308 today's Internet. Fundamentally, ICN requires unique names for 309 individual NDOs, since names are used for identifying objects 310 independently of their location or container. In addition, since 311 NDOs can be cached anywhere, the origin cannot be trusted anymore 312 hence the importance to establish a verifiable binding between the 313 object and its name (name-data integrity) so that a receiver can be 314 sure that the received bits do correspond to the NDO originally 315 requested (object authenticity). Information about an object's 316 provenance, i.e., who generated or published it, is also useful to 317 associate to the name. 319 The above functions are fundamentally required for the information- 320 centric network to work reliably, otherwise neither network elements 321 nor receivers can trust object authenticity. Lack of this trust 322 enables several attacks including DoS attacks by injecting spoofed 323 content into the network. There are different ways to use names and 324 cryptography to achieve the desired functions [ICNNAMING] 325 [ICNSURVEY], and there are different ways to manage namespaces 326 correspondingly. 328 Two types of naming schemes have been proposed in the ICN literature: 329 hierarchical and flat namespaces. For example, a hierarchical scheme 330 may have a structure similar to current URIs, where the hierarchy is 331 rooted in a publisher prefix. Such hierarchy enables aggregation of 332 routing information, improving scalability of the routing system. In 333 some cases, names are human-readable, which makes it possible for 334 users to manually type in names, reuse, and, to some extent, map the 335 name to user intent. 337 The second general class of naming schemes follows a "self- 338 certifying" approach, meaning that the object's name-data integrity 339 can be verified without requiring a public key infrastructure (PKI) 340 or other third party to first establish trust in the key. Self- 341 certification is achieved, e.g., by binding the hash of the NDO 342 content to the object's name. For instance, this can be done by 343 directly embedding the hash of the content in the name. Another 344 option is an indirect binding, which embeds the public key of the 345 publisher in the name and signs the hash of the content with the 346 corresponding secret key. The resulting names are typically non- 347 hierarchical, or flat, although the publisher field could be employed 348 to create a structure which could facilitate route aggregation. 349 There are several design trade-offs for ICN naming, which affect 350 routing and security. Self-certifying names are not human readable 351 nor hierarchical. They can however provide some structure for 352 aggregation, for instance, a name part corresponding to a publisher. 354 Research challenges specific to naming include: 356 o naming static data objects can be performed by using content 357 hashes as part of object names, so that publishers calculate the 358 hash over existing data objects and receivers (or any ICN node) 359 can validate the name-content binding by re-calculating the hash 360 and comparing it to the name (component). [RFC6920] specifies a 361 concrete naming format for this. 363 o naming dynamic objects refers to use cases where the name has to 364 be generated before the object is created. For example, this 365 could be the case for live streaming, when a publisher wants to 366 make the stream available by registering stream chunk names in the 367 network. One approach to this can be self-certified names as 368 described above. 370 o requestor privacy protection can be a challenge in ICN as a direct 371 consequence of the accessing-named-data-objects paradigm: if the 372 network can "see" requests and responses, it can also log request 373 history for network segments or individual users, which can be 374 undesirable, especially since names are typically expected to be 375 long-lived. That is, even if the name itself does not reveal much 376 information, the assumption is that the name can be used to 377 retrieve the corresponding data objects in the future. 379 o Updating and versioning NDO can be challenging because it can 380 contradict fundamental ICN assumptions: if an NDO can be 381 replicated and stored in in-network storage for later retrieval, 382 names have to be long-lived -- and the name-content binding must 383 not change: updating an object (i.e., changing the content without 384 generating a new name) is not possible. Versioning is one 385 possible solution, but requires a naming scheme that supports it 386 (and a way for requestors to learn about versions). 388 o Managing accessibility: whereas in ICN the general assumption is 389 to enable ubiquitous access to NDOs, there can be relevant use 390 cases where access to objects should be restricted, for example to 391 a specific user group. There are different approaches for this, 392 such as object encryption (requiring key distribution and related 393 mechanisms) or the concept of scopes, e.g., based on names that 394 can only be used/resolved under some constraints. 396 4.2. Security 398 Security can take many different forms in ICN and instead of 399 discussing specific attacks or technical details, we propose here the 400 most important security challenges that come from the shift to 401 information-centric communications. Some challenges are well- 402 understood, and there are (sometimes multiple different) approaches 403 to address them, whereas other challenges are active research and 404 engineering topics. 406 4.2.1. Data Object Authentication 408 As mentioned in section Section 4.1, data object authentication is an 409 important ICN feature, since ICN data objects are retrieved not only 410 from an original copy holder but also from any caching point. Hence, 411 the communication channel endpoints to retrieve NDOs are not 412 trustable anymore and solutions widely used today such as TLS 413 [RFC5246] cannot be used as a general solution. Since data objects 414 can be maliciously modified ICN should provide users with a security 415 mechanism to verify the origin and integrity of the data object, and 416 there are different ways to achieve this. 418 An efficient approach for static NDOs is providing a name-content- 419 binding by hashing an NDO and using the hash as a part of the 420 object's name. [RFC6920] provides a mechanism and a format for 421 representing a digest algorithm and the actual digest in a name 422 (amongst other information). 424 For dynamic objects (where it is desirable to refer to an NDO by name 425 before the object has been created), public-key cryptography is often 426 applied, i.e., every NDO would be authenticated by means of a 427 signature performed by the data object publisher so that any data 428 object consumer can verify the validity of the data object based on 429 the signature. However, in order to verify the signature of an 430 object, the consumer must know the public key of the entity that 431 signed the object. 433 One research challenge is then to support a mechanism to distribute 434 the publisher's public keys to the consumers of data objects. There 435 are two main approaches to achieve this; one is based on an external 436 third party authority such as hierarchical Public Key Infrastructure 437 (PKI) [RFC5280] and the other is to adapt a self-certifying scheme. 438 The former, as the name implies, depends on an external third party 439 authority to distribute the public key of the publisher for the 440 consumers. In a self-certifying scheme, the public key (or a hash of 441 it) would be used as part of the name -- which is sufficient to 442 validate the object's authenticity. 444 In cases where information about the origin of a data object is not 445 available by other means, the object itself would have to incorporate 446 the necessary information to determine the object publisher, for 447 example with a certificate, that can be validated through the PKI. 448 Once the certificate is authenticated, its public key can be used to 449 authenticate the signed data object itself. 451 4.2.2. Binding NDOs to Real-World Identities 453 In addition to validating NDO authenticity, it is still important to 454 bind real-world identities, e.g., a publisher identity, to objects, 455 so that a requestor can verify that a received object was actually 456 published by a certain source. 458 With hash-based and self-certifying names, real-world-identity 459 bindings are not intrinsically established: the name provides the 460 hash of the NDO or of the public key that has been used to sign the 461 NDO. There needs to be another binding to a real-world-identity if 462 that feature is requested. 464 If the object name directly provides the publisher name and if that 465 name is protected by a certificate that links to PKI-like trust 466 chain, the object name itself can provide an intrinsic binding to a 467 real-world identity. 469 Binding between NDOs and Real-World Identities is essential but there 470 is no universal way to achieve it as it is all intrinsic to a 471 particular ICN approach. 473 4.2.3. Traffic aggregation and filtering 475 One request message to retrieve a data object can actually aggregate 476 requests coming from several consumers. This aggregation of requests 477 reduces the overall traffic but makes per-requestor filtering harder. 478 The challenge in this case is to provide a mechanism that allows 479 request aggregation and per-requestor filtering. A possible solution 480 is to indicate the set of requestors in the aggregated request such 481 that the response can indicate the subset of requestors allowed to 482 access the data object. However, this solution requires 483 collaboration from other nodes in the network and is not suitable for 484 caching. Another possible solution is to encrypt data objects and 485 ensure that only authorised consumers can decrypt them. This 486 solution does not preclude caching and does not require collaboration 487 from the network. However, it implies a mechanism to generate group 488 keys (e.g., different private keys can be used to decrypt the same 489 encrypted data object) [Chaum]. 491 4.2.4. State overloading 493 ICN solutions that implement state on intermediate routers for 494 request routing or forwarding (e.g., CCN [CCN]) are subject to denial 495 of service attacks from overloading or superseding the internal state 496 of a router (e.g., 'interest flooding' [BACKSCATTER]). Additionally, 497 stateful forwarding can enable attack vectors such as resource 498 exhaustion or complexity attacks to the routing infrastructure. The 499 challenge is then to provision routers and construct internal state 500 in a way that alleviates sensibility to such attacks. The problem 501 becomes even harder, if the protocol does not provide information 502 about the origin of messages. Without origin, it is a particular 503 challenge to distinguish between regular (intense) use and misuse of 504 the infrastructure. 506 4.2.5. Delivering data objects from replicas 508 A common capability of ICN solutions is data replication and in- 509 network storage. Delivering replicated data objects from caches 510 decouples content consumption from data sources, which leads to a 511 loss of control on (1) content access, and (2) content dissemination. 512 In a widely distributed, decentralized environment like the Internet, 513 this raises several challenges. 515 One group of challenges is related to content management. Without 516 access control, a content provider looses the means to count and 517 survey content consumption, to limit access scopes, to control or 518 know about the number of copies of its data in the network, or to 519 withdraw publication reliably. Any non-cooperative or desynchronized 520 data cache may hinder an effective content management policy. 522 Another group of challenges arises from potential traffic 523 amplifications in the decoupled environment. ICN solutions that 524 attempt to retrieve content from several replicas in parallel, or 525 decorrelated network routing states, but also distributed attackers 526 may simultaneously initiate the transmission of content from multiple 527 replicas towards the same destination (e.g., 'initiated overloads' or 528 'blockades' [BACKSCATTER]). Methods for mitigating such threats need 529 rigorous forwarding checks that require alignment with caching 530 procedures (e.g., on-path or off-path). 532 4.2.6. Cryptographic robustness 534 Content producers sign their content to ensure the integrity of data 535 and to allow for data object authentication. This is a fundamental 536 requirement in ICN due to distributed caching. Publishers, who (a) 537 massively sign content, which is (b) long-lived, offer time and data 538 to an attacker for comprising cryptographic credentials. Signing 539 large amount of data eases common attacks that try to breach the key 540 of the publisher. Based on this observation, the following research 541 challenges appear. To which extent does the content publication 542 model conflict with cryptographic limitations? How can we achieve a 543 transparent re-signing without introducing additional cryptographical 544 weaknesses or key management overhead? 546 4.2.7. Routing and forwarding information bases 548 Section 4.3 shows that routing and forwarding information bases are 549 subject to scalability issue when routing by name is used. While the 550 system is designed it is not only important to ensure that it cannot 551 suffer from targeted attacks aiming at increasing routing and 552 forwarding information bases. As the routing system is tightly bound 553 to the ICN solution itself, there is no universal way to avoid such 554 attacks. However, a possible approache is to combine routing 555 information authenticity validation with filtering (e.g., maximum 556 deaggregation level whenever applicable, black lists, etc.). 558 4.3. Routing and Resolution System Scalability 560 ICN routing locates a data object based on its name which is 561 initially provided by a requestor. ICN routing may comprise three 562 steps: a name resolution step, a discovery step, and a delivery step. 563 The name resolution step translates the name of the requested data 564 object into its locator. The discovery step routes the request to 565 data object based on its name or locator. The last step (delivery) 566 routes the data object back to the requestor. Depending on how these 567 steps are combined, ICN routing schemes can be categorized as: Route- 568 By-Name Routing (RBNR), Lookup-By-Name Routing (LBNR), and Hybrid 569 Routing (HR). 571 4.3.1. Route-By-Name Routing (RBNR) 573 RBNR omits the first name resolution step. The name of data object 574 is directly used to route the request to the data object. Therefore, 575 routing information for each data object has to be maintained in the 576 routing table. Since the number of data objects is very large 577 (estimated as 10^11 back in 2007 [DONA] but this may be significantly 578 larger than that, e.g., 10^15 to 10^22), the size of routing tables 579 becomes a concern, as it can be proportional to the number of data 580 object unless an aggregation mechanism is introduced. On the other 581 hand, RBNR reduces overall latency and simplifies the routing process 582 due to the omission of the resolution process. For the delivery 583 step, RBNR needs another identifier (ID) of either host or location 584 to forward the requested data object back to the requestor. 585 Otherwise, an additional routing mechanism has to be introduced, such 586 as bread-crumbs routing [BREADCRUMBS], in which each request leaves 587 behind a trail of breadcrumbs along its forwarding path, and then the 588 response is forwarded back to the requestor consuming the trail. 589 Specific challenges include: 591 o How to aggregate the names of data objects to reduce the number of 592 routing entries? 594 o How does a user learn the name which is designed for aggregation 595 by provider? (For example, although we name our contribution as 596 "ICN research challenge", IRTF (provider) may want to change the 597 name to "/IETF/IRTF/ICN/Research challenge" for aggregation. In 598 this case, how does a user learn the name "/IETF/IRTF/ICN/Research 599 challenge" to retrieve the contribution initially named "ICN 600 research challenge" without any resolution process?) 602 o Without introducing the name aggregation scheme, can we still 603 achieve scalable routing by taking advantage of topological 604 structure and distributed copies? For example, employing compact 605 routing [COMPACT], random walk [RANDOM] or greedy routing 606 [GREEDY]. 608 o How to incorporate copies of a data object in in-network caches in 609 this routing scheme? 611 4.3.2. Lookup-By-Name Routing (LBNR) 613 LBNR uses the first name resolution step to translate the name of 614 requesting data object into its locator. Then, the second discovery 615 step is carried out based on the locator. Since IP addresses could 616 be used as locators, the discovery step can depend on the current IP 617 infrastructure. The delivery step can be implemented similarly to IP 618 routing. The locator of the requestor is included in the request 619 message, and then the requested data object is delivered to the 620 requestor based on the locator. A specific instantiation of such a 621 system is [MDHT]. Specific challenges include: 623 o How to build a scalable resolution system which provides 624 * Fast lookup: mapping the name of data object to its locators 625 (copies as well). 627 * Fast update: the location of data object is expected to change 628 frequently. Also, multiple data objects may change their 629 locations at the same time, e.g., data objects in a laptop. 631 o How to incorporate copies of a data object in in-network caches in 632 this routing scheme? 634 4.3.3. Hybrid Routing (HR) 636 HR combines RBNR and LBNR to benefit from their advantages. For 637 instance, within a single administrative domain, e.g., an ISP, where 638 scalability issues can be addressed with network planning, RBNR can 639 be adopted to reduce overall latency by omitting the resolution 640 process. On the other hand, LBNR can be used to route between 641 domains which have their own prefix (locator). A specific challenge 642 here is: 644 o How to design a scalable mapping system which, given the name of 645 data object, it should return a destination domain locator so that 646 a user request can be encapsulated and forwarded to the domain? 648 4.4. Mobility Management 650 Mobility management has been an active field in host-centric 651 communications for more than two decades. In IETF in particular, 652 starting with [RFC2002], a multitude of enhancements to IP have been 653 standardized aiming to "allow transparent routing of IP datagrams to 654 mobile nodes in the Internet" [RFC5944]. In a nutshell, mobility 655 management for IP networks is locator-oriented and relies on the 656 concept of a mobility anchor as a foundation for providing always-on 657 connectivity to mobile nodes. Other standards organizations, such as 658 3GPP, have followed similar anchor-based approaches. Traffic to and 659 from the mobile node must flow through the mobility anchor, typically 660 using a set of tunnels, enabling the mobile node to remain reachable 661 while changing its point of attachment to the network. 663 Needless to say, an IP network which supports node mobility is more 664 complex than one that does not, as specialized network entities must 665 be introduced in the network architecture. This is reflected in the 666 control plane as well, which carries mobility-related signaling 667 messages, establishes and tears down tunnels and so on. While mobile 668 connectivity was an afterthought in IP, in ICN this is considered a 669 primary deployment environment. Most, if not all, ICN proposals 670 consider mobility from the very beginning, although at varying levels 671 of architectural and protocol detail. That said, no solution has so 672 far come forward with a definite answer on how to handle mobility in 673 ICN using native primitives. In fact, we observe that mobility 674 appears to be addressed on ICN proposal specific basis. That is, 675 there is no single paradigm solution, akin to tunneling through a 676 mobility anchor in host-centric networking, that can be applied 677 across different ICN proposals. For instance, although widely- 678 deployed mobile network architectures typically come with their own 679 network entities and associated protocols, they follow the same line 680 of design with respect to managing mobility. This design thinking, 681 which calls for incorporating mobility anchors, permeates in the ICN 682 literature too. 684 However, employing mobility anchors and tunneling is probably not the 685 best way forward in ICN research for mobile networking. 686 Fundamentally this approach is anything but information-centric and 687 location-indepedent. In addition, as argued in [SEEN], current 688 mobility management schemes anchor information retrieval not only at 689 a specific network gateway (e.g., home agent in Mobile IP) but due to 690 the end-to-end nature of host-centric communication also at a 691 specific correspondent node. However, once a change in the point of 692 attachment occurs, information retrieval from the original 693 "correspondent node" may be no longer optimal. This was shown in 694 [MANI], for example, where a simple mechanism that triggers the 695 discovery of new retrieval providers for the same data object, 696 following a change in the point of attachment, clearly outperforms a 697 tunnel-based approach like Mobile IP in terms of object download 698 times. The challenge here is how to capitalize on location 699 information while facilitating the use of ICN primitives which 700 natively support multicast and anycast. 702 ICN naming and name resolution, as well as the security features that 703 come along should natively support mobility. For example, CCN [CCN] 704 does not have the restriction of spanning tree routing, so it is able 705 to take advantage of multiple interfaces or adapt to the changes 706 produced by rapid mobility (i.e., there is no need to bind a layer 3 707 address with a layer 2 address). In fact, client mobility can be 708 simplified by allowing requests for new content to normally flow from 709 different interfaces, or through newly connected points of attachment 710 to the network. However, when the node moving is the (only) content 711 source, it appears that more complex network support might be 712 necessary, including forwarding updates and cache rebuilding. A case 713 in point is a conversation network service, such as a voice or video 714 call between two parties. The requirements in this case are more 715 stringent when support for seamless mobility is required, esp. when 716 compared to content dissemination that is amenable to buffering. 717 Another parameter that needs to be paid attention to is the impact of 718 using different wireless access interfaces based on different 719 technologies, where the performance and link conditions can vary 720 widely depending of numerous factors. 722 In host-centric networking, mobility management mechanisms ensure 723 optimal handovers and (ideally) seamless transition from one point of 724 attachment to another. In ICN, however, the traditional meaning of 725 "point of attachment" no longer applies as communication is not 726 restrained by location-based access to data objects. Therefore, a 727 "seamless transition" in ICN ensures that content reception continues 728 without any perceptible change from the point of view of the ICN 729 application receiving that content. Moreover, this transition needs 730 to be executed in parallel with ICN content identification and 731 reaching mechanisms enabling scenarios, such as, preparation of the 732 content reaching process at the target connectivity point, prior to 733 the handover (to reduce link switch disturbances). Finally, these 734 mobility aspects can also be tightly coupled with network management 735 aspects, in respect to policy enforcement, link control and other 736 parameters necessary for establishing the node's link to the network. 738 In summary, the following research challenges on ICN mobility 739 management can be derived: 741 o How can mobility management take full advantage of native ICN 742 primitives? 744 o How do we avoid the need for mobility anchors in a network that by 745 design supports multicast, anycast and location-indepedent 746 information retrieval? 748 o How can content retrieval mechanisms interface with specific link 749 operations, such as identifying which links are available for 750 certain content? 752 o How can mobility be offered as a service, which is only activated 753 when the specific user/content/conditions require it? 755 o How can mobility management be coordinated between the node and 756 the network for optimization and policing procedures? 758 o How do we ensure that managing mobility does not introduce 759 scalability issues in ICN? 761 4.5. Wireless Networking 763 Today, all layer 2 wireless network radio access technologies (L2) 764 are developed with a clear assumption in mind: the waist of the 765 protocol stack is IP and it will be so for the foreseeable future. 766 By fixing the protocol stack waist, engineers can answer a large set 767 of questions, including how to handle conversational traffic (e.g., 768 voice calls) vs. web access to online resources, how to support 769 multicast (the IP flavor), and so on, in a rather straightforward 770 manner. Broadcast, on the other hand, which is inherent in wireless 771 communication is not fully taken advantage of. On the contrary, 772 researchers are often more concerned about introducing mechanisms 773 that ensure that "broadcast storms" do not take down a network. The 774 question of how broadcast can serve ICN needs better has yet to be 775 thoroughly investigated. 777 Wireless networking is often intertwined with mobility but this is 778 not always the case. In fact, empirical measurements often indicate 779 that many users tend to connect (and remain connected) to a single 780 Wi-Fi access point for considerable amounts of time. A case in 781 point, which is frequently cited in different variations in the ICN 782 literature, is access to a document repository during a meeting. For 783 instance, in a typical IETF working group meeting, a scribe takes 784 notes which are uploaded to a centralized repository (see Figure 1). 785 Subsequently, each meeting participant obtains a copy of the document 786 on their own devices for local use, annotation, and sharing with 787 colleagues that are not present at the meeting. Note that in this 788 example there is no node mobility and that it is not important 789 whether the document with the notes is uploaded in one go at the end 790 of the session or in a streaming-like fashion as is typical today 791 with online (cloud-based) document processing. 793 +---------------------+ 794 | Document Repository | 795 +---------------------+ 796 || 797 (Internet) 798 || 799 +--------------+ 800 | Access Point | 801 +--------------+ 802 / | \ 803 / | \ 804 / | \ 805 Scribe Participant 1 ... Participant N 807 Figure 1: Document sharing during a meeting 809 In this scenario we observe that the same data object bits 810 (corresponding to the meeting notes) need to traverse the wireless 811 medium at least N+1 times, where N is the number of meeting 812 participants obtaining a copy of the notes. In effect, a broadcast 813 medium is shoehorned into N+1 virtual unicast channels. One could 814 argue that wireless local connectivity is inexpensive, but this is 815 not the critical factor in this example. The actual information 816 exchange wastes N times the available network capacity, no matter 817 what is the spectral efficiency (or the economics) underlying the 818 wireless technology. This waste is a direct result of extending the 819 remote access paradigm from wired to wireless communication, 820 irrespective of the special characteristics of the latter. 822 It goes without saying that an ICN approach that does not take into 823 consideration the wireless nature of an interface will waste the same 824 amount of resources as a host-centric paradigm. In-network caching 825 at the wireless access point could reduce the amount of data carried 826 over the backhaul link but, if there is no change in the use of the 827 wireless medium, the NDO will still be carried over the wireless 828 ether N+1 times. Intelligent caching strategies, replica placement 829 cooperation and so on simply cannot alleviate this. On the other 830 hand, promiscuous interface operation and opportunistic caching would 831 maximize wireless network capacity utilization in this example. 833 Arguably, if one designs a future wireless access technology with an 834 information-centric "layer 3" in mind, many of the design choices 835 that are obvious in an all-IP architecture may no longer be valid. 836 Although this is clearly outside the scope of this document, a few 837 research challenges that the wider community may be interested in 838 include: 840 o Can we use wireless resources more frugally with the information- 841 centric paradigm than what is possible today in all-IP wireless 842 networks? 844 o In the context of wireless access, how can we leverage the 845 broadcast nature of the medium in an information-centric network? 847 o Would a wireless-oriented ICN protocol stack deliver significant 848 performance gains? How different would it be from a wired- 849 oriented ICN protocol stack? 851 o Is it possible that by changing the network paradigm to ICN we can 852 in practice increase the spectral efficiency (bits/s/Hz) of a 853 wireless network beyond what would be possible with today's host- 854 centric approaches? What would be the impact of doing so with 855 respect to energy consumption? 857 o Can wireless interface promiscuous operation coupled with 858 opportunistic caching increase ICN performance, and if so, by how 859 much? 861 o How can a conversational service be supported at least as 862 efficiently as today's state-of-the-art wireless networks deliver? 864 o What are the benefits from combining ICN with network coding in 865 wireless networks? 867 o How can MIMO and Coordinated Multipoint Transmission (CoMP) be 868 natively combined with ICN primitives in future cellular networks? 870 4.6. Transport Services 872 ICN's receiver-driven communication model as described above creates 873 new options for transport protocol design, as it does not rely solely 874 on end-to-end communication from a sender to a receiver. A requested 875 object can be accessible in multiple different network locations. A 876 node can thus decide how to utilize multiple sources, e.g., by 877 sending parallel requests for the same object or by switching sources 878 (or next hops) in a suitable schedule for a series of requests. 880 In this model, the requestor would control the data rate by 881 regulating its request sending rate and next by performing source/ 882 next-hop selections. Specific challenges depend on the specific ICN 883 approach, but general challenges for receiver-driven transport 884 protocols (or mechanisms, since dedicated protocols might not be 885 required) include flow and congestion control, fairness, network 886 utilization, stability (of data rates under stable conditions) etc. 887 [HRICP] describes a sample request rate control protocol and 888 corresponding design challenges. 890 As mentioned above, the ICN communication paradigm does not depend 891 strictly on end-to-end flows, as contents might be received from mid- 892 network caches. The traditional concept of a flow is then somewhat 893 cancelled as sub-flows, or flowlets might be formed on the fly, when 894 fractions of an NDO are transmitted from in-network caches. For a 895 transport layer protocol this is challenging, as any measurement 896 related to this flow, as traditionally done by transport protocols 897 such as TCP, will be hugely misleading. For example, false RTT 898 measurements will lead to largely variable average and smooth RTT 899 values, which in turn will trigger false timeout expirations. 901 Furthermore, out-of-order delivery is expected to be common in a 902 scenario where parts of a content file are retrieved from in-network 903 caches, rather than from the origin server. Several techniques for 904 dealing with out-of-order delivery have been proposed in the past for 905 TCP, some of which could potentially be modified and re-used in the 906 context of ICN. Further research is needed on this direction though 907 to i) choose the right technique and ii) adjust it according to the 908 requirements of the ICN architecture and transport protocol in use. 910 ICN offers routers the possibility to aggregate requests and can use 911 several paths, meaning that there is no such thing as a (dedicated) 912 end-to-end communication path, e.g., a router that receives two 913 requests for the same content at the same time only sends one request 914 to its neighbor. The aggregation of requests has a general impact on 915 transport service design. 917 Achieving fairness for requestors can be one challenge as it is not 918 possible to identify the number of requestors behind one particular 919 request. A second problem related to request aggregation is the 920 management of request retransmissions. Generally, it is assumed that 921 a router will not transmit a request if it transmitted an identical 922 request recently and because there is no information about the 923 requestor, the router cannot distinguish the initial request from a 924 client from a retransmission from the same client. In such a 925 situation, how routers can adapt their timers to use the best of the 926 communication paths. Finally, aggregation of requests has an impact 927 on the server (producer) side. This last has no way to determine the 928 number of clients actually consuming the content it is producing. 929 This shift of model influences the business model of the server, 930 e.g., how to implement pay-per-click. 932 NDOs can represent content used in different types of applications 933 with different QoS requirements, for example, interactive real-time 934 applications, media streaming, file download. Each of these 935 applications imposes different QoS requirements on different elements 936 in an information-centric network, e.g., regarding cache placement, 937 request-to-cache/source routing. Achieving the necessary quality-of- 938 service levels in a shared network is an active ICN research topic. 940 4.7. In-Network Caching 942 Explicitly named data objects allow for caching at virtually any 943 network element, including routers, proxy caches and end-host 944 machines. In-network caching can therefore improve network 945 performance by fetching content from nodes geographically placed 946 closer to the end-user. Several issues that need further 947 investigation have been identified with respect to in-network 948 caching. Here we list some of the most important challenges that 949 relate to the properties of the new ubiquitous caching system. 951 4.7.1. Cache Placement 953 The declining cost of fast memory gives the opportunity to deploy 954 caches in network routers and take advantage of explicitly named 955 cached contents. There exist two approaches to in-network caching, 956 namely, on-path and off-path caching. Both approaches have to 957 consider the issue of cache location. Off-path caching is similar to 958 traditional proxy-caching or CDN server placement. Retrieval of 959 contents from off-path caches requires redirection of requests and, 960 therefore, is closely related to the Request-to-Cache Routing problem 961 discussed later. Off-path caches have to be placed in strategic 962 points within a network in order to reduce the redirection delays and 963 the number of detour hops to retrieve cached contents. Previous 964 research on proxy-caching and CDN deployment is helpful in this case. 966 On the other hand, on-path caching requires less network intervention 967 and fits more neatly in ICN. However, on-path caching requires line- 968 speed operation, which places more constraints on the design and 969 operation of in-network caching elements. Furthermore, the gain of 970 such a system of on-path in-network caches relies on opportunistic 971 cache hits and has therefore been considered of limited benefit, 972 given the huge amount of contents hosted in the Internet. For this 973 reason, network operators might initially consider only a limited 974 number of network elements to be upgraded to in-network caching 975 elements. The decision on which nodes should be equipped with caches 976 is an open issue and might be based, among others, on topological 977 criteria, or traffic characteristics. These challenges relate to 978 both the Content Placement Problem and the Request-to-Cache Routing 979 Problem discussed below. 981 In call cases, however, the driver for the implementation, deployment 982 and operation of in-network caches will be its cost. Operating 983 caches at line speed inevitably requires faster memories, which 984 increase the implementation cost. Based on the capital to be 985 invested, ISPs will need to make strategic decisions on the cache 986 placement, which can be driven by several factors, such as: avoid 987 inter-domain/expensive links, centrality of nodes, size of domain and 988 the corresponding spatial locality of users, traffic patterns in a 989 specific part of the network (e.g., university vs. business vs. 990 fashion district of a city). 992 4.7.2. Content Placement -- Content-to-Cache Distribution 994 Given a number of (on-path or off-path) in-network caching elements, 995 content-to-cache distribution will affect both the dynamics of the 996 system, in terms of request redirections (mainly in case of off-path 997 caches) and the gain of the system in terms of cache hits. A 998 straightforward approach to content placement is on-path placement of 999 contents as they travel from source to destination. This approach 1000 reduces the computation and communication overhead of placing content 1001 within the network but, on the other hand, might reduce the chances 1002 of hitting cached contents. This relates to the Request-to-Cache 1003 Routing problem discussed next. 1005 Furthermore, the number of replicas held in the system brings up 1006 resource management issues in terms of cache allocation. For 1007 example, continuously replicating data objects in all network 1008 elements results in redundant copies of the same objects. The issue 1009 of redundant replication has been investigated in the past for 1010 hierarchical web caches. However, in hierarchical web-caching, 1011 overlay systems coordination between the data and the control plane 1012 can guarantee increased performance in terms of cache hits. Line- 1013 speed, on-path in-network caching poses different requirements and 1014 therefore, new techniques need to be investigated. In this 1015 direction, there already exist some studies that attempt to reduce 1016 redundancy of cached copies. However, the issue of coordinated 1017 content placement in on-path caches still remains open. 1019 The Content-to-Cache Allocation problem relates also to the 1020 characteristics of the content to be cached. Popular content might 1021 need to be placed where it is going to be requested next. 1022 Furthermore, issues of "expected content popularity" or temporal 1023 locality need to be taken into account in designing in-network 1024 caching algorithms in order for some contents to be given priority 1025 (e.g., popular content vs. one-timers). The criteria as to which 1026 contents should be given priority in in-network content caches relate 1027 also to the business relationships between content providers and 1028 network operators. Business model issues will drive some of these 1029 decisions on content-to-cache distribution, but such issues are 1030 outside the scope of this note and are not discussed here further. 1032 4.7.3. Request-to-Cache Routing 1034 In order to take advantage of cached contents, requests have to be 1035 forwarded to the nodes that temporarily host (cache) the 1036 corresponding contents. This challenge relates to name-based 1037 routing, discussed before. Requests should ideally follow the path 1038 to the cached content. However, instructions as to which content is 1039 cached where cannot be broadcast throughout the network. Therefore, 1040 the knowledge of a content's location at the time of the request 1041 might either not exist, or it might not be accurate (i.e., contents 1042 might have been removed by the time a request is redirected to a 1043 specific node). 1045 Coordination between the data and the control planes to update 1046 information of cached contents has been considered, but in this case 1047 scalability issues arise. We therefore, have two options. We either 1048 have to rely on opportunistic caching, where requests are forwarded 1049 to a server and in case the content is found on the path, then the 1050 content is fetched from this node (instead of the original server); 1051 or we employ cache-aware routing techniques. Cache-aware routing can 1052 either involve both the control and the data plane, or only one of 1053 them. Furthermore, cache-aware routing can be done in a domain-wide 1054 scale or can involve more than one individual Autonomous System (AS). 1055 In the latter case, business relationships between ASes might need to 1056 be exploited in order to build a scalable model. 1058 4.7.4. Staleness Detection of Cached NDOs 1060 Due to the largely distributed copies of NDOs in in-network caches, 1061 ICN should be able to provide a staleness verification algorithm 1062 which provides synchronization of NDOs located at their providers and 1063 in-network caching points. Two types of approaches can be considered 1064 for this problem, namely direct and indirect approaches. 1066 In the direct approach, each cache looks up certain information in 1067 the name of NDO, e.g., time stamp which directly indicates its 1068 staleness. This approach is well applicable to some NDOs that come 1069 from machine-to-machine and Internet of Things scenarios, whose base 1070 operation relies on obtaining the latest version of that NDO (i.e., a 1071 soil sensor in a farm providing different continuous parameters that 1072 are sent to a display or green-house regulation system) [freshness]. 1074 In the indirect approach, each cache consults the publisher of the 1075 cached NDO about its staleness before serving it. This approach 1076 assumes that the name of NDO includes the publisher information which 1077 can be used to reach to the publisher. It is suitable for the NDO 1078 whose expiring time is difficult to be set in advance, e.g., a 1079 webpage which contains main text (that stays the same ever after) and 1080 the interactive section such as comments or ads (that is updated 1081 irregularly). 1083 It is often argued that ignoring stale NDOs in caches and simply 1084 providing new names for updated NDOs might be sufficient rather than 1085 using a staleness verification algorithm to manage them. However, 1086 notifying the new names of updated NDOs to users is not a trivial 1087 task. Unless the update is informed to entire users at the same 1088 time, some users would use the old acquainted name by intending to 1089 retrieve the updated NDO. 1091 One research challenge is how to design consistency and coherence 1092 models for caching NDOs along with their revision handling and 1093 updating protocols in a scalable manner. 1095 4.8. Network Management 1097 Managing networks has been a core craft in the IP-based host-centric 1098 paradigm ever since the technology was introduced in production 1099 networks. However, at the onset of IP, management was considered 1100 primarily as an add-on. Essential tools that are used daily by 1101 networkers, such as ping and traceroute, did not become widely 1102 available until more than a decade or so after IP was first 1103 introduced. Management protocols, such as SNMP, also became 1104 available much later than the original introduction of IP and many 1105 still consider them insufficient despite the years of experience we 1106 have running host-centric networks. Today, when new networks are 1107 deployed network management is considered a key aspect for any 1108 operator, a major challenge which is directly reflected in higher 1109 OPEX if not done well. If we want ICN to be deployed in 1110 infrastructure networks, development of management tools and 1111 mechanisms must go hand-in-hand with the rest of the architecture 1112 design. 1114 Although defining an FCAPS model for ICN is clearly outside the scope 1115 of this document, there is a need for creating basic tools early on 1116 while ICN is still in the design and experimentation phases that can 1117 evolve over time and help network operations centers (NOC) to define 1118 policies, validate that they are indeed used in practice, be notified 1119 early on about failures, determine and resolve configuration 1120 problems. AAA as well as performance management, from a NOC 1121 perspective, will also need to be considered. Given the expectations 1122 for a large number of nodes and unprecedented traffic volumes, 1123 automating tasks, or even better employing self-management mechanisms 1124 is preferred. The main challenge here is that all tools we have at 1125 our disposal today are node-centric, end-to-end oriented, or assuming 1126 a packet-stream communication environment. Rethinking reachability 1127 and operational availability, for example, can yield significant 1128 insights into how information-centric networks will be managed in the 1129 future. 1131 With respect to network management we see three different aspects. 1132 First, any operator needs to manage all resources available in the 1133 network, which can range from node connectivity to network bandwidth 1134 availability to in-network storage to multi-access support. In ICN, 1135 users will also bring into the network significant resources in terms 1136 of network coverage extension, storage, and processing capabilities. 1137 DTN characteristics should also be considered to the degree that this 1138 is possible (e.g., content dissemination through data mules). 1139 Secondly, given that nodes and links are not at the center of an 1140 information-centric network, network management should capitalize on 1141 native ICN mechanisms. For example, in-network storage and name 1142 resolution can be used for monitoring, while native publish/subscribe 1143 functionality can be used for triggering notifications. Finally, 1144 management is also at the core of network controlling capabilities by 1145 allowing operating actions to be mediated and decided, triggering and 1146 activating networking procedures in an optimized way. For example, 1147 monitoring aspects can be conjugated with different management 1148 actions in a coordinated way, allowing network operations to flow in 1149 a concertated way. 1151 However, the considerations on leveraging intrinsic ICN mechanisms 1152 and capabilities to support management operations go beyond a simple 1153 mapping exercise. In fact, not only it raises a series of challenges 1154 on its own, but also opens up new possibilities for both ICN and 1155 "network management" as a concept. For instance, naming mechanisms 1156 are central to ICN intrinsic operations, which are used to identify 1157 and reach content under different aspects (e.g., hierarchically 1158 structured vs. 'flattish' names). In this way, ICN is decoupled from 1159 host-centric aspects on which traditional networking management 1160 schemes rely upon. As such, questions are raised which can directly 1161 be translated into challenges for network management capability, such 1162 as, for example how to address a node or a network segment in a ICN 1163 naming paradigm, how to identify which node is connected "where", and 1164 if there is a host-centric protocol running from which the management 1165 process can also leverage upon. 1167 But, on the other hand, these same inherent ICN characteristics also 1168 allow us to look into network management through a new perspective. 1169 By centering its operations around content, one can conceive new 1170 management operations addressing, for example, per-content management 1171 or access control, as well as analyzing performance per content name 1172 instead of per link or node. Moreover, such considerations can also 1173 be used to manage operational aspects of ICN mechanisms themselves. 1174 For example, [NDN-MGMT] re-utilizes inherent content-centric 1175 capabilities of CCN to manage optimal link connectivity for nodes, in 1176 concert with a network optimization process. Conversely, how these 1177 content-centric aspects can otherwise influence and impact management 1178 in other areas (e.g., security, resilience) is also important, as 1179 exemplified by in [ccn-access], where access control mechanisms are 1180 integrated into a prototype of the [PURSUIT] architecture. 1182 In this way, a set of core research challenges on ICN management can 1183 be derived as: 1185 o Manage and control content reception at the destination 1187 o Coordination of management information exchange and control 1188 between ICN nodes and ICN network control points 1190 o Identification of management and controlling actions and items 1191 through information naming 1193 o Relationship between NDOs and host entities identification (i.e., 1194 how to identify a particular link, interface or flow that need to 1195 be managed) 1197 5. Security Considerations 1199 Security related questions related to ICN are discussed in 1200 Section 4.2. 1202 6. Informative References 1204 [BACKSCATTER] 1205 Waehlisch, M., Schmidt, TC., and M. Vahlenkamp, 1206 "Backscatter from the Data Plane - Threats to Stability 1207 and Security in Information-Centric Network 1208 Infrastructure", Computer Networks Vol 57, No. 16, pp. 1209 3192-3206, November 2013. 1211 [BREADCRUMBS] 1212 Rosensweig, E. and J. Kurose, "Breadcrumbs: Efficient, 1213 Best-Effort Content Location in Cache Networks", 1214 In Proceedings of the IEEE INFOCOM 2009, April 2009. 1216 [CCN] Jacobson, K, D, F, H, and L, "Networking Named Content", 1217 CoNEXT 2009 , December 2009. 1219 [COMPACT] Cowen, L., "Compact routing with minimum stretch", 1220 In Journal of Algorithms, vol. 38, pp. 170--183, 2001. 1222 [Chaum] Chaum, D. and E. van Heijst, "Group signatures", 1223 In Proceedings of EUROCRYPT, 1991. 1225 [DONA] Koponen, T., Ermolinskiy, A., Chawla, M., Kim, K., gon 1226 Chun, B., and S. Shenker, "A Data-Oriented (and Beyond) 1227 Network Architecture", In Proceedings of SIGCOMM 2007, 1228 August 2007. 1230 [GREEDY] Papadopoulos, F., Krioukov, D., Boguna, M., and A. Vahdat, 1231 "Greedy forwarding in dynamic scale-free networks embedded 1232 in hyperbolic metric spaces", In Proceedings of the IEEE 1233 INFOCOM, San Diego, USA, 2010. 1235 [HRICP] Carofiglio, G., Gallo, M., and L. Muscariello, "Joint hop- 1236 by-hop and receiver-driven interest control protocol for 1237 content-centric networks", In Proceedings of ACM SIGCOMM 1238 ICN 2012, DOI 10.1145/2342488.2342497, 2012. 1240 [ICNNAMING] 1241 Ghodsi, A., Koponen, T., Rajahalme, J., Sarolahti, P., and 1242 S. Shenker, "Naming in Content-Oriented Architectures", 1243 In Proceedings ACM SIGCOMM Workshop on Information-Centric 1244 Networking (ICN), 2011. 1246 [ICNSURVEY] 1247 Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D., 1248 and B. Ohlman, "A Survey of Information-Centric 1249 Networking", In Communications Magazine, IEEE , vol.50, 1250 no.7, pp.26-36, DOI 10.1109/MCOM.2012.6231276, 2012. 1252 [MANI] Pentikousis, K. and T. Rautio, "A multiaccess Network of 1253 Information", WoWMoM 2010, IEEE , June 2010. 1255 [MDHT] D'Ambrosio, M., Dannewitz, C., Karl, H., and V. 1256 Vercellone, "MDHT: A hierarchical name resolution service 1257 for information-centric networks", ACM SIGCOMM workshop on 1258 Information-centric networking Toronto, Canada, 2011, 1259 August 2011. 1261 [NDN-MGMT] 1262 Corujo, D., Aguiar, R., Vidal, I., and J. Garcia-Reinoso, 1263 "A named data networking flexible framework for management 1264 communications", Communications Magazine, IEEE , vol.50, 1265 no.12, pp.36-43 , December 2012. 1267 [PURSUIT] Fotiou et al., N., "Developing Information Networking 1268 Further: From PSIRP to PURSUIT", In Proceedings of Proc. 1269 BROADNETS. ICST, 2010. 1271 [RANDOM] Gkantsidis, C., Mihail, M., and A. Saberi, "Random walks 1272 in peer-to-peer networks: algorithms and evaluation", 1273 In Perform. Eval., vol. 63, pp. 241--263, 2006. 1275 [RFC2002] Perkins, C., "IP Mobility Support", RFC 2002, 1276 October 1996. 1278 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1279 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1281 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1282 Housley, R., and W. Polk, "Internet X.509 Public Key 1283 Infrastructure Certificate and Certificate Revocation List 1284 (CRL) Profile", RFC 5280, May 2008. 1286 [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", 1287 RFC 5944, November 2010. 1289 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 1290 Keranen, A., and P. Hallam-Baker, "Naming Things with 1291 Hashes", RFC 6920, April 2013. 1293 [SEEN] Pentikousis, K., "In search of energy-efficient mobile 1294 networking", Communications Magazine, IEEE, vol. 48, no. 1295 1, pp.95-103 , January 2010. 1297 [ccn-access] 1298 Fotiou, N., Marias, G., and G. Polyzos, "Access control 1299 enforcement delegation for information-centric networking 1300 architectures", In Proceedings of the second edition of 1301 the ICN workshop on Information-centric networking (ICN 1302 '12). ACM, New York, NY, USA, 85-90., 2012. 1304 [freshness] 1305 Quevedo, J., Corujo, D., and R. Aguiar, "Consumer Driven 1306 Information Freshness Approach for Content Centric 1307 Networking", IEEE INFOCOM Workshop on Name-Oriented 1308 Mobility Toronto, Canada, 2014, May 2014. 1310 Appendix A. Acknowledgments 1312 The authors would like to thank Georgios Karagiannis for providing 1313 suggestions on QoS research challenges. 1315 Appendix B. Changes 1317 draft-icnrg-challenges-00 1319 * added paragraph on QoS to transport services section 1321 * rewrote text 4.7.4 (Staleness Detection of Cached NDOs) 1323 Authors' Addresses 1325 Dirk Kutscher (editor) 1326 NEC 1327 Kurfuersten-Anlage 36 1328 Heidelberg, 1329 Germany 1331 Phone: 1332 Email: kutscher@neclab.eu 1333 Suyong Eum 1334 National Institute of Information and Communications Technology 1335 4-2-1, Nukui Kitamachi, Koganei 1336 Tokyo 184-8795 1337 Japan 1339 Phone: +81-42-327-6582 1340 Email: suyong@nict.go.jp 1342 Kostas Pentikousis 1343 EICT GmbH 1344 Torgauer Strasse 12-15 1345 Berlin 10829 1346 Germany 1348 Email: k.pentikousis@eict.de 1350 Ioannis Psaras 1351 University College London, Dept. of E.E. Eng. 1352 Torrington Place 1353 London WC1E 7JE 1354 United Kingdom 1356 Email: i.psaras@ucl.ac.uk 1358 Daniel Corujo 1359 Universidade de Aveiro 1360 Instituto de Telecomunicacoes, Campus Universitario de Santiago 1361 Aveiro P-3810-193 1362 Portugal 1364 Email: dcorujo@av.it.pt 1366 Damien Saucez 1367 INRIA 1368 2004 route des Lucioles - BP 93 1369 Sophia Antipolis 06902 Cedex 1370 France 1372 Email: damien.saucez@inria.fr 1373 Thomas C. Schmidt 1374 HAW HAmburg 1375 Berliner Tor 7 1376 Hamburg 20099 1377 Germany 1379 Email: t.schmidt@ieee.org 1381 Matthias Waehlisch 1382 FU Berlin 1383 Takustr. 9 1384 Berlin 14195 1385 Germany 1387 Email: waehlisch@ieee.org