idnits 2.17.1 draft-irtf-icnrg-nrsarch-considerations-03.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 (November 04, 2019) is 1633 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 351, 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 Y-G. Hong 5 Expires: May 7, 2020 ETRI 6 V. Kafle 7 NICT 8 November 04, 2019 10 Architectural Considerations of ICN using Name Resolution Service 11 draft-irtf-icnrg-nrsarch-considerations-03 13 Abstract 15 This document discusses architectural considerations and implications 16 of Information-Centric Networking (ICN) related to the usage of the 17 Name Resolution Service (NRS). It describes how ICN architectures 18 may change and what implications are introduced within the ICN 19 routing system when NRS is integrated into ICN. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 7, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Implications of NRS in ICN . . . . . . . . . . . . . . . . . 4 59 5. ICN Architectural Considerations for NRS . . . . . . . . . . 5 60 5.1. Name mapping records registration, resolution, and update 5 61 5.2. Protocols and Semantics . . . . . . . . . . . . . . . . . 6 62 5.3. Routing System . . . . . . . . . . . . . . . . . . . . . 7 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 67 8.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 Information-Centric Networking (ICN) is an approach to evolve the 73 Internet infrastructure to directly access Named Data Objects (NDOs) 74 by its name, i.e., the name of NDO is directly used to route the 75 request to the data object. Such name-based routing in ICN has 76 inherent challenges in supporting globally scalable routing system, 77 producer mobility, off-path caching, etc. In order to address these 78 challenges, the Name Resolution Service (NRS) has been integrated 79 into several ICN projects and literature [Afanasyev] [Zhang2] 80 [Ravindran] [SAIL] [MF] [Bayhan]. 82 This document describes how ICN architectures may change and what 83 implications are introduced within the ICN routing system when NRS is 84 integrated into ICN. It also discusses ICN architectural 85 considerations for an NRS. In other words, the scope of this 86 document includes considerations in the veiw of the ICN architecture 87 and routing system when NRS is integrated into ICN. The NRS itself 88 discussion is provided in the NRS design guidelines [NRSguidelines] 89 document. 91 2. Terminology 93 o Name Resolution Service (NRS): NRS in ICN is defined as the 94 service that provides the name resolution function for translating 95 an object name into some other information such as a locator, 96 another name, etc. for forwarding the object request 97 [NRSguidelines]. 99 o NRS server: The NRS is a service maintained by a distributed 100 mapping database system. The NRS consists of the distributed NRS 101 servers storing the mapping records in database. NRS servers 102 store and maintain the mapping records that keep the mappings of 103 name to some other information that is used for forwarding content 104 request. 106 o NRS resolver: The client side of the NRS is called an NRS 107 resolver. The resolver is responsible for initiating the name 108 resolution request queries that ultimately lead to a name 109 resolution of the data objects. NRS resolvers can be located in 110 the consumer (or client) nodes and ICN routers. NRS resolver may 111 also cache the mapping records obtained through the name for later 112 usage. 114 o Name registration: In order to create the NRS, the content names 115 and their mapping records must be registered in NRS system by a 116 publisher who has at least one authoritative NRS server or by a 117 producer who generates named data objects. The mapping 118 information is the mapping of a name to some information such as 119 another names and locators, which are used for forwarding the 120 content request. Thus, a publisher or producer creates an NRS 121 registration request and send to an NRS server. On registration, 122 the NRS server stores the mapping record in the database and sends 123 an ACK as a response back to the producer or publisher. 125 o Name resolution: Name resolution is the main process of the NRS. 126 It is performed by an NRS resolver which can be deployed on a 127 consumer node or an ICN router. When the required name mapping 128 record has not been stored in the cache of a NRS resolver, it 129 sends a name resolution request toward the NRS server. The NRS 130 server searches the content name in its mapping record database, 131 retrieves and sends the mapping record in the name resolution 132 response message to the NRS resolver. 134 3. Background 136 The name-based routing in ICN has inherent challenges in supporting 137 globally scalable routing system, producer mobility, off-path 138 caching, etc. In order to address these challenges, an NRS has been 139 integrated into several ICN projects and literature as follows: 141 o Routing scalability : In ICN, application names identifying 142 contents are used directly for packet delivery, so ICN routers run 143 a name-based routing protocol to build namebased routing and 144 forwarding tables. Similar to the scalability challenge of IP 145 routing, if non-aggregatable name prefixes are injected to the 146 Default Route Free Zone (DFZ) of ICN, they would be driving the 147 growth of the DFZ routing table size. Thus, integrating an NRS 148 with ICN can be a feasible solution to keep the routing table size 149 under control, where the NRS resolves name prefixes which do not 150 exist in the DFZ forwarding table into globally routable prefixes 151 such as one proposed in NDN [Afanasyev]. Another approach deal 152 with routing scalability is the Multi-level Distributed Hash 153 Table (MDHT) used in NetInf [Dannewitz]. It provides name-based 154 anycast routing that can support a non-hierarchical namespace can 155 be adopted on a global scale [Dannewitz2]. 157 o Producer mobility : In ICN, if a producer moves into a different 158 name domain, which is assigned by another authoritative of 159 publish, or a different network location, the request for a 160 content produced by the moving producer with the origin name would 161 be hardly forwarded to the moving producer's new location. 162 Especially, in a hierarchical name scheme, producer mobility 163 support is much harder than in a flat name scheme since the 164 routing tables in broader area need to be updated according to the 165 producer movement. Therefore, various ICN architectures such as 166 NetInf [Dannewitz] and MobilityFirst [MF] have adopted NRS to 167 tackle the producer's location. 169 o Off-path caching : In-network caching is a feature of an ICN 170 architecture. Caching approaches can be categorized into on-path 171 caching and off-path caching according to the location of caches 172 in relation to the forwarding path from the original server to a 173 consumer. Off-path caching, also referred as content replication 174 or content storing, aims at replicating content in various 175 locations within a network in order to increase availability, 176 where the caching locations may not be lying along the content 177 forwarding path. Thus, finding off-path cached objects is not 178 trivial in name-based routing of ICN. In order to support off- 179 path caches, the locations of replicas are usually advertised into 180 a name-based routing system or into NRS such as in [Bayhan]. 182 This document discusses architectural considerations and implications 183 of ICN when NRS is integrated into ICN to solve such challenges due 184 to the name-based routing in ICN. 186 4. Implications of NRS in ICN 188 The majority of ICN projects use the name-based routing which omits 189 the name resolution. So, NRS would not be mandatory in an ICN 190 architecture. The integration of NRS would change the ICN 191 architecture at least with respect to procedures, latency, and 192 security, as follows: 194 o Procedure : When NRS is adopted into an ICN architecture, the 195 procedure of the name resolution has to be integrated into ICN 196 overall procedures. For NRS integration, there are certain things 197 that have to be decided such as where and how the name resolution 198 task is performed. 200 o Latency : When NRS is adopted into an ICN architecture, the 201 additional latency of the resolution obviously occurs in the 202 routing and forwarding system. Although the latency of the 203 resolution is added, the total latency could be minimized if the 204 nearest copies or off-path caches can be located by the NRS lookup 205 procedure. Additionally, there might be a trade-off between the 206 resolution latency and inter-domain traffic reduction. 208 o Security : When NRS is adopted into an ICN architecture, security 209 threats may increase. Protection of the NRS system against 210 attacks such as Distributed Denial of Service (DDoS) and 211 authentication of name mapping records and related signaling 212 messages would be challenging. 214 5. ICN Architectural Considerations for NRS 216 This section discusses the various items that have to be considered 217 from the point of view of ICN architecture when ICN utilizes an NRS. 218 These items are related with the name mapping records registration, 219 resolution, and update, protocols and messages, and integration with 220 the routing system. 222 5.1. Name mapping records registration, resolution, and update 224 When an NRS is integrated in an ICN architecture, the functions 225 related with the registration, resolution and update of name mapping 226 records have to be considered. The NRS nodes maintain the name 227 mapping records and may exist in an overlay network over the ICN 228 routers, that is, they communicate to each other through ICN routers. 229 The NRS nodes exist in a distributed manner so that an NRS node is 230 always available closer to an ICN node and communication latency for 231 the name registration and resolution performed by the ICN node 232 remains very low. 234 o Name registration: Name registration is performed by the producer 235 when it creates a new content. When a producer creates a content 236 and assigns a name to it from the name prefix space assigned to 237 it, the producer performs the name registration in an NRS node. 238 Name registration is possibly performed by an ICN router when it 239 does off-path caching or cooperative caching since involving an 240 NRS may be a good idea for off-path caching. As a content gets 241 cached in many ICN routers, all of them may register the same 242 content names in the same NRS node multiple times. In this case, 243 the NRS node adds the new location of the content to the name 244 record together with the previous locations. In this way, each of 245 the name records stored in the NRS node may contain multiple 246 locations of the content. 248 o Name resolution: Name resolution is performed to obtain the name 249 record from an NRS node by sending a name resolution request 250 message and getting the response containing the record. Regarding 251 the name-based ICN routing context, the name resolution will be 252 mostly performed by an ICN router that does not contain the name 253 in its FIB table. The name resolution may also be performed by 254 the consumer (in case the consumer is multihomed) to make decision 255 to forward the content request in a better direction so that it 256 obtains the content from the nearest cache. If the consumer is 257 single homed, it may not perform the name resolution. It creates 258 the content request packet containing the content name and 259 forwards to the nearest ICN router. The ICN router checks its FIB 260 table to see where to forward the content request. If the ICN 261 router fails to know the requested content reachable, it performs 262 name resolution to obtain the name mapping record and adds to FIB 263 table. The ICN router may also perform name resolution even 264 before the arrival of the content request time to use the name 265 mapping record to configure the FIB table. 267 o Name record update: Name record update is carried out when a 268 content name mapping record changes, e.g. the content is not 269 available in one or more of previous locations. 271 5.2. Protocols and Semantics 273 In order to develop an NRS system within a local ICN network domain 274 or global ICN network domain, new protocols and semantics should be 275 designed to manage and resolve names among different name spaces. 277 One way of implementing an NRS is by extending the basic ICN TLV 278 format and semantics [RFC8609] [RFC8569]. For instance, name 279 resolution and response messages can be implemented by defining new 280 type fields in the Interest and Content Object messages [CCNxNRS]. 281 Then it allows the ICN architecture to minimize implication of ICN 282 architectural changes. But NRS system cannot support more flexible 283 and scalable designs cause to restrict basic ICN protocol and 284 semantics. 286 On the other hand, an NRS system can be implemented by using its own 287 protocol and semantics like existing NRS systems, such as [Hong]. 288 For instance, the NRS protocol and messages can be implemented by 289 using a RESTful API. Then an NRS as application protocol can be 290 operated independently from a basic ICN architecture, but an ICN 291 architecture cannot be assisted with the routing protocol itself 292 effectively. 294 5.3. Routing System 296 It has to be considered how to process the information resolved by an 297 NRS lookup. The results of an NRS operation can be intended to be 298 used just to construct tunnels resulting in NRS identifying tunnel 299 endpoints. 301 Another way to process the information resolved by an NRS lookup is 302 to use it as routing hints in request messages. In this case, 303 request message needs to be re-written with the resolved information 304 including the original name that was requested by a consumer to check 305 the data integrity. 307 6. IANA Considerations 309 There are no IANA considerations related to this document. 311 7. Security Considerations 313 When NRS is integrated into an ICN architecture, security threats 314 will be increased in various aspects as follows: 316 o Name Space Management: In order to deploy an NRS in ICN 317 architecture, ICN name spaces, which are assigned by various 318 authoritative publishers, should be mapped and managed securely. 319 According to the ICN research challenge [RFC7927], new name space 320 can also provide an integrity verification function to 321 authenticate its publishers, so that the verification for mapping 322 among different name spaces should be securely required. 324 o NRS System: NRS enables deployment of new entities to build 325 distributed and scalable NRS systems. Thus, the entities, e.g., 326 mapping server that can be a mapping database, could be a single 327 point of failure receiving malicious requests from innumerable 328 adversaries like Denial of Service or Distributed Denial of 329 service attacks. Additionally, in order to communicate with the 330 entities to build a NRS system, an initiator should rely on other 331 NRS entities that are designed to be distributed deployed mapping 332 servers in each network domain. Because malicious entities should 333 be involved in this communication to impersonate control 334 functions. Thus, NRS entities should trust each other and 335 communications with them should be protected securely. 337 o NRS Protocols and Messages: In NRS system, additional messages 338 relatively lookup, update, etc., are flooding to unauthorized 339 networks, so that more security threats can be increased, such 340 that an adversary can manipulate these messages by hijacking to 341 response fake messages. After then a lot of problems as similar 342 with IP network's security issues, affect whole ICN architectures. 343 Therefore, security mechanisms such as accessibility, 344 authentication, etc., [NRSguidelines] for NRS system should be 345 considered to protect the ICN architecture as well as the NRS. 347 8. References 349 8.1. Normative References 351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 352 Requirement Levels", BCP 14, RFC 2119, 353 DOI 10.17487/RFC2119, March 1997, 354 . 356 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 357 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 358 "Information-Centric Networking (ICN) Research 359 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 360 . 362 8.2. Informative References 364 [Afanasyev] 365 Afanasyev, A. et al., "SNAMP: Secure Namespace Mapping to 366 Scale NDN Forwarding", IEEE Global Internet Symposium , 367 April 2015. 369 [Zhang2] Zhang, Y., "A Survey of Mobility Support in Named Data 370 Networking", NAMED-ORIENTED MOBILITY: ARCHITECTURES, 371 ALGORITHMS, AND APPLICATIONS(NOM) , 2016. 373 [Ravindran] 374 Ravindran, R. et al., "Forwarding-Label support in CCN 375 Protocol", draft-ravi-icnrg-ccn-forwarding-label-01 , July 376 2017. 378 [SAIL] "FP7 SAIL project.", http://www.sail-project.eu/ . 380 [MF] "NSF Mobility First project.", 381 http://mobilityfirst.winlab.rutgers.edu/ . 383 [Bayhan] Bayhan, S. et al., "On Content Indexing for Off-Path 384 Caching in Information-Centric Networks", ACM ICN , 385 September 2016. 387 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric 388 Networking (CCNx) Semantics", 389 https://www.rfc-editor.org/info/rfc8569 , July 2019. 391 [RFC8609] Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 392 Format", https://www.rfc-editor.org/info/rfc8609 , July 393 2019. 395 [CCNxNRS] Hong, J. et al., "CCNx Extension for Name Resolution 396 Service", draft-hong-icnrg-ccnx-nrs-02 , July 2018. 398 [Hong] Hong, J., Chun, W., and H. Jung, "Demonstrating a Scalable 399 Name Resolution System for Information-Centric 400 Networking", ACM ICN , September 2015. 402 [NRSguidelines] 403 Hong, J. et al., "Design Guidelines for Name Resolution 404 Service in ICN", draft-irtf-icnrg-nrs-requirements-03 , 405 November 2019. 407 [Dannewitz] 408 Dannewitz, C. et al., "Network of Information (NetInf)-An 409 information centric networking architecture", Computer 410 Communications vol. 36, no. 7, April 2013. 412 [Dannewitz2] 413 Dannewitz, C., DAmbrosio, M., and V. Vercellone, 414 "Hierarchical DHT-based name resolution for Information- 415 Centric Networks", Computer Communications vol. 36, no. 7, 416 April 2013. 418 Authors' Addresses 420 Jungha Hong 421 ETRI 422 218 Gajeong-ro, Yuseung-Gu 423 Daejeon 34129 424 Korea 426 Email: jhong@etri.re.kr 427 Tae-Wan You 428 ETRI 429 218 Gajeong-ro, Yuseung-Gu 430 Daejeon 34129 431 Korea 433 Email: twyou@etri.re.kr 435 Yong-Geun Hong 436 ETRI 437 218 Gajeong-ro, Yuseung-Gu 438 Daejeon 34129 439 Korea 441 Email: yghong@etri.re.kr 443 Ved Kafle 444 NICT 445 4-2-1 Nukui-Kitamachi 446 Koganei, Tokyo 184-8795 447 Japan 449 Email: kafle@nict.go.jp