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