idnits 2.17.1 draft-ravi-icnrg-ccn-forwarding-label-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 Introduction section. ** The document seems to lack a Security Considerations section. ** 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.) ** There are 30 instances of too long lines in the document, the longest one being 21 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 16, 2016) is 2716 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '2' on line 589 looks like a reference -- Missing reference section? '3' on line 594 looks like a reference -- Missing reference section? '4' on line 598 looks like a reference -- Missing reference section? '16' on line 639 looks like a reference -- Missing reference section? '8' on line 610 looks like a reference -- Missing reference section? '1' on line 586 looks like a reference -- Missing reference section? '14' on line 632 looks like a reference -- Missing reference section? '5' on line 601 looks like a reference -- Missing reference section? '7' on line 607 looks like a reference -- Missing reference section? '13' on line 628 looks like a reference -- Missing reference section? '15' on line 635 looks like a reference -- Missing reference section? '11' on line 621 looks like a reference -- Missing reference section? '9' on line 613 looks like a reference -- Missing reference section? '10' on line 618 looks like a reference -- Missing reference section? '6' on line 604 looks like a reference -- Missing reference section? '12' on line 625 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICN Research Group R. Ravindran 3 Internet-Draft A. Chakraborti 4 Intended status: Informational A. Azgin 5 Expires: May 20, 2017 Huawei Technologies 6 November 16, 2016 8 Forwarding-Label support in CCN Protocol 9 draft-ravi-icnrg-ccn-forwarding-label-00 11 Abstract 13 The objective of this proposal is to enable ID and Locator namespace 14 split in the CCN protocol that has several applications such as 15 towards Interest routing optimization, mobility, handling 16 indirections in manifests, and routing scalability. We enable this 17 through the notion of forwarding-label (FL) object, which is an 18 optional hop-by-hop payload in the Interest message with a locator 19 name which identifies a network domain, router, or a host. Depending 20 on the application and trust context, an FL object can be subjected 21 to policy based actions by the forwarders such as invoking security 22 verification or enabling other service-centric actions such as FL 23 object replacement. FL object can be inserted by the applications or 24 by the network. To enable dynamic name resolution FL objects can 25 also be modified in the network by designated points such as the edge 26 routers. 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 http://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 20, 2017. 45 Copyright Notice 47 Copyright (c) 2016 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 (http://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. ID-Locator Namespace Split in CCN . . . . . . . . . . . . . . 2 63 2. Forwarding-Label Object Proposal . . . . . . . . . . . . . . 4 64 2.1. FL Object Naming . . . . . . . . . . . . . . . . . . . . 4 65 2.2. FL Object Insertion . . . . . . . . . . . . . . . . . . . 4 66 2.3. FL Object Swapping . . . . . . . . . . . . . . . . . . . 5 67 2.4. FL Object Termination . . . . . . . . . . . . . . . . . . 5 68 3. FL Object Message Format . . . . . . . . . . . . . . . . . . 6 69 4. FL Object Processing Rules . . . . . . . . . . . . . . . . . 7 70 5. PIT Processing Implications . . . . . . . . . . . . . . . . . 8 71 6. Caching Implications . . . . . . . . . . . . . . . . . . . . 9 72 7. Multiple Domain Scenario . . . . . . . . . . . . . . . . . . 9 73 8. FL Object Security . . . . . . . . . . . . . . . . . . . . . 9 74 9. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . 10 75 9.1. Handling Producer Mobility . . . . . . . . . . . . . . . 10 76 9.2. Manifests . . . . . . . . . . . . . . . . . . . . . . . . 11 77 9.3. Interest Routing Optimization . . . . . . . . . . . . . . 14 78 9.4. Routing Scalability . . . . . . . . . . . . . . . . . . . 14 79 10. Informative References . . . . . . . . . . . . . . . . . . . 14 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 82 1. ID-Locator Namespace Split in CCN 84 In the context of ICN/CCN, we define identifier and locator as 85 follows: 87 o Identifier (ID) is a persistent secure or non-secure flat-ID or a 88 hierarchical name assigned to a content, device or service. If 89 the ID is secure, then trust relationship can be derived from it. 90 Generally the identifier space is managed by applications. 92 o Locator (LID) is a routeable topological name assigned to a 93 network entity such as a router, a server, or an end device. 94 Generally the locator space is managed and assigned by the network 95 administrators. 97 We discuss here the motivations behind the need for separation 98 between persistent name (ID) and a locator (LID) in the Interest 99 message in the context of CCN and a proposal to achieve this. The 100 advantages of ID/Locator have been extensively studied and it has 101 been part of many host-centric protocols such as HIP[2], ILNP [3], 102 and LISP [4] and is also part of FIA architectures such as 103 MobilityFirst[16]. Specifically in CCN, ID based routing is not 104 efficient considering the need to dynamically replicate content and 105 handle mobile entities, and the problem to address routing 106 scalability [8]. Hence providing this distinct ID-LID separation in 107 the protocol offers the following advantages: 109 o Today CCN applications bind to persistent IDs, while their 110 resolution is handled through per-hop name-based routing by a CCN 111 forwarder using unicast/anycast/broadcast mechanisms, with routing 112 scalability handled through its namespace aggregation. This model 113 can introduce problems when the named entity is mobile, migrated, 114 or replicated, as the names have to be announced in the routing 115 control plane which can in turn introduce routing instability and 116 scalability challenges (as the name aggregation to topological 117 binding cannot be satisfied anymore). Enabling ID/Locator split 118 and managing this mapping in a separate name resolution service 119 shall address the routing churn introduced by dynamic entities. 120 CCN is unique in the sense that both name-based routing and 121 resolution service can operate simultaneously driven by their use 122 based on a given context. For e.g. while inter-domain routing can 123 be handled using a name resolution service, intra-domain routing 124 can be based on name-based routing. 126 o ID and Locator namespaces are managed by different entities. IDs 127 are managed by applications, hence relevant only to consumers, 128 producers and intermediate service points, while locator names are 129 managed by a network administrator. Locators map to network 130 domains or specific network elements through which the named 131 entity is reachable. The relationship between the two is 132 established during the namespace publishing phase, and managed by 133 a separate name resolution service. ID/Locator distinction in CCN 134 allows applications to manage its own namespace and not be 135 restricted by the naming rules imposed by the network. 137 o Affording ID/Locator split in an Interest message offers many 138 advantages in CCN especially when a centralized control is applied 139 such as using NFV/SDN frameworks, enabling efficiency and 140 flexibility in name resolution, routing, mobility, service 141 chaining, and routing scalability. 143 Considering the above requirements, we propose a Forwarding-label 144 (FL) object, which acts as a locator and provides the flexibility to 145 forward Interests on a name other than the one provided within the 146 original Interest message with the ability to modify it within the 147 network. Handling ID/Locator mapping requires a control plane 148 infrastructure and appropriate network layer state with security 149 functions to prevent malicious usage. Specific control plane or 150 security mechanism of ID/Locator mapping is out of the scope of this 151 document as many techniques can be used towards achieving this. This 152 draft presents various considerations towards FL object management 153 such as: FL object insertion/modification/deletion, FL object 154 processing by a CCN forwarder, PIT/CS implications for FL object 155 carrying Interests, FL object Interest packet format, and security/ 156 trust considerations. We then discuss the application of FL object 157 in various scenarios. 159 2. Forwarding-Label Object Proposal 161 The use of FL is required when routing by ID is inefficient in 162 scenarios such as replicated content, device mobility, or scalability 163 challenges when ID based routing is employed. FL objects are 164 subjected to processing and modification in the network depending on 165 the specific use case scenario. Following we discuss various aspects 166 of FL related to its semantics and management. 168 2.1. FL Object Naming 170 FL objects are container objects that include LID, service specific 171 metadata, and security attributes for authentication. LIDs are 172 hierarchically structured topologically names where the names follow 173 the definition in [1]. The security attributes are optional and may 174 include validation payload and algorithm as discussed in [1]. 176 2.2. FL Object Insertion 178 An FL object can be inserted in an Interest message by the consuming 179 application or by the network. 181 In certain situations, the application logic may use an FL object in 182 addition to the ID in the Interest message or this action may also be 183 triggered because of feedback from the network, for instance due to 184 failure of routing the Interest message based on the ID. In such 185 situations, forwarders which process traffic from applications 186 outside the trust domain require a way to validate the FL object. A 187 possible approach to ensure trust in such situations is discussed in 189 [8] where a trust binding is provided between the ID and the LID as a 190 link object which can be validated by the forwarder. To avoid the 191 possibility of a misuse of an FL object, a default policy of the 192 network may be to ignore it from untrusted applications and only 193 choose to route by the content ID. 195 In the case where the FL object is inserted by the network, FL object 196 insertion is triggered at the ingress service routers of the network 197 domain. For instance, network may insert an FL object to an incoming 198 Interest message, if the Interest message satisfies the flow service 199 profiles that are imposed by the network administrator at the ingress 200 edge routers. The service profile matching actions may include 201 matching an Interest name to a set of service prefixes or triggered 202 by certain markings such as context-ID (for e.g. contexts may include 203 service, trust, location) in the Interest message. FL objects 204 inserted within the trust domain may not require security validation. 206 In situations where a forwarder handles both of these scenarios, 207 policies can be applied at the ingress router to handle the two cases 208 accordingly. These policies may include the face on which the 209 Interests arrives on, or the Interest IDs etc. 211 2.3. FL Object Swapping 213 An FL object can be swapped by another within the network in the 214 context of a given service at designated points, such as the service 215 edge routers, in the network. As an FL object carries a LID, and 216 with appropriate representation and security considerations in the 217 Interest message, FL objects also can be potentially stacked if the 218 Interest message has to be tunneled through a domain, where routing 219 based on the top level FL object is not feasible. 221 2.4. FL Object Termination 223 FL objects are terminated by a forwarder when the LID in it matches 224 its own LID. Here we assume a forwarder to possibly have many LIDs 225 such as domain-IDs or router-IDs. For e.g. a forwarder (in a domain) 226 identified as /att/santaclara can process an FL object with its LID 227 set to this router's domain name or to a forwarder ID such as 228 /att/santaclara/pop-x. Whenever an FL object is terminated by the 229 forwarder, depending on the service context, it can attach a new FL 230 object, or conduct additional processing (e.g. re-resolution of the 231 name to a new FL object) based on the Interest parameters. The FL 232 object can also include optional policy metadata based on which FL 233 objects can be swapped in the network. 235 3. FL Object Message Format 237 As FL objects are swappable in the network, it is proposed as a hop- 238 by-hop field in the optional body of the fixed header as shown in 239 Figure 1. The optional FL container includes attribute of type FL- 240 Object, which contains a name TLV identifying the LID (Figure 2). 241 LID is a hierarchically structured variable length name as defined in 242 [1]. A LID implies a locator such as an AS-ID, Gateway-ID, Router-ID 243 or Host-ID. In addition to the LID, optional FL metadata includes 244 contextual information on the application or the service to aid the 245 network for invoking an appropriate FL processing, such as trust 246 validation of the FL object. Optional security attributes, such as 247 authentication information, can be included depending on the specific 248 use case scenarios, such as secure name delegation information as 249 discussed in [8], or signature of the consumer. 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | CCN Fixed Header | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | | 255 / / 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Type = FL-Object | Length | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | LID TLV | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 / Optional FL Object Metadata / 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 / Optional FL Object Security Attributes / 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 / Interest Message Body / 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 Figure 1: Interest message with hop-by-hop Optional Forwarding-Label TLV 269 +----------------------+------------------+-----------------+ 270 | Forwarding-Label | Meaning | Value | 271 +----------------------+------------------+-----------------+ 272 | LID TLV | Identifies an | Name TLV | 273 | | AS-ID/Gateway-ID/| | 274 | | Host-ID | | 275 +----------------------+------------------+-----------------+ 277 Figure 2: Locator-ID (LID) Definition 279 4. FL Object Processing Rules 281 The following discussion is based on the assumption that all 282 forwarders must process the optional header fields. In the context 283 of CCN packet processing, FL object is only relevant when the 284 decision to forward the Interest message is to be made. At this 285 stage, multiple options exist, assuming consistent policies exists 286 throughout the domain: 1) In the first scenario, the rule may be that 287 if an FL object is included in an Interest message, then it should be 288 given preference over the ID. This is under the assumption that FL 289 objects are trusted indirections within the Interest message, and can 290 be validated by the router if required; 2) In the second scenario, 291 the forwarder could prioritize forwarding on the ID, and then forward 292 on the LID at every hop; 3) In the third scenario, where policy based 293 routing is involved, more complex routing approaches can be 294 considered at the network edge, such as the forwarder could apply 295 service policy on the Interest ID and choose to remove or swap it 296 with a new FL object irrespective of the current FL object inserted 297 in the Interest message, while the core nodes could use a more 298 simpler approach, such as approach 1 or 2. Following are the steps 299 when approach 1 is applied. 301 o During Interest packet processing, while a forwarding decision is 302 being made, if an LID is available then it should be preferred for 303 forwarding over the name in the Interest message irrespective of 304 the feasibility of ID based routing. 306 o The validation of FL depends on the trust context. In trusted 307 scenarios, where the applications and the network are managed by 308 the same authority, the forwarder can bypass the validation. In 309 untrusted scenarios, the edge router may validate the FL that is 310 inserted by the sender, and to avoid re-validations by successive 311 forwarders, these Interests can be marked to have been validated 312 at the ingress point. 314 o If FL object is trusted and validated and the lookup based on LID 315 in the FL object succeeds, then two possibilities exist: 1) for a 316 non-terminating flow, the LID FIB lookup results in a next hop 317 towards which the Interest is forwarded ; 2) for a terminating 318 flow, LID lookup invokes a service logic wherein the service 319 either re-resolves the Interest ID to another LID resulting in a 320 new FL object or removes the current FL object and subjects the 321 Interest to regular processing based on the ID in the Interest 322 message. 324 o If the FL object is trusted and validated and the LID lookup 325 fails, then the router can try to forward the Interest based on 326 the Interest ID. However if routing based on the Interest ID 327 fails, then the router could raise an error condition and feedback 328 the message to the previous hop, in the same or a different 329 domain, with the appropriate error code. 331 5. PIT Processing Implications 333 To maintain the simplicity of the forwarding logic, the purpose of an 334 FL object should be to guide the Interest towards the closest source 335 of the resource entity, hence FL object may only be used for the 336 forwarding decision and not be required for content object 337 processing. However there may be usage scenarios where the FL object 338 state is required to be saved in the PIT and even piggybacked in the 339 content object (CO). 341 For example, in the case when there is no binding between the ID and 342 the LID in the Interest expressed by a consumer, and multiple 343 Interests arrive carrying the same ID but with different LIDs, then 344 the expected outcome is to forward all such Interests with unique 345 LIDs. In this case the forwarder is required to save the LID along 346 with the Interest ID in the PIT and forward the duplicate Interest 347 whose LIDs differ from ID to LIDs state saved in the PIT. 349 In another application, it may be required to decouple the choice of 350 one consumer's LID from another consumer's LID, i.e, when a secure 351 binding exists between the ID and the LID. In this case, the 352 forwarder stores the FL object in the PIT, and the returning CO 353 should piggyback the Interest's FL object as long as the CO is from 354 the location intended in the LID, which is matched against the 355 pending PIT entry before continuing with the reverse path forwarding. 356 In cases, where the FL object is swapped by the intermediate routers, 357 the CO should be updated with the appropriate FL to ensure matching 358 of the PIT entries along the previous hops. These considerations are 359 similar to those elaborated in [14]. 361 6. Caching Implications 363 The considerations here follow our previous discussion, where the FL 364 object is piggybacked in the CO. If there is an implicit security 365 binding between the Interest ID and the LID, then the FL object state 366 is piggybacked along with the CO, and the FL object in the incoming 367 Interest should be matched against the CO's FL object before the 368 cached content object is returned. 370 7. Multiple Domain Scenario 372 In wide area network scenarios, Interests cross multiple domains. If 373 an FL object is only trusted within the domain boundaries, then the 374 FL object is removed before the Interest is forwarded to the next 375 domain, which then, upon entry inserts a new forwarding label with 376 the associated security attributes at the ingress of the next domain. 377 But if trust exists between domains, such as one through a trusted 378 third party (validated based on the FL object security binding), to 379 use the FL inserted by the previous domain, then the intermediate 380 domains can avoid further FL processing and use the FL object passed 381 on by the previous domains. 383 8. FL Object Security 385 FL object security is related to the purpose it is used for and the 386 control plane mechanism used to manage it. Depending on the use case 387 scenario of the FL, appropriate security mechanisms should be applied 388 to secure the control and data planes to avoid exploitation of this 389 feature. 391 Generally, the major threats against the FL object approach is to 392 manipulate the relationship between the name and the FL object. Such 393 manipulations can happen in various scenarios, some of which are 394 listed as follows: (i) a malicious interceptor (acting as a 395 publisher) intentionally injecting an incorrect mapping into the name 396 resolution system; (ii) a malicious interceptor (between the edge 397 router and the resolution server) manipulating the mapping sent back 398 from the name resolution system when the edge router queries the 399 mapping system ; (iii) a compromised intermediate router maliciously 400 changing the FL object, e.g., with the wrong FL object or an out- 401 dated FL object; (iv) an untrusted application injecting invalid FL 402 object into the Interest message. 404 To achieve network level FL security, appropriate mechanisms should 405 be applied to provide mapping provenance, mapping integrity and to 406 prevent replay attack to address these issues. The security 407 mechanisms applicable to the above discussed scenarios (i) and (ii) 408 are similar to ones applied to secure other mapping systems such as 409 LISP [5] and DNS[7]. Scenario (iii) requires new security 410 mechanisms, one such way is to enable a domain level trust 411 infrastructure so that the mapping between the name and the FL object 412 can be authenticated by the successive routers. 414 In untrusted environments, when an FL object is inserted in the 415 Interest message by the end hosts, appropriate authentication 416 information should also be included in the FL object to allow ingress 417 routers to optionally validate the delegation of the Interest ID to 418 LID [8]. Furthermore, additional security policies can be enabled by 419 the network to handle FL objects outside its trust domain. 421 9. Use Case Scenarios 423 Here we provide the discussions related to using FL objects in 424 different scenarios. 426 9.1. Handling Producer Mobility 428 In the literature the different techniques to handle producer 429 mobility can be classified into the following two types: 431 o Application-based approach, where the application takes the 432 responsibility for announcing its reacheability to the network and 433 triggering a network state change to enable Interest routing 434 towards the mobile producer. Most of the current proposals fall 435 under this category, and these include the following two 436 approaches: 1)The Kite proposal [13] implements an anchor based 437 approach where consumers and producers agree on an anchor point 438 based on external mechanisms and uses application initiated 439 (traced and tracing) Interests to handle the producer mobility; 440 2)The anchor-less proposal [15] is another application-based 441 approach wherein enhanced name-based routing is used to track the 442 mobile producer. While these approaches allow consumers and 443 producers to work on a single name space, it raises scalability 444 concerns with increasing number of mobile nodes and number of 445 applications signaling into the network. As these approaches 446 introduce more signaling in the network, the operational 447 efficiency of packet forwarding is negatively affected due to the 448 state changes that have to be applied to maintain the sanity of 449 the Interest packet processing logic. Another potential security 450 issue with these approaches is that it can be prone to flooding 451 attacks by malicious applications targeting specific application 452 names and impeding their normal operation. 454 o Network-based approach uses the late-binding technique [11], 455 wherein the reachability of the mobile node is handled by the 456 network. In this case applications can explicitly request 457 mobility for a given name space [9], with the network handling the 458 mobility by tracking its latest location in the network through a 459 name resolution system. At the same time, through coordination of 460 the old and new point-of-attachments (PoA) and in-band signaling 461 one can achieve zero loss for a given Interest flow. The late- 462 binding technique uses ID/Locator split that is only applied at 463 the PoAs, thereby avoiding any routing churn in the network due to 464 producer mobility, while offering better scalability when the 465 number of mobile producers increases. Here the mobile entity (ME) 466 registers a persistent name that requires mobility with its 467 current point-of-attachment (PoA). The PoA then registers the 468 mapping between the name and the PoA's locator in its local name 469 resolution system. Then the domain updates the ME's home domain 470 name resolution system with its current domain LID. When a 471 correspondent nodes expresses Interest for the name, it is first 472 resolved to the current ME domain by the home domain. When the 473 Interest enters the domain offering mobility service, it is 474 resolved again to the ME's current location. Furthermore PoA-to- 475 PoA signaling can be enabled to offer seamless forwarding of 476 Interests whenever an ME changes its PoA. In addition to 477 correcting the path stretch the Interests re-routed from the old 478 PoA can be marked and re-routed to the new PoA with the new FL. 479 On the return path, the CO are also marked, this in-band marking 480 is used by the ingress PoA at the consumer's end to re-resolve the 481 mobile prefix to a new forwarding locater that would correct the 482 path stretch. 484 9.2. Manifests 486 The FL objects can also be used to support the retrieval of nameless 487 objects [10]. Using the current manifest proposal [6] a consumer 488 receives a manifest with the ContentObjectHashIDs and their 489 respective locator information. A consuming application uses the 490 locater as a routeable content name, while the ContentObjectHashID is 491 used as a HashID restriction parameter. Multiplexing the Interest 492 name field as an ID and also as an LID has the following 493 consequences: (1) a forwarder cannot distinguish between Interest 494 packets containing ID or LID in the name field, as the protocol 495 doesn't differentiate these two constructs; (2) it complicates 496 Interest processing when LID is used as a name, by first requiring to 497 check for the presence of ContentObjectHashID, and to use it to index 498 the Interest based on it instead of the locator name; (3) more 499 complications arise if an Interest packet arrives with two IDs i.e. a 500 ContentObjectHashID as the hash restriction and the ID as the content 501 name, in which case, one of them may seek precedence over the other. 503 The above issues can be avoided through the use of the 504 ContentObjectHashID as the content name and the locater in the FL 505 object. In this case, a forwarder will always index the pending 506 Interest table based on the content name. The routing decision then 507 would be based on the FL object depending on the routing policy in 508 the forwarder. This also avoids the situation of dealing with two 509 IDs in the Interest packet, i.e. the application has to choose either 510 ID or ContentObjectHashID as the content ID. This use of FL object 511 can be enforced in a straight forward manner by identifying flat-ID, 512 e.g. ContentObjectHashID, and routeable name as different typed name 513 objects in the Interest packet. 515 A possible high level forwarding logic for the edge/core router to 516 support nameless objects based on the above discussion is presented 517 in Figure 3. Here edge router can also be a gateway node. 519 Begin 521 if Edge_Router 522 If Interest arrives on a face with a flat-ID 523 Then check for the presence of FL object 524 If FL object is present, use the LID in the FL object for Interest forwarding 526 If there no FL Object 527 If policy allows, resolve the flat-ID with a NRS to obtain an FL object 528 Use the FL object to route the Interest 530 End 532 If the Interest arrives with a routeable ID 533 If there is FL object 534 Then use the ID for forwarding and Remove the FL object 536 If there is no FL object 537 Match Interest ID with name policy for e.g. mobility or interest routing optimization 538 If a name policy for resolution exists 539 Then network resolution service is invoked on the ID which returns an FL object 540 Use the FL object to direct the Interest to the appropriate next hop 541 End 542 End 544 if Core_Router 545 if Interest arrives with an FL Object 546 Use the LID for forwarding 547 Else if Interest is with a Routeable ID 548 Use the name for forwarding 549 End 551 Figure 3: Forwarding logic to support flat-ID and routeable ID at the edge router 553 We discuss security implications of using ID and FL object in the 554 Interest message depending on the ID type and 556 o Case 1 - ContentObjectHashId with FL object: This use case is a 557 straight forward simplification of what is being proposed in [10]. 558 Here the locator is included within the FL object and the 559 ContentObjectHashId is used as the name, so this shouldn't 560 introduce any new security concerns. This holds good for both 561 application and network based FL object insertion. 563 o Case 2 - Routeable ID with FL object: For UE based FL object 564 insertion, this scenario can cause cache poisoning in the absence 565 of signature check enforcement in the forwarders. For the case 566 when FL object is managed within a trusted domain, the security 567 implications are discussed in Section 8. 569 9.3. Interest Routing Optimization 571 Networks which hosts its own or third party content/service can 572 benefit from the ability to handle Interest routing logic in its 573 domain opportunistically. When a Interest seeking a specific content 574 or service enters a network domain, the ingress router can redirect 575 the Interest to the closest cache point or service location. 577 9.4. Routing Scalability 579 As discussed in [8], locator based routing can address routing 580 scalability as the number of ASs are many orders less than the number 581 of information objects. This reduces the forwarding table in the DFZ 582 zone in the order of number of ASs in the Internet. 584 10. Informative References 586 [1] CCN Wire format, CCNX1., "http://www.ietf.org/id/ 587 draft-mosko-icnrg-ccnxmessages-00.txt.", 2013. 589 [2] Nikander, P., Gurtov, A., and T. Henderson, "Host identity 590 protocol (HIP): Connectivity, mobility, multi-homing, 591 security, and privacy over IPv4 and IPv6 networks", IEEE 592 Communications Surveys and Tutorials, pp: 186-204, 2010. 594 [3] Atkinson, R., "An Overview of the Identifier-Locator 595 Network Protocol (ILNP)", Technical Report, University 596 College London, 2005. 598 [4] LISP, RFC6380., "https://tools.ietf.org/html/draft-ietf- 599 lisp-sec-07.", 2014. 601 [5] LISP-Security, LISP-SEC., "https://tools.ietf.org/html/ 602 draft-ietf-lisp-sec-07.", 2014. 604 [6] CCNx, Manifest., "http://www.ccnx.org/pubs/ 605 draft-wood-icnrg-ccnxmanifests-00.html.", 2015. 607 [7] DNS-SEC, RFC4033., "DNS Security Introduction and 608 Requirements.", 2005. 610 [8] Afanasyev, A., "Map-and-Encap for Scaling NDN Routing.", 611 NDN Technical Report ndn-004-02, 2015. 613 [9] Azgin, A., Ravidran, R., Chakraborti, A., and G. Wang, 614 "Seamless Producer Mobility as a Service in Information 615 Centric Networks.", 5G/ICN Workshop, ACM ICN Sigcomm 2016, 616 2016. 618 [10] Mosko, M., "Nameless Objects.", IETF/ICNRG, Paris 619 Interim 2016, 2016. 621 [11] Azgin, A., Ravindran, R., and G. Wang, "A Scalable 622 Mobility-Centric Architecture for Named Data Networking.", 623 ICCCN (Scene Workshop) , 2014. 625 [12] Cisco System Inc., CISCO., "Cisco visual networking index: 626 Global mobile data traffic forecast update.", 2009-2014. 628 [13] Zhang, Y., Zhang, H., and L. Zhang, "Kite: A Mobility 629 Support Scheme for NDN.", NDN, Technical Report NDN-0020 , 630 2014. 632 [14] CCNx Label Forwarding, CCNLF., "http://www.ccnx.org/pubs/ 633 ccnx-mosko-labelforwarding-01.txt.", 2013. 635 [15] Auge, J., Carofiglio, G., Grassi, G., Muscariello, L., 636 Pau, G., and X. Zeng, "Anchor-less Producer Mobility in 637 ICN.", ICN, Sigcomm, 2015 , 2015. 639 [16] NSF FIA project, MobilityFirst., 640 "http://www.nets-fia.net/", 2010. 642 Authors' Addresses 644 Ravishankar Ravindran 645 Huawei Technologies 646 2330 Central Expressway 647 Santa Clara, CA 95050 648 USA 650 Email: ravi.ravindran@huawei.com 651 Asit Chakraborti 652 Huawei Technologies 653 2330 Central Expressway 654 Santa Clara, CA 95050 655 USA 657 Email: asit.chakraborti@huawei.com 659 Aytac Azgin 660 Huawei Technologies 661 2330 Central Expressway 662 Santa Clara, CA 95050 663 USA 665 Email: aytac.azgin@huawei.com