idnits 2.17.1 draft-jhong-icnrg-nrs-requirements-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 30, 2017) is 2362 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 548, but not defined == Unused Reference: 'Jacobson' is defined on line 622, but no explicit reference was found in the text == Unused Reference: 'Baid' is defined on line 627, but no explicit reference was found in the text == Unused Reference: 'Bari' is defined on line 632, but no explicit reference was found in the text == Unused Reference: 'ID.Wang' is defined on line 648, but no explicit reference was found in the text == Unused Reference: 'Sevilla' is defined on line 662, but no explicit reference was found in the text == Unused Reference: 'RFC7252' is defined on line 674, but no explicit reference was found in the text == Unused Reference: 'ID.Shelby' is defined on line 679, but no explicit reference was found in the text == Unused Reference: 'CoRE' is defined on line 683, but no explicit reference was found in the text == Unused Reference: 'Westphal' is defined on line 687, but no explicit reference was found in the text == Unused Reference: 'Mosko' is defined on line 691, but no explicit reference was found in the text == Unused Reference: 'RFC6830' is defined on line 695, but no explicit reference was found in the text == Unused Reference: 'RFC6833' is defined on line 700, but no explicit reference was found in the text == Unused Reference: 'Zhang' is defined on line 705, but no explicit reference was found in the text == Unused Reference: 'Dannewitz' is defined on line 712, but no explicit reference was found in the text == Unused Reference: 'Seskar' is defined on line 717, but no explicit reference was found in the text == Unused Reference: 'Dannewitz2' is defined on line 721, but no explicit reference was found in the text == Unused Reference: 'Vu' is defined on line 727, but no explicit reference was found in the text == Unused Reference: 'Hong' is defined on line 732, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-10 -- No information found for draft-wood-icnrg-ccnxmanifests - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) -- Obsolete informational reference (is this intentional?): RFC 6833 (Obsoleted by RFC 9301) == Outdated reference: A later version (-02) exists of draft-ravi-icnrg-ccn-forwarding-label-01 Summary: 0 errors (**), 0 flaws (~~), 23 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group J. Hong 3 Internet-Draft ETRI 4 Intended status: Informational L. Dong 5 Expires: May 3, 2018 Huawei 6 T. You 7 ETRI 8 C. Westphal 9 Huawei 10 Y-G. Hong 11 ETRI 12 GQ. Wang 13 Huawei 14 J. Wang 15 City University Hong Kong 16 October 30, 2017 18 Requirements for Name Resolution Service in ICN 19 draft-jhong-icnrg-nrs-requirements-02 21 Abstract 23 This document discusses the motivation and requirements for Name 24 Resolution Service (NRS) in ICN. The NRS in ICN is to translate an 25 object name into some other information such as locator and another 26 name which is used for forwarding the object request. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 3, 2018. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 64 3. Name Resolution Service in ICN . . . . . . . . . . . . . . . 4 65 3.1. Standalone name resolution approach . . . . . . . . . . . 4 66 3.2. Name based routing approach . . . . . . . . . . . . . . . 4 67 3.3. Hybrid approach . . . . . . . . . . . . . . . . . . . . . 5 68 3.4. Comparisons of name resolution approaches . . . . . . . . 5 69 4. Motivation of NRS in ICN . . . . . . . . . . . . . . . . . . 6 70 4.1. Heterogeneous names in ICN . . . . . . . . . . . . . . . 6 71 4.2. Dynamism in ICN . . . . . . . . . . . . . . . . . . . . . 7 72 4.3. Routing system in ICN . . . . . . . . . . . . . . . . . . 8 73 4.4. Use cases of NRS . . . . . . . . . . . . . . . . . . . . 8 74 4.4.1. Flat name based routing support . . . . . . . . . . . 8 75 4.4.2. Publisher mobility support . . . . . . . . . . . . . 9 76 4.4.3. Scalable routing support . . . . . . . . . . . . . . 9 77 4.4.4. Nameless object support . . . . . . . . . . . . . . . 10 78 5. Requirements for NRS in ICN . . . . . . . . . . . . . . . . . 10 79 5.1. Requirements as a service . . . . . . . . . . . . . . . . 10 80 5.1.1. Delay sensitivity . . . . . . . . . . . . . . . . . . 10 81 5.1.2. Accuracy . . . . . . . . . . . . . . . . . . . . . . 10 82 5.1.3. Resolution guarantee . . . . . . . . . . . . . . . . 10 83 5.2. Requirements as a system . . . . . . . . . . . . . . . . 11 84 5.2.1. Scalability . . . . . . . . . . . . . . . . . . . . . 11 85 5.2.2. Manageability . . . . . . . . . . . . . . . . . . . . 11 86 5.2.3. Deployability . . . . . . . . . . . . . . . . . . . . 11 87 5.2.4. Fault tolerance . . . . . . . . . . . . . . . . . . . 11 88 5.3. Requirements on Security aspect . . . . . . . . . . . . . 11 89 5.3.1. Accessibility . . . . . . . . . . . . . . . . . . . . 11 90 5.3.2. Authentication . . . . . . . . . . . . . . . . . . . 12 91 5.3.3. Data confidentiality . . . . . . . . . . . . . . . . 12 92 5.3.4. Dat privacy . . . . . . . . . . . . . . . . . . . . . 12 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 96 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 97 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 98 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 99 9.2. Informative References . . . . . . . . . . . . . . . . . 13 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 102 1. Introduction 104 The current Internet is a host-centric networking, where hosts are 105 uniquely identified with IP addresses and communication is possible 106 between any pair of hosts. Thus, information in the current Internet 107 is identified by the name of host where the information is stored. 108 In contrast to the host-centric networking, the primary communication 109 objects in Information-centric networking (ICN) are the named data 110 objects (NDOs) and they are uniquely identified by the location- 111 independent names. Thus, ICN aiming to the efficient dissemination 112 and retrieval of the NDOs in a global scale has been identified and 113 acknowledged as a promising technology for the future Internet 114 architecture to overcome the limitations of the current Internet such 115 as scalability, mobility, etc.[Ahlgren] [Xylomenos]. ICN also has 116 been emerged as a candidate architecture for IoT environment since 117 IoT focuses on data and information rather than end-to-end 118 communications [Baccelli] [Amadeo] [Quevedo] [Amadeo2] [ID.Zhang2]. 120 Since naming data independently from the current location where it is 121 stored is a primary concept of ICN, how to find the NDO using the 122 location-independent name is one of the most important design 123 challenges in ICN. Such ICN routing may comprise three steps 124 [RFC7927] : 126 o Name resolution : matches/translates a content name to locators of 127 providers/sources that can provide the content. 129 o Content discovery : routes the content request towards the content 130 either based on its name or locator. 132 o Content delivery : transfers the content to the requester. 134 In three steps of ICN routing, this document focuses only the name 135 resolution step which translates a content name to its locators. In 136 addition, this document considers all other types of name resolution 137 in ICN such as name to name, name to manifest. 139 Thus, this document presents the definition of the Name Resolution 140 Service (NRS) in ICN and discusses the motivation and the 141 requirements in designing the NRS for ICN. 143 2. Conventions and Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 3. Name Resolution Service in ICN 151 The Name Resolution Service (NRS) in ICN is defined as the service 152 that provides the name resolution function translating an object name 153 into some other information such as locator and another name that is 154 used for forwarding the object request. In other words, the NRS is 155 the service that shall be provided by ICN infrastructure to help a 156 consumer to reach a specific piece of content, service, or host using 157 a persistent name when the name resolution is needed. 159 The name resolution is a necessary process in ICN routing although 160 the name resolution either can be separated from the content 161 discovery as a standalone process or can be integrated with the 162 content discovery as one combined process. The former is referred as 163 standalone name resolution approach, the latter is referred as name 164 based routing approach in this document. 166 3.1. Standalone name resolution approach 168 The NRS could take the standalone name resolution approach to return 169 the client with the locators of the content, which will be used by 170 the underlying network as the identifier to route the client's 171 request to one of the producers. There are several ICN projects that 172 use the standalone name resolution approach such as DONA[Koponen], 173 PURSUIT [PURSUIT], SAIL [SAIL], MobilityFirst [MF], IDNet [Jung], 174 etc. 176 3.2. Name based routing approach 178 The NRS could take the name based routing approach, which integrates 179 the name resolution with the content request message routing as in 180 NDN [NDN]/CCN [CCN]. 182 In the case that the content request also specifies the reverse path, 183 as in NDN/CCN, the name resolution mechanism also determines the 184 routing path for the data. This adds a requirement on the name 185 resolution service to propagate request in a way that is consistent 186 with the subsequent data forwarding. Namely, the request must select 187 a path for the data based upon the finding the copy of the content, 188 but also properly delivering the data. 190 3.3. Hybrid approach 192 The NRS could also take hybrid approach which can perform name based 193 routing approach from the beginning, when it fails at certain router, 194 the router can go back to the standalone name resolution approach. 195 The alternative hybrid NRS approach also works, which can perform 196 standalone name resolution approach to find locators of routers which 197 can carry out the name based routing of the client's request. 199 A hybrid approach would combine name resolution as a subset of 200 routers on the path with some tunneling in between (say, across an 201 administrative domain) so that only a few of the nodes in the 202 architecture perform name resolution in the name-based routing 203 approach. 205 3.4. Comparisons of name resolution approaches 207 The following compares the standalone name resolution and name based 208 routing approaches from different aspects: 210 o Update message overhead : The update message overhead is due to 211 the change of content reachability, which may include content 212 caching or expiration, content producer mobility etc. The name 213 based routing approach may require to flood part of the network 214 for update propagation. In the worst case, the name based routing 215 approach may flood the whole network (but mitigating techniques 216 may be used to scope the flooding). The standalone name 217 resolution approach only requires to update propagation in part of 218 the name resolution overlay. 220 o Resolution capability : The standalone name resolution approach 221 can guarantee the resolution of any content in the network if it 222 is registered to the name resolution overlay (assuming the content 223 is being broadcast in the overlay after it is registered). On the 224 other hand, the name based routing approach can only promise a 225 high probability of content resolution, depending on the flooding 226 scope of the content availability information (i.e. content 227 publishing message and name based routing table). 229 o Node failure impact : Nodes involved in the standalone name 230 resolution approach are the name resolution overlay servers (e.g. 231 Resolution Handlers in DONA), while the nodes involved in the name 232 based routing approach are routers which route messages based on 233 locally maintained name based routing tables (e.g. NDN routers). 234 Node failures in the standalone name resolution approach may cause 235 some content resolution to fail even though the content is 236 available. This problem does not exist in the name based routing 237 approach because other alternative paths can be discovered to 238 bypass the failed ICN routers, given the assumption that the 239 network is still connected. 241 o Maintained databases : The storage usage for the standalone name 242 resolution approach is different from that of the name based 243 routing approach. The standalone name resolution approach 244 typically needs to maintain two databases: name to locator mapping 245 in the name resolution overlay and routing tables in the routers 246 on the data forwarding plane. The name based routing approach 247 needs to maintain different databases: name routing table and 248 optionally breadcrumbs for reverse routing of content back to the 249 requester. 251 4. Motivation of NRS in ICN 253 This section presents the motivation and use cases of NRS in ICN. 255 4.1. Heterogeneous names in ICN 257 In ICN design, a name is used to identify an entity, such as named 258 data content, a device, an application, a service. ICN requires 259 uniqueness and persistency of the name of any entity to ensure the 260 reachability of the entity within certain scope and with proper 261 authentication and trust guarantees. The name does not change with 262 the mobility and multi-home of the corresponding entity. A client 263 can always use this name to retrieve the content from network and 264 verify the binding of the content and the name. 266 Ideally, a name can include any form of identifier, which can be 267 flat, hierarchical, and human readable or non-readable. 269 There are heterogeneous content naming schemes [ID.Zhang] [RFC1498] 270 and name resolution approaches from different ICN architectures. For 271 example: 273 o Names in DONA [Koponen] consist of the cryptographic hash of the 274 principal's public key P and a label L uniquely identifying the 275 information with respect to the principal. Name resolution in 276 DONA is provided by specialized servers called Resolution Handlers 277 (RHs). 279 o Content in PURSUIT [PURSUIT] is identified by a combination of a 280 scope ID and a rendezvous ID. The scope ID represents the 281 boundaries of a defined dissemination strategy for the content it 282 contain. The rendezvous ID is the actual identity for a 283 particular content. Name resolution in PURSUIT is handled by a 284 collection of Rendezvous Nodes (RNs), which are implemented as a 285 hierarchical Dynamic Hash Table (DHT)[Rajahalme] [Katsaros]. 287 o Names in NDN [NDN] and CCN [CCN] are hierarchical and may be 288 similar to URLs. Each name component can be anything, including a 289 dotted human-readable string or a hash value. NDN/CCN adopts the 290 name based routing. The NDN router forwards the request by doing 291 the longest-match lookup in the Forwarding Information Base (FIB) 292 based on the content name and the request is stored in the Pending 293 Interest Table (PIT). 295 o In MobilityFirst [MF], every network entity, content has a Global 296 Unique Identifier (GUID). GUIDs are flat 160-bit strings with no 297 semantic structure. Name Resolution in MobilityFirst is carried 298 out via a Global Name Resolution Service (GNRS). 300 Although the existing naming schemes are different, they all need to 301 provide basic functions for identifying a content, supporting trust 302 provenance, content lookup and routing. The NRS may combine the 303 advantages of different mechanisms. The NRS may be able to provide a 304 generic naming schema to resolve any type of content name, either it 305 is flat or hierarchical. 307 4.2. Dynamism in ICN 309 In ICN literature, it is said that mobility can be achieved in 310 fundamental feature of ICN. Especially, consumer or client mobility 311 can be achieved by allowing information requests to basic procedure 312 from different interfaces or through attachment point of the new 313 network. Moreover, seamless mobility service in ICN ensures that 314 content reception continues without any disruption in ICN 315 application, so in consumer point of view, seamless mobility can be 316 easily supported. 318 However, producer or publisher mobility in ICN is more complicated to 319 be supported. If a publisher moves into different authority domain 320 or network location, then the request for a content published by the 321 moving publisher with origin name would be hardly forwarded to the 322 moving publisher. Especially in a hierarchical name scheme, 323 publisher mobility support is much harder than in a flat name scheme 324 since the routing tables related in broad area should be updated 325 according to the publisher movement. Therefore, various ICN 326 literatures would adopt NRS to achieve the publisher mobility, where 327 NRS can be implemented in different ways such as rendezvous 328 mechanism, mapping, etc. 330 Besides mobility, ICN has challenge to support the dynamism features 331 like multi-homing, migration, and replication of named resources such 332 as content, devices, services, etc. and NRS may help to support the 333 dynamism features. 335 4.3. Routing system in ICN 337 In ICN, data objects must be identified by names regardless their 338 location or container [RFC7927] and the names are divided into two 339 types of schemes: hierarchical and flat namespaces. A hierarchical 340 scheme used in CCN and NDN architectures has a structure similar to 341 current URIs, where the hierarchy improves scalability of routing 342 system. It is because the hierarchy enables aggregation of the name 343 resulting in reducing the size of RIB or FIB as similar to IP routing 344 system. In a flat scheme, on the other hand, name routing is not 345 easy since names in a flat namespace cannot be aggregated anymore, 346 which would cause more the scalability problem in routing system. In 347 order to address such problem, a flat name can be resolved to some 348 information which is routable through NRS. 350 In ICN, application names identifying contents are used directly for 351 packet delivery, so ICN routers run a name-based routing protocol to 352 build name-based routing and forwarding tables. Regardless of name 353 scheme, if non-aggregated name prefixes are injected to the Default 354 Route Free Zone (DFZ) of ICN, then they would be driving the growth 355 of the DFZ routing table size, which is the same as the scalability 356 issue of IP routing. Thus a solution to keep the routing table size 357 under control is needed, which can be done by defining indirection 358 layer. 360 4.4. Use cases of NRS 362 This subsection describes NRS in many other ways in ICN literature. 364 4.4.1. Flat name based routing support 366 In PURSUIT [PURSUIT], names are flat and the rendezvous functions are 367 defined for NRS, which is implemented by a set of Rendezvous Nodes 368 (RNs), the Rendezvous Network (RENE). Thus a name consisted of a 369 sequence of scope IDs and a single rendezvous ID is routed by RNs in 370 RENE. Thus, PURSUIT decouples name resolution and data routing, 371 where NRS is performed by the RENE. 373 In MobilityFirst [MF], a name called a global unique Identifier 374 (GUID) derived from a human-readable name via a global naming service 375 is flat typed 160-bits strings with self-certifying function. Thus, 376 MobilityFirst defines a global name resolution service (GNRS) which 377 resolves GUIDs to network addresses and decouples name resolution and 378 data routing as similar to PURSUIT. 380 4.4.2. Publisher mobility support 382 In NDN [Zhang2], for publisher mobility support, rendezvous 383 mechanisms have been proposed to build interests rendezvous (RV) with 384 data generated by a mobile producer (MP). There can be classified 385 two approaches such as chase mobile producer and rendezvous data. 386 Regarding MP chasing, rendezvous acts as a mapping service that 387 provides the mapping from the name of the data produced by the MP to 388 the MP's current point of attachment (PoA) name. Alternatively, the 389 RV serves as a home agent like as IP mobility support, so the RV 390 enables consumer's interest message to tunnel towards the MP at the 391 PoA. Regarding rendezvous data, moving the data produced by the MP 392 have been hosting at data depot instead of forwarding interest 393 messages. Thus a consumer's interest message can be forwarded to 394 stationary place as called data rendezvous, so it would either return 395 the data or fetch it using another mapping solution. Therefore, RV 396 or other mapping functions are in the role of NRS in NDN. 398 In [Ravindran], forwarding-label (FL) object is referred to enable 399 identifier (ID) and locator (LID) namespaces to be split in ICN. 400 Generally, IDs are managed by applications, while locators are 401 managed by a network administrator, so that IDs are mapping to 402 heterogeneous name schemes and LIDs are mapping to network domains or 403 specific network elements. Thus the proposed FL object acts as a 404 locator (LID) and provides the flexibility to forward Interest 405 messages through mapping service between IDs and LIDs. Therefore, 406 the mapping service in control plane infrastructure can be considered 407 as NRS in this draft. 409 In MobilityFirst [MF], both consumer and publisher mobility can be 410 primarily handled by the global name resolution service (GNRS) which 411 resolves GUIDs to network addresses. Thus, the GNRS must be updated 412 for mobility support when a network attached object changes its point 413 of attachment, which differs from NDN/CCN. 415 4.4.3. Scalable routing support 417 In [Afanasyev], in order to address the routing scalability problem 418 in NDN's DFZ, a well-known concept of Map-and-Encap is applied to 419 provide a simple and secure namespace mapping solution. In the 420 proposed map-and-encap design, data whose name prefixes do not exist 421 in the DFZ forwarding table can be retrieved by a distributed mapping 422 system called NDNS, which maintains and lookups the mapping 423 information from a name to its globally routed prefixes, where NDNS 424 is a kind of NRS. 426 4.4.4. Nameless object support 428 In CCNx 1.0 [Mosko2], the concept of "Nameless Objects" that are a 429 Content Object without a Name is introduced to provide a means to 430 move Content between storage replicas without having to rename or re- 431 sign the content objects for the new name. Nameless Objects can be 432 addressed by the ContentObjectHash that is to restrict Content Object 433 matching by using SHA-256 hash. 435 An Interest message would still carry a Name and a ContentObjectHash, 436 where a Name is used for routing, while a ContentObjectHash is used 437 for matching. However, on the reverse path, if the Content Object's 438 name is missing, it is a "Nameless Object" and only matches against 439 the ContentObjectHash. Therefore, a consumer needs to resolve proper 440 name and hashes through an outside system, which can be considered as 441 NRS. 443 5. Requirements for NRS in ICN 445 This section presents the requirements for designing NRS in ICN in 446 terms of service, system and security aspects, respectively. 448 5.1. Requirements as a service 450 This subsection presents the requirements for NRS as a service. 452 5.1.1. Delay sensitivity 454 The name resolution process provided by the NRS must be completed 455 within a minimum delay. If the name resolution takes too long, then 456 the content request packet may get dropped or it will yield the high 457 content retrieval time for content requestor. Thus, the content 458 retrieval time has to be content requestor-tolerant. 460 5.1.2. Accuracy 462 The NRS must provide accurate and up-to-date information on how to 463 discover the requested content with minimum overhead in propagating 464 the update information. For example, a content can be moved from one 465 domain to another domain due to the mobility of the producer, then 466 the old name record should be deleted from the NRS system and a new 467 name record should be added and updated with minimum delay. 469 5.1.3. Resolution guarantee 471 The NRS must ensure the name resolution success if the matching 472 content exists in the network, regardless of its popularity, number 473 of cached copies. 475 5.2. Requirements as a system 477 This subsection presents the requirements for NRS as a system. 479 5.2.1. Scalability 481 The NRS system must be extremely scalable to support a large number 482 of content objects as well as billions of users, who may access the 483 system through various connection methods and devices. Especially in 484 IoT applications, the data size is small but frequently generated by 485 sensors. Message forwarding and processing, routing table building- 486 up and name records propagation must be efficient and scalable. 488 5.2.2. Manageability 490 The NRS system must be manageable since some parts of the system may 491 grow or shrink dynamically and a NRS system node may be added or 492 deleted. 494 5.2.3. Deployability 496 The NRS system must be deployable since deployability is important 497 for a real world system. If the NRS system can be deployed from the 498 edges, then the deployment can be simplified. 500 5.2.4. Fault tolerance 502 The NRS system must ensure resilience to node failures. After a NRS 503 node fails, the NRS system must be able to restore the name records 504 stored in the NRS node. 506 5.3. Requirements on Security aspect 508 This subsection presents the requirements for NRS on security aspect 509 for both node and data in the NRS system. 511 5.3.1. Accessibility 513 The name records must have proper access rights such that the 514 information contained in the name record would not be revealed to 515 unauthorized users. In other words, The NRS system must be prevented 516 from the malicious users attempting to hijack or corrupt name 517 records. 519 5.3.2. Authentication 521 Users/nodes that register themselves in the NRS system must require 522 the authentication to ensure who claims to be. For example, the 523 attacker can act as a fake NRS server which causes disruption or 524 intercepts the data. 526 5.3.3. Data confidentiality 528 NRS must keep the data confidentiality to prevent a lot of sensitive 529 data from reaching unauthorized data requestor such as in IoT 530 environment. 532 5.3.4. Dat privacy 534 When a private data is registered in the system, the NRS system must 535 support the privacy to avoid the information leaking. Otherwise, 536 unauthorized entity may disclose the privacy. 538 6. IANA Considerations 540 There are no IANA considerations related to this document. 542 7. Security Considerations 544 [TBD] 546 8. Acknowledgements 548 [TBD] 550 9. References 552 9.1. Normative References 554 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 555 Requirement Levels", BCP 14, RFC 2119, 556 DOI 10.17487/RFC2119, March 1997, 557 . 559 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 560 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 561 "Information-Centric Networking (ICN) Research 562 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 563 . 565 9.2. Informative References 567 [Ahlgren] Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D., 568 and B. Ohlman, "A Survey of Information-Centric 569 Networking", IEEE Communications Magarzine Vol.50, Issue 570 7, 2012. 572 [Xylomenos] 573 Xylomenos, G., Ververidis, C., Siris, V., Fotiou, N., 574 Tsilopoulos, C., Vasilako, X., Katsaros, K., and G. 575 Polyzos, "A Survey of Information-Centric Networking 576 Research,Communications Surveys and Tutorials", IEEE 577 Communications Surveys and Tutorials vol. 16, no. 2, 2014. 579 [Baccelli] 580 Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M. 581 Wahlisch, "Information Centric Networking in the IoT: 582 Experiments with NDN in the Wild", ACM ICN 2014, 2014. 584 [Amadeo] Amadeo, M., Campolo, C., Iera, A., and A. Molinaro, "Named 585 data networking for IoT: An architectural perspective", 586 European Conference on Networks and Communications 587 (EuCNC) , 2014. 589 [Quevedo] Quevedo, J., Corujo, D., and R. Aguiar, "A case for ICN 590 usage in IoT environments", IEEE GLOBECOM , 2014. 592 [Amadeo2] Amadeo, M. et al., "Information-centric networking for the 593 internet of things: challenges and opportunitiesve", IEEE 594 Network vol. 30, no. 2, July 2016. 596 [ID.Zhang2] 597 Zhang, Y., "Design Considerations for Applying ICN to 598 IoT", draft-zhang-icnrg-icniot-01 , June 2017. 600 [Koponen] Koponen, T., Chawla, M., Chun, B., Ermolinskiy, A., Kim, 601 K., Shenker, S., and I. Stoica, "A Data-Oriented (and 602 Beyond) Network Architecture", ACM SIGCOMM 2007 pp. 603 181-192, 2007. 605 [PURSUIT] "FP7 PURSUIT project.", 606 http://www.fp7-pursuit.eu/PursuitWeb/ . 608 [SAIL] "FP7 SAIL project.", http://www.sail-project.eu/ . 610 [NDN] "NSF Named Data Networking project.", 611 http://www.named-data.net . 613 [CCN] "Content Centric Networking project.", 614 https://wiki.fd.io/view/Cicn . 616 [MF] "NSF Mobility First project.", 617 http://mobilityfirst.winlab.rutgers.edu/ . 619 [Jung] Jung, H. et al., "IDNet: Beyond All-IP Network", ETRI 620 Jouranl vol. 37, no. 5, October 2015. 622 [Jacobson] 623 Jacobson, V., Smetters, D., Thornton, J., Plass, M., 624 Briggs, N., and R. Braynard, "Networking Named Content", 625 ACM CoNEXT , 2009. 627 [Baid] Baid, A., Vu, T., and D. Raychaudhuri, "Comparing 628 Alternative Approaches for Networking of Named Objects in 629 the Future Internet", IEEE Workshop on Emerging Design 630 Choices in Name-Oriented Networking (NOMEN) , 2012. 632 [Bari] Bari, M., Chowdhury, S., Ahmed, R., Boutaba, R., and B. 633 Mathieu, "A Survey of Naming and Routing in Information- 634 Centric Networks", IEEE Communications Magazine Vol. 50, 635 No. 12, P.44-53, 2012. 637 [Rajahalme] 638 Rajahalme, J., Sarela, M., Visala, K., and J. Riihijarvi, 639 "On Name-based Inter-domain Routing", Computer 640 Networks Vol. 55, No. 4, P. 975-986, March 2011. 642 [Katsaros] 643 Katsaros, K., Fotiou, N., Vasilakos, X., Ververidis, C., 644 Tsilopoulos, C., Xylomenos, G., and G. Polyzos, "On Inter- 645 Domain Name Resolution for Information-Centric Networks", 646 Proc.IFIP-TC6 Networking Conference , 2012. 648 [ID.Wang] Wang, J., Li, S., and C. Wetphal, "Namespace Resolution in 649 Future Internet Architectures", draft-wang-fia- 650 namespace-01 , October 2015. 652 [ID.Zhang] 653 Zhang, X., Ravindran, R., Xie, H., and G. Wang, "PID: A 654 Generic Naming Schema for Information-centric Network", 655 draft-zhang-icnrg-pid-naming-scheme-03 , August 2013. 657 [D.Zhang] Zhang, D. and H. Liu, "Routing and Name Resolution in 658 Information-Centric Networks", 22nd International 659 Conference on Computer Communications and Networks 660 (ICCCN) , 2013. 662 [Sevilla] Sevilla, S., Mahadevan, P., and J. Garcia-Luna-Aceves, 663 "iDNS: Enabling Information Centric Networking Through The 664 DNS", Name Oriented Mobility (workshop co-located with 665 Infocom 2014) , 2014. 667 [RFC1498] Saltzer, J., "On the Naming and Binding of Network 668 Destinations", RFC 1498, DOI 10.17487/RFC1498, August 669 1993, . 671 [oneM2M] "oneM2M Functional Architecture TS 0001.", 672 http://www.onem2m.org/technical/published-documents. . 674 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 675 Application Protocol (CoAP)", RFC 7252, 676 DOI 10.17487/RFC7252, June 2014, 677 . 679 [ID.Shelby] 680 Shelby, Z., "CoRE Resource Directory", draft-ietf-core- 681 resource-directory-10 , March 2017. 683 [CoRE] "Constrained RESTful Environments, CoRE", 684 https://datatracker.ietf.org/wg/core/charter/ , March 685 2013. 687 [Westphal] 688 Westphal, C. and E. Demirors, "An IP-based Manifest 689 Architecture for ICN", ACM ICN , 2015. 691 [Mosko] Mosko, M., Scott, G., Solis, I., and C. Wood, "CCNx 692 Manifest Specification", draft-wood-icnrg- 693 ccnxmanifests-00 , July 2015. 695 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 696 Locator/ID Separation Protocol (LISP)", RFC 6830, 697 DOI 10.17487/RFC6830, January 2013, 698 . 700 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 701 Protocol (LISP) Map-Server Interface", RFC 6833, 702 DOI 10.17487/RFC6833, January 2013, 703 . 705 [Zhang] Zhang, L. et al., "Named data networking", ACM SIGCOMM 706 Computer Communication Review vol. 44, no. 3, July 2014. 708 [Zhang2] Zhang, Y., "A Survey of Mobility Support in Named Data 709 Networking", NAMED-ORIENTED MOBILITY: ARCHITECTURES, 710 ALGORITHMS, AND APPLICATIONS(NOM) , 2016. 712 [Dannewitz] 713 Dannewitz, C. et al., "Network of Information (NetInf)-An 714 information centric networking architecture", Computer 715 Communications vol. 36, no. 7, April 2013. 717 [Seskar] Seskar, I., Nagaraja, K., Nelson, S., and D. Raychaudhuri, 718 "MobilityFirst Future Internet Architecture Project", 7th 719 Asian Internet Engineering Conference , November 2011. 721 [Dannewitz2] 722 Dannewitz, C., DAmbrosio, M., and V. Vercellone, 723 "Hierarchical DHT-based name resolution for Information- 724 Centric Networks", Computer Communications vol. 36, no. 7, 725 April 2013. 727 [Vu] Vu, T. et al., "DMap: A Shared Hosting Scheme for Dynamic 728 Identifier to Locator Mapping in the Global Internet", 729 IEEE 32nd International Conference on Distributed 730 Computing Systems , 2012. 732 [Hong] Hong, J., Chun, W., and H. Jung, "Demonstrating a Scalable 733 Name Resolution System for Information-Centric 734 Networking", ACM ICN , September 2015. 736 [Ravindran] 737 Ravindran, R. et al., "Forwarding-Label support in CCN 738 Protocol", draft-ravi-icnrg-ccn-forwarding-label-01 , July 739 2017. 741 [Afanasyev] 742 Afanasyev, A. et al., "SNAMP: Secure Namespace Mapping to 743 Scale NDN Forwarding", IEEE Global Internet Symposium , 744 April 2015. 746 [Mosko2] Mosko, M., "Nameless Objects", , July 2015. 748 Authors' Addresses 749 Jungha Hong 750 ETRI 751 218 Gajeong-ro, Yuseung-Gu 752 Daejeon 34129 753 Korea 755 Phone: +82 42 860 0926 756 Email: jhong@etri.re.kr 758 Lijun Dong 759 Huawei 760 10180 Telesis Court 761 San Diego, CA 92121 762 USA 764 Email: lijun.dong@huawei.com 766 Tae-Wan You 767 ETRI 768 218 Gajeong-ro, Yuseung-Gu 769 Daejeon 34129 770 Korea 772 Phone: +82 42 860 0642 773 Email: twyou@etri.re.kr 775 Cedric Westphal 776 Huawei 777 2330 Central Expressway 778 Santa Clara, CA 95050 779 USA 781 Email: cedric.westphal@huawei.com 783 Yong-Geun Hong 784 ETRI 785 218 Gajeong-ro, Yuseung-Gu 786 Daejeon 34129 787 Korea 789 Phone: +82 42 860 6557 790 Email: yghong@etri.re.kr 791 GQ Wang 792 Huawei 793 2330 Central Expressway 794 Santa Clara, CA 95050 795 USA 797 Email: gq.wang@huawei.com 799 Jianping Wang 800 City University Hong Kong 802 Email: jianwang@cityu.edu.hk