idnits 2.17.1 draft-irtf-icnrg-nrsarch-considerations-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 11, 2019) is 1867 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 285, but not defined == Outdated reference: A later version (-02) exists of draft-ravi-icnrg-ccn-forwarding-label-01 == Outdated reference: A later version (-10) exists of draft-irtf-icnrg-ccnxsemantics-06 == Outdated reference: A later version (-09) exists of draft-irtf-icnrg-ccnxmessages-06 == Outdated reference: A later version (-06) exists of draft-irtf-icnrg-nrs-requirements-01 Summary: 1 error (**), 0 flaws (~~), 7 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: September 12, 2019 ETRI 6 March 11, 2019 8 Architectural Considerations of ICN using Name Resolution Service 9 draft-irtf-icnrg-nrsarch-considerations-01 11 Abstract 13 This document discusses architectural considerations and implications 14 of Information-Centric Networking (ICN) related to the usage of the 15 Name Resolution Service (NRS). It describes how ICN architectures 16 may change and what implications are introduced within the ICN 17 routing system when NRS is integrated into ICN. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 12, 2019. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 55 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Implications of NRS in ICN . . . . . . . . . . . . . . . . . 4 57 5. ICN Architectural Considerations for NRS . . . . . . . . . . 4 58 5.1. Name resolution . . . . . . . . . . . . . . . . . . . . . 5 59 5.2. Protocols and Semantics . . . . . . . . . . . . . . . . . 5 60 5.3. Routing System . . . . . . . . . . . . . . . . . . . . . 6 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 6.1. Name Space Separation . . . . . . . . . . . . . . . . . . 6 63 6.2. NRS System . . . . . . . . . . . . . . . . . . . . . . . 6 64 6.3. NRS Protocols and Messages . . . . . . . . . . . . . . . 6 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 8.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 Information-Centric Networking (ICN) is an approach to evolve the 74 Internet infrastructure to directly access Named Data Objects (NDOs) 75 by its name, i.e., the name of NDO is directly used to route the 76 request to the data object. Such name based routing in ICN poses a 77 number of issues, which are not solved yet in ICN. These issues 78 includes global scalability of routing, producer mobility, off-path 79 cache, etc. In order to address these issues, the Name Resolution 80 Service (NRS) has been integrated into several ICN projects and 81 literature [Afanasyev][Zhang2][Ravindran][SAIL][MF][Bayhan]. 83 This document describes how ICN architectures may change and what 84 implications are introduces within the ICN routing system when NRS is 85 integrated into ICN. It also discusses ICN architectural 86 considerations for an NRS. In other words, the scope of this 87 document includes considerations in the veiw of the ICN architecture 88 and routing system when integrating NRS into ICN. However, it does 89 not include the NRS discussion, itself, which is presented in 90 [NRSrequirements]. 92 2. Conventions and Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 3. Background 100 The name based routing in ICN can be helpful to address a number of 101 challenges, such as global scalability of routing, producer mobility, 102 and off-path caching in ICN. In order to address these challenges, 103 an NRS has been integrated into several ICN projects and literature: 105 o Routing scalability : In ICN, application names identifying 106 contents are used directly for packet delivery, so ICN routers run 107 a name-based routing protocol to build namebased routing and 108 forwarding tables. Similar to the scalability challenge of IP 109 routing, if non-aggregatable name prefixes are injected to the 110 Default Route Free Zone (DFZ) of ICN, they would be driving the 111 growth of the DFZ routing table size. Thus, applying an NRS can 112 be a feasible solution to keep the routing table size under 113 control, where the NRS resolves name prefixes which do not exist 114 in the DFZ forwarding table into globally routable prefixes such 115 as one proposed in NDN [Afanasyev]. Another approach deal with 116 routing scalability is the Multi-level Distributed Hash 117 Table (MDHT) used in NetInf [Dannewitz]. It provides name-based 118 anycast routing that can support a non-hierarchical namespace can 119 be adopted on a global scale [Dannewitz2]. 121 o Producer mobility : In ICN, if a producer moves into a different 122 authority domain or network location, the request for a content 123 produced by the moving producer with the origin name would be 124 hardly forwarded to the moving producer's new location. 125 Especially, in a hierarchical name scheme, producer mobility 126 support is much harder than in a flat name scheme since the 127 routing tables in broader area need to be updated according to the 128 producer movement. Therefore, various ICN architectures such as 129 NetInf [Dannewitz] and MobilityFirst [MF] have adopted NRS to 130 tackle the producer's location. 132 o Off-path caching : Caching in-network is considered a basic 133 architectural component of an ICN architecture and caching 134 approaches can be categorized into off-path caching and on-path 135 caching based on the location of caches in relation to the 136 forwarding path from the original server to a consumer. Off-path 137 caching, also referred as content replication or content storing, 138 aims at replicating content in various locations within a network 139 in order to increase availability, where the caching locations may 140 not be lying along the content forwarding path. Thus, finding 141 off-path cached objects is not trivial in name-based routing of 142 ICN. In order to support off-path caches, the locations of 143 replicas are usually advertised into a name-based routing system 144 or into NRS such as in [Bayhan]. 146 This document discusses architectural considerations and implications 147 of ICN when NRS is integrated into ICN to solve such challenges due 148 to the name-based routing in ICN. 150 4. Implications of NRS in ICN 152 In general, NRS would not be mandatory in an ICN architecture if the 153 name-based routing system can be scalable enough to timely reflect 154 the optimal location of requested content in the routing table. 155 However, due to the unlimited size of content namespace, it is not 156 easy to achieve such a scalable routing system in near future. 157 Therefore, the adoption of an NRS is a design choice for making ICN 158 routing and forwarding scalable. Integration of NRS would change the 159 ICN architecture at least with respect to procedures, latency, and 160 security, which are described below. 162 o Procedure : When NRS is adopted into an ICN architecture, the 163 procedure of the name resolution has to be integrated into ICN 164 overall procedures. For NRS integration, there are certain things 165 that have to be decided such as where and how the name resolution 166 task is performed. 168 o Latency : When NRS is adopted into an ICN architecture, the 169 additional latency of the resolution obviously occurs in the 170 routing and forwarding system. Although the latency of the 171 resolution is added, the total latency could be minimized if the 172 nearest copies or off-path caches can be located by the NRS lookup 173 procedure. Additionally, there might be a trade-off between the 174 resolution latency and inter-domain traffic reduction. 176 o Security : When NRS is adopted into an ICN architecture, security 177 treats may increase. Protection of the NRS system against attacks 178 such as Distributed Denial of Service (DDoS) and authentication of 179 name mapping records and related signaling messages would be 180 challenging. 182 5. ICN Architectural Considerations for NRS 184 This section discusses the various items that have to be considered 185 from the point of view of ICN architecture when it utilizes an NRS. 186 These items are related with the name mapping records registration, 187 resolution, and update, protocols and messages, and integration with 188 the routing system. 190 5.1. Name resolution 192 When an NRS is integrated into an ICN architecture, the followings 193 related with the registration and resolution of name mapping records 194 have to be considered. 196 o Who performs the name resolution? 198 o How is the name resolution performed? 200 The name resolution in ICN can be performed by consumer, routers, or 201 both. Once it is decided where the name resolution will take place, 202 it has to be considered how the name resolution will be performed. 203 The name provided by a consumer might be always resolved to 204 identifiers in a differnet namespace just like a DNS lookup. 205 Conversely, an NRS is always needed to map names to a different 206 namespace. 208 5.2. Protocols and Semantics 210 In order to develop a NRS system within a local ICN network domain or 211 global ICN network domain, new protocols and semantics should be 212 designed to manage and resolve names between different name spaces. 214 One way of implementing an NRS is by extending the basic ICN TLV 215 format and semantics [CCNxMessages] [CCNxSemantics]. For instance, 216 name resolution and response messages can be implemented by defining 217 new type fields in the Interest and Content Object messages 218 [CCNxNRS]. Then it allows the ICN architecture to minimize 219 implication of ICN architectural changes. But NRS system cannot 220 support more flexible and scalable designs cause to restrict basic 221 ICN protocol and semantics. 223 On the other hand, a NRS system can be implemented by using its own 224 protocol and semantics like existing NRS systems, such as [Hong]. 225 For instance, the NRS protocol and messages can be implemented by 226 using a RESTful API. Then a NRS as application protocol can be 227 operated independently from a basic ICN architecture, but an ICN 228 architecture cannot be assisted with the routing protocol itself 229 effectively. 231 5.3. Routing System 233 It has to be considered how to process the information resolved by an 234 NRS lookup. The results of an NRS operation can be intended to be 235 used just to construct tunnels resulting in NRS identifying tunnel 236 endpoints. 238 Another way to process the information resolved by an NRS lookup is 239 to use it as routing hints in request messages. In this case, 240 request message needs to be re-written with the resolved information 241 including the original name that was requested by a consumer to check 242 the data integrity. 244 6. Security Considerations 246 When NRS is integrated into an ICN architecture, security threats 247 shall be increased in various aspects such as followings. 249 6.1. Name Space Separation 251 In order to deploy an NRS on ICN architecture, ICN name spaces are 252 separated into more than two name spaces. Thus these name spaces 253 should be mapped and managed securely. According to the ICN research 254 challenge [RFC7927], new name space can also provide an integrity 255 verification function to authenticate its publishers. In addition to 256 the verification, binding two different name spaces should be 257 securely required. 259 6.2. NRS System 261 NRS enables deployment of new entities to build distributed and 262 scalable NRS systems. Thus, the entities, e.g., mapping server that 263 can be a mapping database, could be a single point of failure 264 receiving malicious requests from innumerable adversaries like Denial 265 of Service or Distributed Denial of service attacks. Additionally, 266 in order to communicate with the entities to build a NRS system, an 267 initiator should rely on other NRS entities that are designed to be 268 distributed deployed mapping servers in each network domain. Because 269 malicious entities should be involved in this communication to 270 impersonate control functions. Thus, NRS entities should trust each 271 other and communications with them should be protected securely. 273 6.3. NRS Protocols and Messages 275 Regarding NRS messages, such as lookup, update, etc., if these 276 messages are transported unauthenticated, an adversary can manipulate 277 them and hijack the important communication to response or to store 278 fake data. Thus, the adversary can generate malicious traffic to be 279 redirected to victim hosts. Therefore, security requirements for NRS 280 should be considered to protect the ICN architecture as well as the 281 NRS. 283 7. Acknowledgements 285 [TBD] 287 8. References 289 8.1. Normative References 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, 293 DOI 10.17487/RFC2119, March 1997, 294 . 296 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 297 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 298 "Information-Centric Networking (ICN) Research 299 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 300 . 302 8.2. Informative References 304 [Afanasyev] 305 Afanasyev, A. et al., "SNAMP: Secure Namespace Mapping to 306 Scale NDN Forwarding", IEEE Global Internet Symposium , 307 April 2015. 309 [Zhang2] Zhang, Y., "A Survey of Mobility Support in Named Data 310 Networking", NAMED-ORIENTED MOBILITY: ARCHITECTURES, 311 ALGORITHMS, AND APPLICATIONS(NOM) , 2016. 313 [Ravindran] 314 Ravindran, R. et al., "Forwarding-Label support in CCN 315 Protocol", draft-ravi-icnrg-ccn-forwarding-label-01 , July 316 2017. 318 [SAIL] "FP7 SAIL project.", http://www.sail-project.eu/ . 320 [MF] "NSF Mobility First project.", 321 http://mobilityfirst.winlab.rutgers.edu/ . 323 [Bayhan] Bayhan, S. et al., "On Content Indexing for Off-Path 324 Caching in Information-Centric Networks", ACM ICN , 325 September 2016. 327 [CCNxSemantics] 328 Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", 329 draft-irtf-icnrg-ccnxsemantics-06 , October 2017. 331 [CCNxMessages] 332 Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 333 Format", draft-irtf-icnrg-ccnxmessages-06 , October 2017. 335 [CCNxNRS] Hong, J. et al., "CCNx Extension for Name Resolution 336 Service", draft-hong-icnrg-ccnx-nrs-02 , July 2018. 338 [Hong] Hong, J., Chun, W., and H. Jung, "Demonstrating a Scalable 339 Name Resolution System for Information-Centric 340 Networking", ACM ICN , September 2015. 342 [NRSrequirements] 343 Hong, J. et al., "Requirements for Name Resolution Service 344 in ICN", draft-irtf-icnrg-nrs-requirements-01 , March 345 2019. 347 [Dannewitz] 348 Dannewitz, C. et al., "Network of Information (NetInf)-An 349 information centric networking architecture", Computer 350 Communications vol. 36, no. 7, April 2013. 352 [Dannewitz2] 353 Dannewitz, C., DAmbrosio, M., and V. Vercellone, 354 "Hierarchical DHT-based name resolution for Information- 355 Centric Networks", Computer Communications vol. 36, no. 7, 356 April 2013. 358 Authors' Addresses 360 Jungha Hong 361 ETRI 362 218 Gajeong-ro, Yuseung-Gu 363 Daejeon 34129 364 Korea 366 Email: jhong@etri.re.kr 367 Tae-Wan You 368 ETRI 369 218 Gajeong-ro, Yuseung-Gu 370 Daejeon 34129 371 Korea 373 Email: twyou@etri.re.kr 375 Yong-Geun Hong 376 ETRI 377 218 Gajeong-ro, Yuseung-Gu 378 Daejeon 34129 379 Korea 381 Email: yghong@etri.re.kr