idnits 2.17.1 draft-irtf-icnrg-nrsarch-considerations-00.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 (October 17, 2018) is 2015 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 261, 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 (-02) exists of draft-hong-icnrg-ccnx-nrs-00 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: April 20, 2019 ETRI 6 October 17, 2018 8 Architectural Considerations of ICN using Name Resolution Service 9 draft-irtf-icnrg-nrsarch-considerations-00 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 architecture 16 changes and what implications are in the routing system when NRS is 17 utilized in 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 April 20, 2019. 36 Copyright Notice 38 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . 2 55 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Implications of NRS in ICN . . . . . . . . . . . . . . . . . 4 57 5. ICN Architectural Considerations for NRS . . . . . . . . . . 4 58 5.1. Resolution . . . . . . . . . . . . . . . . . . . . . . . 4 59 5.2. Protocols and Semantics . . . . . . . . . . . . . . . . . 5 60 5.3. Routing System . . . . . . . . . . . . . . . . . . . . . 5 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 6.1. Name Space Separation . . . . . . . . . . . . . . . . . . 5 63 6.2. NRS System . . . . . . . . . . . . . . . . . . . . . . . 6 64 6.3. NRS Protocols and Messages . . . . . . . . . . . . . . . 6 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 8.2. Informative References . . . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 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 function has been applied to several ICN projects and literature 81 [Afanasyev][Zhang2][Ravindran][MF][Bayhan]. 83 Thus, this document describes how ICN architecture changes and what 84 implications are in the routing system when Name Resolution Sevice 85 (NRS) is utilized in ICN. It also discusses ICN architectural 86 considerations for a NRS. 88 2. Conventions and Terminology 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 3. Background 96 The name based routing in ICN poses a number of issues, such as 97 global scalability of routing, producer mobility, off-path cache, 98 etc., which are not solved yet in ICN. In order to address these 99 issues, the name resolution function as a Name Resolution Sevice 100 (NRS) has been applied to several ICN projects and literature: 102 o Routing scalability : In ICN, application names identifying 103 contents are used directly for packet delivery, so ICN routers run 104 a name-based routing protocol to build namebased routing and 105 forwarding tables. As same as scalability of IP routing, if non- 106 aggregated name prefixes are injected to the Default Route Free 107 Zone (DFZ) of ICN, then they would be driving the growth of the 108 DFZ routing table size. Thus a NRS can be used as a solution to 109 keep the routing table size under control, where the NRS resolves 110 name prefixes which do not exist in the DFZ forwarding table into 111 globally routable prefixes such as NDNS in [Afanasyev]. 113 o Producer mobility : In ICN, if a producer moves into different 114 authority domain or network location, then the request for a 115 content produced by the moving producer with the origin name would 116 be hardly forwarded to the moving producer. Especially in a 117 hierarchical name scheme, producer mobility support is much harder 118 than in a flat name scheme since the routing tables related in 119 broad area should be updated according to the producer movement. 120 Therefore, various ICN literatures such as MobilityFirst [MF] 121 would adopt NRS to retrieve the producer's location. 123 o Off-path caching : Caching in-network is considered to be a basic 124 architectural component of an ICN architecture and caching 125 approaches can be categorized into off-path caching and on-path 126 caching based on the location of caches in relation to the 127 forwarding path from a original server to a consumer. Off-path 128 caching, also referred as content replication or content storing, 129 aims to replicate content within a network in order to increase 130 availability, regardless of the relationship of the location to 131 the forwarding path. Thus, finding off-path cached objects is not 132 trivial in name based routing of ICN. In order to support off- 133 path caches, replicas are usually advertised into a name- based 134 routing system or into NRS such as in [Bayhan]. 136 Thus, this document discusses architectural considerations and 137 implications of ICN when NRS is needed and utilized in ICN to solve 138 such issues due to the name based routing in ICN. 140 4. Implications of NRS in ICN 142 In general, NRS is not mandatory in an ICN architecture and the 143 majority of ICN projects use the name based routing which omits the 144 name resolution. Thus adopting a NRS would change the ICN 145 architecure at least on procedures, latency, and security: 147 o Procedure : When NRS is adopted into an ICN architecture, the 148 procedure of the name resolution has to be added into ICN overall 149 procedures. On changing procedures, there are certain things that 150 have to be decided such as who and how the resolution does. 152 o Latency : When NRS is adopted into an ICN architecture, the 153 additional latency of the resolution obviously occurs. Although 154 the latency of the resolution is added, the total latency could be 155 minimized if the nearest copies or off-path caches can be found by 156 NRS lookup. Also, there might be a trade-off between the 157 resolution latency and inter-damain traffic reduction. 159 o Security : When NRS is adopted into an ICN architecture, security 160 treats could be increased with the above additional procedures, 161 which include authentication of NRS messages and name spaces, and 162 protecting NRS entities such as mapping servers from Denial of 163 Service or Distributed Denial of service attacks. 165 5. ICN Architectural Considerations for NRS 167 This section discusses what kinds of things have to be considered 168 from the point of view of ICN architecture when it utilizes a NRS. 170 5.1. Resolution 172 When a NRS is applying to an ICN architecture, the followings have to 173 be considered: 175 o Who does the resolution? 177 o How does the resolution? 179 The resolution can be done by consumer, routers, or both. Once it is 180 decided where the resolution takes place, it has to be considered how 181 the resolution does. The name provided by consumer might be always 182 resolved to identifiers in a differnet namespace just like DNS 183 lookup. Conversely, a NRS is ever needed to map names to a diferent 184 namespace. 186 5.2. Protocols and Semantics 188 In order to develop NRS system whether in local ICN network domain or 189 global ICN networking system, new protocol and semantics should be 190 designed to manage and resolve in between different name spaces. 191 Basically NRS can be implemented by extension of basic ICN TLV format 192 and semantics ension of basic ICN TLV format and semantics 193 [CCNxMessages] [CCNxSemantics]. For instance, resolution and 194 response messages can be implemented by defining new type fields in 195 Interest and Content Object message format [CCNxNRS]. Then it allows 196 ICN architecture to minimize implication of ICN architectural 197 changes. But NRS system cannot support more flexible and scalable 198 designs cause to restrict basic ICN protocol and semantics. 200 On the other hand, NRS system can be implemented by using its own 201 protocol and semantics like as existing NRS systems, such as [Hong]. 202 For instance, NRS protocol and messages can be implemented by using 203 RESTful API. Then NRS as application protocol can be operated 204 independently from basic ICN architecture. But ICN architecture 205 cannot get assist of routing protocol itself effectively. 207 5.3. Routing System 209 It has to be considered how to process the resolved information by 210 NRS lookup. The results of an NRS operation can be intended to be 211 used just to construct tunnels resulting in NRS identifying tunnel 212 endpoints. 214 Another way to process the resolved information by NRS lookup is to 215 use it as routing hints in request messages. In this case, request 216 message needs to be re-written by the resolved information including 217 the original name that was requested by consumer to check the data 218 integrity. 220 6. Security Considerations 222 When NRS is adopted in an ICN architecture, security threats shall be 223 increased in various aspects such as followings. 225 6.1. Name Space Separation 227 In order to deploy NRS on ICN architecture, ICN name spaces are 228 separated into more than two name spaces. Thus these name spaces 229 should be mapped and managed securely. According to the ICN research 230 challenge [RFC7927], new name space can also provide an integrity 231 verification function to authenticate its publishers. In addition to 232 the verification, binding two different name spaces should be 233 securely required. 235 6.2. NRS System 237 NRS enables deployment of new entities to build distributed and 238 scalable NRS system. Thus, the entities, e.g., mapping server that 239 can be a mapping database., could be a single point of failure cause 240 to receive malicious requests from innumerable adversaries like as 241 mount Denial of Service or Distributed Denial of service attacks. 242 Additionally, in order to communicate with the entities to build NRS 243 system, an initiator should rely on other NRS entities that are 244 designed to distributed deploy mapping servers in each network 245 domains. Because malicious entities should be involved in this 246 communication to impersonate control functions. Thus, NRS entities 247 should trust each other and communications with them should be 248 protected securely. 250 6.3. NRS Protocols and Messages 252 Regarding NRS messages, such as lookup, update, and etc., if these 253 messages are transported unauthenticated, an adversary can manipulate 254 them and hijack the important communication to response or to store 255 fake data. Thus, the adversary can generate malicious traffics to be 256 redirected to victim hosts. Therefore, security requirements for NRS 257 should be considered to protect ICN architecture as well as NRS. 259 7. Acknowledgements 261 [TBD] 263 8. References 265 8.1. Normative References 267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 268 Requirement Levels", BCP 14, RFC 2119, 269 DOI 10.17487/RFC2119, March 1997, 270 . 272 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 273 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 274 "Information-Centric Networking (ICN) Research 275 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 276 . 278 8.2. Informative References 280 [Afanasyev] 281 Afanasyev, A. et al., "SNAMP: Secure Namespace Mapping to 282 Scale NDN Forwarding", IEEE Global Internet Symposium , 283 April 2015. 285 [Zhang2] Zhang, Y., "A Survey of Mobility Support in Named Data 286 Networking", NAMED-ORIENTED MOBILITY: ARCHITECTURES, 287 ALGORITHMS, AND APPLICATIONS(NOM) , 2016. 289 [Ravindran] 290 Ravindran, R. et al., "Forwarding-Label support in CCN 291 Protocol", draft-ravi-icnrg-ccn-forwarding-label-01 , July 292 2017. 294 [MF] "NSF Mobility First project.", 295 http://mobilityfirst.winlab.rutgers.edu/ . 297 [Bayhan] Bayhan, S. et al., "On Content Indexing for Off-Path 298 Caching in Information-Centric Networks", ACM ICN , 299 September 2016. 301 [CCNxSemantics] 302 Mosko, M., Solis, I., and C. Wood, "CCNx Semantics", 303 draft-irtf-icnrg-ccnxsemantics-06 , October 2017. 305 [CCNxMessages] 306 Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV 307 Format", draft-irtf-icnrg-ccnxmessages-06 , October 2017. 309 [CCNxNRS] Hong, J. et al., "CCNx Extension for Name Resolution 310 Service", draft-hong-icnrg-ccnx-nrs-00 , October 2017. 312 [Hong] Hong, J., Chun, W., and H. Jung, "Demonstrating a Scalable 313 Name Resolution System for Information-Centric 314 Networking", ACM ICN , September 2015. 316 Authors' Addresses 318 Jungha Hong 319 ETRI 320 218 Gajeong-ro, Yuseung-Gu 321 Daejeon 34129 322 Korea 324 Email: jhong@etri.re.kr 325 Tae-Wan You 326 ETRI 327 218 Gajeong-ro, Yuseung-Gu 328 Daejeon 34129 329 Korea 331 Email: twyou@etri.re.kr 333 Yong-Geun Hong 334 ETRI 335 218 Gajeong-ro, Yuseung-Gu 336 Daejeon 34129 337 Korea 339 Email: yghong@etri.re.kr