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