idnits 2.17.1 draft-irtf-icnrg-nrsarch-considerations-04.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 09, 2020) is 1480 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 400, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-ravi-icnrg-ccn-forwarding-label-01 == Outdated reference: A later version (-06) exists of draft-irtf-icnrg-nrs-requirements-03 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group J. Hong 3 Internet-Draft T. You 4 Intended status: Informational ETRI 5 Expires: September 10, 2020 V. Kafle 6 NICT 7 March 09, 2020 9 Architectural Considerations of ICN using Name Resolution Service 10 draft-irtf-icnrg-nrsarch-considerations-04 12 Abstract 14 This document discusses architectural considerations and implications 15 of Information-Centric Networking (ICN) related to the usage of the 16 Name Resolution Service (NRS). It describes how ICN architectures 17 may change and what implications are introduced within the ICN 18 routing system when NRS is integrated into an ICN architecture. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 10, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Implications of NRS in ICN . . . . . . . . . . . . . . . . . 5 58 5. ICN Architectural Considerations for NRS . . . . . . . . . . 5 59 5.1. Name mapping records registration, resolution, and update 5 60 5.2. Protocols and Semantics . . . . . . . . . . . . . . . . . 7 61 5.3. Routing System . . . . . . . . . . . . . . . . . . . . . 8 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 66 8.2. Informative References . . . . . . . . . . . . . . . . . 9 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 Information-Centric Networking (ICN) is an approach to evolve the 72 Internet infrastructure to directly access Named Data Objects (NDOs) 73 by its name, i.e., the name of NDO is directly used to route the 74 request to the data object. Such name-based routing in ICN has 75 inherent challenges in supporting globally scalable routing system, 76 producer mobility, and off-path caching. In order to address these 77 challenges, the Name Resolution Service (NRS) has been integrated 78 into several ICN project's proposals and literature [Afanasyev] 79 [Zhang2] [Ravindran] [SAIL] [MF] [Bayhan]. 81 This document describes how ICN architectures may change and what 82 implications are introduced within the ICN routing system when NRS is 83 integrated into an ICN architecture. It also discusses ICN 84 architectural considerations for an NRS. In other words, the scope 85 of this document includes considerations in the view of the ICN 86 architecture and routing system when NRS is integrated into ICN. The 87 discussion of NRS itself is provided in the NRS design guidelines 88 [NRSguidelines] document. 90 2. Terminology 92 o Name Resolution Service (NRS): NRS in ICN is defined as the 93 service that provides the name resolution function for translating 94 an object name into some other information such as a locator, a 95 off-path-cache pointer, or an alias name for forwarding the object 96 request [NRSguidelines]. The NRS is a service maintained by a 97 distributed mapping database system. 99 o NRS server: The NRS consists of the distributed NRS servers 100 storing the mapping records in database. NRS servers store and 101 maintain the mapping records that keep the mappings of name to 102 some other information that is used for forwarding content 103 request. 105 o NRS resolver: The client side of the NRS is called an NRS 106 resolver. The resolver is responsible for initiating the name 107 resolution request queries that ultimately lead to a name 108 resolution of the target data objects. NRS resolvers can be 109 located in the consumer (or client) nodes and ICN routers. NRS 110 resolver may also cache the mapping records obtained through the 111 name resolution for later usage. 113 o Name registration: In order to create the NRS, the content names 114 and their mapping records must be registered in the NRS system by 115 a publisher who has an access to at least one authoritative NRS 116 server or by a producer who generates named data objects. The 117 mapping information is the mapping of a name to some information 118 such as another names and locators, which are used for forwarding 119 the content request. Thus, a publisher or producer creates an NRS 120 registration request and send to an NRS server. On registration, 121 the NRS server stores the mapping record in the database and sends 122 an ACK back to the producer or publisher. 124 o Name resolution: Name resolution is the main process of the NRS. 125 It is performed by an NRS resolver which can be deployed on a 126 consumer node or an ICN router. When the required valid name 127 mapping record (whose lifetime has not expired yet) has not been 128 stored in the cache of an NRS resolver, it sends a name resolution 129 request toward the NRS server. The NRS server searches the 130 content name in its mapping record database, retrieves and sends 131 the mapping record in the name resolution response message to the 132 NRS resolver. 134 o NRS node: In ICN architecture, NRS servers are also referred to as 135 NRS nodes that maintain the name records. 137 o NRS client: A node that uses the NRS is called NRS client. The 138 nodes that initiate the name registration, resolution, or update 139 procedure are NRS clients. That is, NRS resolver, ICN client 140 nodes, ICN routers, or producers are NRS clients. 142 3. Background 144 The name-based routing in ICN has inherent challenges in supporting a 145 globally scalable routing system, producer mobility, and off-path 146 caching. In order to address these challenges, an NRS has been 147 integrated into several ICN project's proposals and literature as 148 follows: 150 o Routing scalability : In ICN, application names identifying 151 contents are used directly for packet delivery, so ICN routers run 152 a name-based routing protocol to build name-based routing and 153 forwarding tables. Similar to the scalability challenge of IP 154 routing, if non-aggregatable name prefixes are injected into the 155 Default Route Free Zone (DFZ) of ICN, they would be driving the 156 growth of the DFZ routing table size. Thus, integrating an NRS 157 with ICN can be an approach to keep the routing table size under 158 control, where the NRS resolves name prefixes which do not exist 159 in the DFZ forwarding table into globally routable prefixes such 160 as one proposed in NDN [Afanasyev]. Another approach dealing with 161 routing scalability is the Multi-level Distributed Hash 162 Table (MDHT) used in NetInf [Dannewitz]. It provides name-based 163 anycast routing that can support a non-hierarchical namespace and 164 can be adopted on a global scale [Dannewitz2]. 166 o Producer mobility : In ICN, if a producer moves into a different 167 name domain that uses a different name prefix, the request for a 168 content produced by the moving producer with the origin name would 169 be hardly forwarded to the moving producer's new location. 170 Especially, in a hierarchical name scheme, producer mobility 171 support is much harder than in a flat name scheme since the 172 routing tables in broader area need to be updated according to the 173 producer movement. Therefore, various ICN architectures such as 174 NetInf [Dannewitz] and MobilityFirst [MF] have adopted NRS to 175 tackle the issues of producer's location change. 177 o Off-path caching : In-network caching is an inherent feature of an 178 ICN architecture. Caching approaches can be categorized into on- 179 path caching and off-path caching, according to the location of 180 caches in relation to the forwarding path from the original 181 content store to a consumer. Off-path caching, also referred as 182 content replication or content storing, aims at replicating 183 content in various locations within a network in order to increase 184 the availability of contents, where the caching locations may not 185 be lying along the content forwarding path. Thus, finding off- 186 path cached contents is not trivial in name-based routing of ICN. 187 In order to support off-path caches, the locations of replicas are 188 usually advertised into a name-based routing system or into NRS as 189 described in [Bayhan]. 191 This document discusses architectural considerations and implications 192 of ICN when the NRS is integrated into ICN to solve such challenges 193 of the name-based routing in ICN. 195 4. Implications of NRS in ICN 197 The majority of ICN projects use the name-based routing which omits 198 the name resolution. So, NRS would not be mandatory part in an ICN 199 architecture. The integration of NRS would change the ICN 200 architecture at least with respect to procedures, latency, and 201 security, as discussed below: 203 o Procedure : When the NRS is adopted into an ICN architecture, the 204 procedure of the name resolution has to be integrated into ICN 205 overall procedures. For NRS integration, there are certain things 206 that have to be decided such as where and how the name resolution 207 task is performed. 209 o Latency : When the NRS is adopted into an ICN architecture, the 210 additional latency of the name resolution obviously occurs in the 211 routing and forwarding system. Although the latency of the name 212 resolution is added, the total latency could be minimized if the 213 nearest copies or off-path caches can be located by the NRS lookup 214 procedure. Additionally, there might be a trade-off between the 215 name resolution latency and inter-domain traffic reduction. 216 Finding a nearest cache holding the content would reduce the 217 content discovery as well as delivery latency. 219 o Security : When the NRS is adopted into an ICN architecture, 220 security threats may increase. Protection of the NRS system 221 against attacks such as Distributed Denial of Service (DDoS) and 222 authentication of name mapping records and related signaling 223 messages would be challenging. 225 5. ICN Architectural Considerations for NRS 227 This section discusses the various items that have to be considered 228 from the point of view of ICN architecture when ICN integrates the 229 NRS system in its architecture. These items are related with the 230 name mapping records registration, resolution, and update, protocols 231 and messages, and integration with the routing system. 233 5.1. Name mapping records registration, resolution, and update 235 When the NRS is integrated in an ICN architecture, the functions 236 related with the registration, resolution and update of name mapping 237 records have to be considered. The NRS nodes maintain the name 238 mapping records and may exist in an overlay network over the ICN 239 routers, that is, they communicate to each other through ICN routers. 240 Figure 1 shows the NRS nodes and NRS clients connected through an 241 underlying network. The NRS nodes exist in a distributed manner so 242 that an NRS node is always available closer to an NRS client and 243 communication latency for the name registration and resolution 244 performed by the NRS client remains very low. The name registration, 245 name resolution and name record update procedures are briefly 246 discussed below. 248 +------------+ +------------+ 249 | NRS Node | | NRS Node | 250 +------------+ +------------+ 251 | | 252 | | 253 +------------+ | | +------------+ 254 | NRS Client |--------------------------------------| NRS Client | 255 +------------+ underlying network +------------+ 257 Figure 1: NRS nodes and NRS clients connected through an underlying 258 network 260 o Name registration: Name registration is performed by the producer 261 (as an NRS client) when it creates a new content. When a producer 262 creates a content and assigns a name from its name prefix space to 263 the content, the producer performs the name registration in an NRS 264 node. Name registration may be performed by an ICN router when it 265 does off-path caching or cooperative caching since involving an 266 NRS may be a good idea for off-path caching. The ICN routers with 267 forwarder caches do not require to invoke NRS registration 268 procedure because they lie on the path to the content store or 269 producer. They will be hit when a future request is forwarded to 270 the content producer by an ICN router lying toward the ICN client 271 node. However, the ICN routers performing off-path caching of the 272 content require to invoke the name registration procedure so that 273 other ICN routers can know about the off-path cache locations 274 through the name resolution. As a content gets cached in many 275 off-path ICN routers, all of them may register the same content 276 names in the same NRS node multiple times. In this case, the NRS 277 node adds the new location of the content to the name record 278 together with the previous locations. In this way, each of the 279 name records stored in the NRS node may contain multiple locations 280 of the content. 282 o Name resolution: Name resolution is performed by NRS client to 283 obtain the name record from an NRS node by sending a name 284 resolution request message and getting the response containing the 285 record. Regarding the name-based ICN routing context, the name 286 resolution will be mostly performed by an ICN router that does not 287 contain the name in its FIB table. The name resolution may also 288 be performed by the consumer (in case the consumer is multihomed) 289 to make decision to forward the content request in a better 290 direction so that it obtains the content from the nearest cache. 291 If the consumer is single homed, it may not perform the name 292 resolution. It creates the content request packet containing the 293 content name and forwards to the nearest ICN router. The ICN 294 router checks its FIB table to see where to forward the content 295 request. If the ICN router fails to know the requested content 296 reachable, it performs name resolution to obtain the name mapping 297 record and adds to FIB table. The ICN router may also perform 298 name resolution even before the arrival of the content request 299 time to use the name mapping record to configure the FIB table. 301 o Name record update: Name record update is carried out when a 302 content name mapping record changes, e.g. the content is not 303 available in one or more of previous locations. The name record 304 update may take place explicitly by the exchange of name record 305 update message or implicitly when a timeout occurs and a name 306 record is deemed to be invalid. The explicit update is possible 307 when each record is accompanied by its lifetime value. 309 5.2. Protocols and Semantics 311 In order to develop an NRS system within a local ICN network domain 312 or global ICN network domain, new protocols and semantics should be 313 designed to manage and resolve names among different name spaces. 315 One way of implementing an NRS is by extending the basic ICN TLV 316 format and semantics [RFC8609] [RFC8569]. For instance, name 317 resolution and response messages can be implemented by defining new 318 type fields in the Interest and Content Object messages [CCNxNRS]. 319 By leveraging the existing ICN Interest and Content Object packets 320 for name resolution and registration, the NRS system can be deployed 321 with a minimum implication of ICN architecture changes. However, 322 because of confining to the basic ICN protocol and semantics, the NRS 323 system may not be able to support more flexible and scalable designs. 325 On the other hand, an NRS system can be designed newly with its own 326 protocol and semantics like an independent NRS system described in 327 [Hong]. For instance, the NRS protocol and messages can be 328 implemented by using a RESTful API and the NRS can be operated as an 329 application protocol independently from a basic ICN architecture. 331 5.3. Routing System 333 The NRS helps in reducing the routing complexity of ICN architecture 334 than the pure name-based routing by helping the routing system to 335 update the routing table on demand through the help of name records 336 obtained from the NRS. The routing system has to be considered to 337 make name resolution requests and process the information such as a 338 locator, a off-path-cache pointer, or an alias name, obtained from 339 the name resolution. 341 No matter what kind of infomation is obtained from the name 342 resolution, as long as it is in the form of a name, the content 343 request message in the routing system may be reformatted with the 344 obtained information. In this case, the content name requested 345 originally by a consumer needs to be involved in the reformatted 346 content request to check the integrity of the requested content. In 347 other words, the infomation obtained from the name resolution is used 348 to forward the content request and the original content name 349 requested by a consumer is used to identify the content. Otherwise, 350 the resolve information is used to build the routing table. 352 The infomation obtained from the name resolution may not be in the 353 form of a name. For example, it may identify the tunnel endpoints by 354 IP address and is used to construct a tunnel to forward the content 355 request. 357 6. IANA Considerations 359 There are no IANA considerations related to this document. 361 7. Security Considerations 363 When NRS is integrated into an ICN architecture, security threats may 364 increase in various aspects as discussed below: 366 o Name Space Management: In order to deploy an NRS in ICN 367 architecture, ICN name spaces, which may be assigned by 368 authoritative entities, should be securely mapped to the content 369 publishers and securely managed by them. According to the ICN 370 research challenges [RFC7927], a new name space can also provide 371 an integrity verification function to authenticate its publisher. 372 The verification for mapping among different name spaces should be 373 securely required. 375 o NRS System: NRS enables the deployment of new entities (e.g. NRS 376 servers) to build distributed and scalable NRS systems. Thus, the 377 entities, e.g., NRS server maintaining a mapping database, could 378 be a single point of failure receiving malicious requests from 379 innumerable adversaries like Denial of Service or Distributed 380 Denial of service attacks. In addition, the NRS clients should 381 also trust on the NRS nodes in other network domains and 382 communication between them should be protected securely to prevent 383 the malicious entities from participating in this communication. 385 o NRS Protocols and Messages: In an NRS system, additional messages 386 related to the name registration, name resolution, and name record 387 update can spill over to unauthorized networks, increaing the 388 number of more security threats. An adversary can also manipulate 389 these messages by hijacking them to create false messages. A lot 390 of problems similar to the security issues of an IP network can 391 affect the overall ICN architecture. Therefore, security 392 mechanisms such as accessibility, authentication, etc., 393 [NRSguidelines] for the NRS system should be considered to protect 394 not only the NRS system, but also the ICN architecture. 396 8. References 398 8.1. Normative References 400 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 401 Requirement Levels", BCP 14, RFC 2119, 402 DOI 10.17487/RFC2119, March 1997, 403 . 405 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 406 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 407 "Information-Centric Networking (ICN) Research 408 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 409 . 411 8.2. Informative References 413 [Afanasyev] 414 Afanasyev, A. et al., "SNAMP: Secure Namespace Mapping to 415 Scale NDN Forwarding", IEEE Global Internet Symposium , 416 April 2015. 418 [Zhang2] Zhang, Y., "A Survey of Mobility Support in Named Data 419 Networking", NAMED-ORIENTED MOBILITY: ARCHITECTURES, 420 ALGORITHMS, AND APPLICATIONS(NOM) , 2016. 422 [Ravindran] 423 Ravindran, R. et al., "Forwarding-Label support in CCN 424 Protocol", draft-ravi-icnrg-ccn-forwarding-label-01 , July 425 2017. 427 [SAIL] "FP7 SAIL project.", http://www.sail-project.eu/ . 429 [MF] "NSF Mobility First project.", 430 http://mobilityfirst.winlab.rutgers.edu/ . 432 [Bayhan] Bayhan, S. et al., "On Content Indexing for Off-Path 433 Caching in Information-Centric Networks", ACM ICN , 434 September 2016. 436 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric 437 Networking (CCNx) Semantics", 438 https://www.rfc-editor.org/info/rfc8569 , July 2019. 440 [RFC8609] Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 441 Format", https://www.rfc-editor.org/info/rfc8609 , July 442 2019. 444 [CCNxNRS] Hong, J. et al., "CCNx Extension for Name Resolution 445 Service", draft-hong-icnrg-ccnx-nrs-02 , July 2018. 447 [Hong] Hong, J., Chun, W., and H. Jung, "Demonstrating a Scalable 448 Name Resolution System for Information-Centric 449 Networking", ACM ICN , September 2015. 451 [NRSguidelines] 452 Hong, J. et al., "Design Guidelines for Name Resolution 453 Service in ICN", draft-irtf-icnrg-nrs-requirements-03 , 454 November 2019. 456 [Dannewitz] 457 Dannewitz, C. et al., "Network of Information (NetInf)-An 458 information centric networking architecture", Computer 459 Communications vol. 36, no. 7, April 2013. 461 [Dannewitz2] 462 Dannewitz, C., DAmbrosio, M., and V. Vercellone, 463 "Hierarchical DHT-based name resolution for Information- 464 Centric Networks", Computer Communications vol. 36, no. 7, 465 April 2013. 467 Authors' Addresses 468 Jungha Hong 469 ETRI 470 218 Gajeong-ro, Yuseung-Gu 471 Daejeon 34129 472 Korea 474 Email: jhong@etri.re.kr 476 Tae-Wan You 477 ETRI 478 218 Gajeong-ro, Yuseung-Gu 479 Daejeon 34129 480 Korea 482 Email: twyou@etri.re.kr 484 Ved Kafle 485 NICT 486 4-2-1 Nukui-Kitamachi 487 Koganei, Tokyo 184-8795 488 Japan 490 Email: kafle@nict.go.jp