idnits 2.17.1 draft-ietf-lwig-nbr-mgmt-policy-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 : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 22, 2018) is 2252 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-13 == Outdated reference: A later version (-15) exists of draft-ietf-6tisch-minimal-security-04 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LWIG R. Jadhav, Ed. 3 Internet-Draft R. Sahoo 4 Intended status: Informational Huawei 5 Expires: August 26, 2018 S. Duquennoy 6 Inria 7 J. Eriksson 8 Yanzi Networks 9 February 22, 2018 11 Neighbor Management Policy for 6LoWPAN 12 draft-ietf-lwig-nbr-mgmt-policy-01 14 Abstract 16 This document describes the problems associated with neighbor cache 17 management in constrained multihop networks and a sample neighbor 18 management policy to deal with it. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 26, 2018. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language and Terminology . . . . . . . . . . 4 56 2. Neighbor Management . . . . . . . . . . . . . . . . . . . . . 5 57 2.1. Significance of Neighbor management policy . . . . . . . 5 58 2.2. Trivial neighbor management policies . . . . . . . . . . 6 59 2.3. Lifecycle of a NCE . . . . . . . . . . . . . . . . . . . 7 60 2.3.1. NCE Insertion . . . . . . . . . . . . . . . . . . . . 7 61 2.3.2. NCE Deletion . . . . . . . . . . . . . . . . . . . . 10 62 2.3.3. NCE Eviction . . . . . . . . . . . . . . . . . . . . 11 63 2.3.3.1. Eviction for directly connected routing entries . 11 64 2.3.4. NCE Reinforcement . . . . . . . . . . . . . . . . . . 12 65 2.4. Requirements of a good neighbor management policy . . . . 12 66 2.5. Approaches to neighbor management policy . . . . . . . . 13 67 2.5.1. Reactive Approach . . . . . . . . . . . . . . . . . . 13 68 2.5.2. Proactive Approach . . . . . . . . . . . . . . . . . 13 69 3. Reservation based Neighbor Management Policy . . . . . . . . 14 70 3.1. Limitations of such a policy . . . . . . . . . . . . . . 15 71 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 76 7.2. Informative References . . . . . . . . . . . . . . . . . 17 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 79 1. Introduction 81 In a wireless multihop network, the node densities (maximum number of 82 devices connected on a single hop) may vary significantly depending 83 upon deployments/scenarios. While there is some policy control 84 possible with regards to the network size in terms of maximum number 85 of devices connected, it is especially difficult to set a figure on 86 what will be the maximum node density given a deployment. For e.g. 87 A network can put an upper limit on max 1000 devices but it is 88 impossible to state what the node density will be in this 1000 node 89 network. 91 A neighbor cache is used for populating neighboring one-hop connected 92 nodes information such as MAC address, link local IP address and 93 other reachability state information. Node density has direct 94 implications on the neighbor cache and in constrained network 95 scenario the size of the neighbor cache will be limited. Thus there 96 are chances that a node may not be able to fit all the neighboring 97 nodes in its cache in which case it has to prioritize entries and 98 thus needs a neighbor management policy. 100 This draft presents problems related to neighbor management policies 101 by considering a security-enabled multi-hop 6lo network. This 102 document considers RPL [RFC6550] as a routing protocol and PANA (EAP- 103 PANA) [RFC5191] as a network access protocol. For RPL, both the 104 storing and non-storing mode of operations are considered. We also 105 provide a sample neighbor management policy which can be used in such 106 networks and its limitations. The aim of such a policy is to retain 107 set of neighbor cache entries with high quality links such that 108 routing adjacencies are stablized. 110 The problem statement and the proposed solution described is also 111 relevant to other multihop constrained scenarios such as 6TiSCH 112 [I-D.ietf-6tisch-architecture]. [I-D.ietf-6tisch-minimal-security] 113 talks about a pledge (new joinee) node authenticating via a Join 114 Proxy. The considerations mentioned in this document are applicable 115 for such networks as well. 117 +--------+ 118 | PAA/ | 119 +------| Auth | 120 | | Server | 121 | +--------+ 122 +------------|-------------+ 123 | | | 124 | (BR) | 125 | / \ | 126 | / \ | 127 | / \ | 128 | (N1) (N2) | 129 | / : / \ | 130 | / : / \ | 131 | / : / \ | 132 | (N8) (N3) (N4) | 133 | : / \ : | 134 | : / \ : | 135 | : / \ : | 136 | (N5) (New) | 137 | / \ | 138 | / \ | 139 | / \ | 140 | (N6) (N7) | 141 | | 142 | 6Lo Network | 143 +--------------------------+ 145 Figure 1: Sample Topology 147 1.1. Requirements Language and Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in RFC 2119 [RFC2119]. 153 PaC (PANA Client): New joining node which is yet to be authenticated. 155 PRE (PANA Relay Element): An already authenticated and network joined 156 node which is willing to act as a relay element for PaCs to complete 157 their authentication procedure on multi-hop networks. [RFC6345] 158 describes the details of PRE. 160 PAA (PANA Auth Agent): Auth server which hosts the credentials 161 database. PaC will handshake with PAA to complete authentication 162 procedure. 164 Routing Child: A downstream node who is part of the routing table of 165 the parent. For e.g. in the sample topology above N5 is the directly 166 connected routing child for N3. N6 and N7 are also part of N3 167 routing table, they are routing child nodes but not directly 168 connected. For N6 and N7 the document might alternatively use a term 169 grand-child. 171 Routing Parent: In Figure 1, N1 and N2 are possible routing parents 172 for N3. 174 Neighbor Cache Entry (NCE): A neighbor entry managed on behalf of 175 directly connected peer. 177 This document also uses terminology described in [RFC6550] and 178 [RFC6775]. 180 2. Neighbor Management 182 2.1. Significance of Neighbor management policy 184 Multihop mesh networks present unique challenges to neighbor 185 management especially with resource constrained nodes. In cases 186 where the node density is higher that the neighbor cache size, the 187 entries have to be prioritized. [Woo_et_al] and [Dawans_et_al] talk 188 about prioritization of neighbor entries by using link quality 189 estimation techniques. But prioritization alone may not necessarily 190 be optimal in all cases. The reason or function why neighbor entry 191 was added also needs to be taken in consideration. For example, 192 evicting a routing direct child might have a ripple effect in turn 193 impacting all the sub-childs as well. 195 In case of key management protocols deployed above MAC layer in 196 multihop network, the neighbor management kicks in early even before 197 the routing adjacencies are established. Since a new joining node 198 needs to discover/attach to a relay element for completing its 199 authentication procedure, the neighbor cache entries have to be 200 appropriately populated both on a PaC and on the PRE. If a neighbor 201 entry whose authentication is in progress is evicted, it will 202 negatively impact the authentication procedure. 204 Another important consideration is that with increased node density, 205 the prioritization based on link estimation parameters might not help 206 since there might be more well connected peers. In dense deployments 207 the number of directly attached neighbors with good quality links 208 might still be higher than the max entries in neighbor cache size. 210 2.2. Trivial neighbor management policies 212 This section investigates policies which are used by most of the 213 current operating systems for constrained nodes. While such policies 214 are trivial to implement they may not be able to deal with the 215 constrained network scenario. Note that such policies can still be 216 used if it is known apriori that the neighbor cache can hold entries 217 for maximum node density. 219 a. First Come First Serve (FCFS) policy 221 b. Least Recently Used (LRU) policy 223 The primary distinction between these policies is how it treats a new 224 entry when the neighbor cache is full. In case of FCFS policy, the 225 new entry is simply rejected while with LRU, the new entry replaces 226 the least recently used entry. 228 RPL works by initiating a downstream multicast DIO to establish 229 upstream network path. Subsequently DAO messages might be sent by 230 the nodes to establish downstream paths to the nodes. Thus the 231 network is flooded with multicast DIO messages initially and 232 similarly there are chances that the same node is ended up been 233 selected as a preferred parent by most of the child nodes and thus 234 receives a DAO message from all these child nodes. Note that once a 235 node establishes a parent entry or a routing entry on behalf of a 236 directly connected node then it has to also provision a neighbor 237 cache entry for it for subsequent unicast traffic. 239 In case of FCFS policy, a node might end up hosting all the neighbor 240 entries based on DIO or DAO messages. Once the cache is full all the 241 subsequent attempts to add an NCE will fail. 243 In case of LRU policy, a node might end up churning lot of neighbor 244 entries because once the cache gets full and there is a request for 245 new entry, it would result in evicting the least recently used (but 246 active) entry. If at later point of time, there is a traffic for the 247 evicted entry then the old entry has to be reinstated using IPv6 NDP 248 procedure. This would mean reinstating the entry by evicting another 249 least recently used entry. If the node density is very high, then 250 this churn would be substantially high to extent that it would 251 disrupt any routing adjacencies to be established in the network in a 252 stable way. 254 2.3. Lifecycle of a NCE 256 2.3.1. NCE Insertion 258 IPv6 NDP [RFC6775] defines signaling involved in resolving the IPv6 259 addresses to its corresponding MAC addresses which gets populated in 260 the neighbor cache. In case of constrained network, it is desired 261 that such control traffic is minimized and thus the neighbor cache 262 entries are populated as part of existing messaging. One example 263 would be when the node receives a DAO message from its immediate 264 child node, it not only makes an addition to the routing table but 265 also creates a neighbor cache entry for the node. Thus it eliminates 266 need for additional IPv6 NDP NS/NA messaging involved to resolve MAC 267 address. Similar hueristic is used to add neighbor entries in other 268 cases as well. Section 10.3.2 of [RFC6775] describes update and 269 addition of such NCEs based on roting information packets. 271 Following are the possible signaling scenarios in which case a 272 neighbor entry may get added. 274 Node Joining procedure: A new joinee node discovers a relay element 275 to initiate its auth procedure. At the end of the discovery phase 276 the new joinee node would have known the link local IP address of the 277 relay element. The joinee node will send an unsecured-NS to the 278 relay element to solicit its NA. The PRE may send a NA with the 279 suitable status code as defined in section 6.5.3 of [RFC6775]. 281 RPL 282 New PRE Parent PAA 283 | | | | 284 | PRE Disc | | | 285 |<----------->| | | 286 | | | | 287 | UNSEC-NS | | | 288 |------------>| | | 289 | | | | 290 | addNCE(new,reason=PANA)| | 291 | | | | 292 | UNSEC-NA(status) | | 293 |<------------| | | 294 | | | | 295 addNCE(PRE,reason=PANA) | | 296 | | | | 297 | PCI | | | 298 |------------>| | | 299 | | | | 300 | | AUTHPROC | | 301 |<----------->|<----------------------->| 302 | | | | 304 Figure 2: NCE creation between PaC and PRE during relay discovery 305 process 307 Relay element does not hold any state information on behalf of the 308 new joinee node except for its neighbor cache entry. Thus in the 309 Figure 1 the new joinee node may select node N3 as its PRE, in which 310 case N3 has to add a neighbor entry on behalf of the new joinee node. 312 Post authentication the node enters into network discovery phase. 313 The node selects one or more of its neighboring peer as its preferred 314 parent based on the DIO received from these peers. Note that the 315 node's selected relay element and its preferred parent may not be 316 same. The preferred parent serves as a default router node to which 317 all its upstream traffic is directed. Thus an NCE on behalf of 318 preferred parent needs to be added. In Figure 1 node N5 selects N3 319 as its preferred parent. N5 needs to add neighbor entry on behalf of 320 N3 which is its directly connected RPL preferred parent. 322 In case of RPL storing MOP (mode of operation), the node may send a 323 DAO message containing its reachability information to its preferred 324 parent. The parent node in turn may pass this information upstream 325 to its parent by generating a DAO retaining the child node's 326 reachability information, establishing a downstream routing path 327 towards the node who originated the DAO. The preferred parent has to 328 maintain a neighbor entry on behalf of the directly connected child 329 node. For example, in the Figure 1, node N3 needs to maintain a 330 neighbor entry on behalf of N5 which is its directly connected child 331 node. Nodes N6 and N7 are grand-child nodes for node N3 for whom no 332 neighbor entry is required. 334 As mentioned in Section 10.3.2 of [RFC6775], the NCEs on parent and 335 child can be added directly as a result of RPL DIO/DAO signalling 336 without any explicit NS/NA messaging. 338 RPL 339 New PRE Parent PAA 340 | | | | 341 | | AuthProc | | 342 |<----------->|<----------------------->| 343 | | | | 344 | | RPL-DIO | | 345 |<-------------------------| | 346 | | | | 347 addNCE(parent,reason=PARENT) | | 348 | | | | 349 | | RPL-DAO | | 350 |------------------------->| | 351 | | | | 352 | | addNCE(new,reason=CHILD) 353 | | | | 355 Figure 3: NCE creation call Flow for RPL storing MOP 357 In case of non-storing MOP, the parent node needs to know the global 358 IPv6 address of the immediate child nodes. This is needed since the 359 source routing header carries the global addresses and thus the NCE 360 of the child node should contain the global address. Secondly, the 361 RPL DAO is addressed directly to the root node in case of non-storing 362 mode. Thus RPL messaging cannot be used for creating NCE entries on 363 parent and child, unlike storing MOP. The child node may send a 364 secure unicast NS with ARO option containing its global address to be 365 registered on the parent node. The child node can still use RPL DIO 366 to create an NCE on behalf of the parent node. 368 RPL 369 New PRE Parent Root 370 | | | | 371 | | AuthProc | | 372 |<----------->|<----------------------->| 373 | | | | 374 | | RPL-DIO | | 375 |<-------------------------| | 376 | | | | 377 addNCE(parent,reason=PARENT) | | 378 | | | | 379 | sec-NS(ARO=GlobalIPv6) | | 380 |------------------------->| | 381 | | | | 382 | | addNCE(new,reason=CHILD) 383 | sec-NA(status) | | 384 |<-------------------------| | 385 | | | | 386 | | RPL-DAO | | 387 |-------------------------------------->| 388 | | | | 390 Figure 4: NCE creation call Flow for non-storing MOP 392 This document expects the neighbor management policy to remember the 393 reason why the neighbor entry is inserted. Secondly, the router may 394 remember whether the NS received was secured or unsecured and 395 accordingly use it to prioritize eviction entries. As described in 396 the next sections, this reason will help the policy to prioritize the 397 entries in case an eviction is required. 399 2.3.2. NCE Deletion 401 It is imperative that an unwanted neighbor entry be removed as soon 402 as possible. This section talks about different cases in which 403 neighbor entry can be deleted. 405 Route Invalidation: In case of storing MOP, when the child node 406 decides to switch its preferred parent, the RPL specifications allows 407 the node to send a no-path DAO message to invalidate the route along 408 the previous path(s). A directly connected parent node can use this 409 message to clear the NCE. While the entry can be immediately 410 cleared, usually the implementations choose to wait a small amount of 411 time before clearing the entry. This is to avoid any impact on the 412 in-transit traffic. Thus this also establishes the importance of 413 route invalidation to achieve optimized neighbor cache utilization. 415 In case of non-storing mode, the no-path DAO cannot be not employed 416 since the previous parent does not having any routing information to 417 be invalidated. But the previous parent may still contain the NCE on 418 behalf of the child node. This document recommends use of [RFC6775] 419 section 6.5.3. which allows sending a zero lifetime ARO option in NS 420 for deregistering the corresponding neighbor entry. 422 [RFC6775], ND optimizations for 6LoWPANs, section 5.5.3. talks about 423 deleting the entries in case the NUD (neighbor unreachability 424 detection) fails either due to no response to NS messages or due to 425 failure response. NCEs in such cases should be deleted. An example 426 where NUD NS would fail because of no response is the case where the 427 child node switches its parent due to link unavailability. The 428 parent in such a case would not receive the no-path DAO message or 429 any other traffic from the child node. Thus on NCE lifetime expiry, 430 the parent node would send NS which would fail with no response, thus 431 triggering entry deletion. 433 2.3.3. NCE Eviction 435 The eviction rules have a major impact on the neighbor management 436 policy. Eviction rules are used when the policy has to forcibly 437 remove an active neighbor entry from the cache to make space for the 438 new (hopefully higher priority) entry. The eviction policy may take 439 into account several considerations such as the reason why the entry 440 was made, is the entry in active use currently, how good (for e.g., 441 based on link estimation) the entry currently is. 443 2.3.3.1. Eviction for directly connected routing entries 445 This section talks about implications of an eviction in which a 446 parent node decides of evicting a directly connected routing child 447 NCE. In the sample topology Figure 1, lets assume N3 needs to evict 448 N5 from its neighbor cache. In case of RPL's storing MOP, eviction 449 of directly connected routing child NCE also has impact on all the 450 sub-children. Thus not only will it result in impacting N5 but also 451 nodes N6 and N7. It is important to note that such an eviction has 452 less impact on RPL's non-storing MOP i.e. in case of non-storing mode 453 N5 might end up selecting alternate parent N8 and does not result in 454 any additional control overhead for node N6 and N7. 456 Thus RPL's non-storing MOP provides additional eviction flexibility 457 for a neighbor management policy in terms evicting directly connected 458 child entries. 460 2.3.4. NCE Reinforcement 462 It is expected that the latest reachability state and metric 463 information be maintained in context to the NCE. With wireless 464 networks, the neighbor cache entries prioritization may change over a 465 period of time especially the link quality estimation parameters or 466 the routing metrics. Reinforcement refers to updating the parameters 467 in context to the NCEs which helps in prioritizing the entries when 468 it comes to handling eviction. In wireless networks, on reception of 469 incoming packet, the receiver node's physical and MAC layer may 470 derive certain signal reception parameters (such as RSSI, LQI) which 471 can be considered for reinforcement purpose if the corresponding 472 transmitter/source entry in neighbor cache is found. It should be 473 noted that the signal quality parameters may have high variance in 474 6lo networks and thus statistical techniques (such as weighted 475 averaging) are usually employed for deciding about a link quality 476 over a period of time. Reinforcement can be achieved using one or 477 more of the following techniques: 479 Passive Monitoring: Reinforcing the quality parameters using packets 480 received from the source. Trickled DIO, periodic beacons, 481 application traffic etc can be used for such monitoring. 483 Active Probing: A node may select subset of entries for active 484 probing wherein it sends a message to the neighbor entry's target 485 and can expect a response message back. An example of such 486 probing is [CONTIKI] where unicast DIS is sent to solicit a 487 unicast DIO without impacting the trickle timers. Though it adds 488 a control overhead on the link, periodic probing can help to 489 ascertain connectivity in the absence of any other traffic from 490 the neighboring node. 492 2.4. Requirements of a good neighbor management policy 494 Route Stability: Stable NCEs will result in stable routing 495 adjacencies. Thus it is important to avoid unnecessary NCE churn 496 for routing path stability. 498 Control overhead: A neighbor management policy may have to use 499 signalling messages for policy handling (such as rejection of 500 NCE). It is required that such overhead be kept as low as 501 possible. 503 Scalability: Scalability with respect to large and uneven node 504 densities in the network. 506 2.5. Approaches to neighbor management policy 508 Neighbor management policy depends upon the neighbor cache space 509 availability and the same can be advertised proactively or can be 510 handled reactively. 512 2.5.1. Reactive Approach 514 In this approach, the nodes select their RPL parent or the relay 515 element purely based on link metrics and subsequently when they try 516 to allocate their NCE in the target node, it may fail due to 517 unavailability of the cache space. The failure can be communicated 518 depending upon the signaling involved: 520 NS failure: Section 6.5.3 of [RFC6775] defines a procedure for NS 521 failure handling in case the router's neighbor cache is full. It 522 results in a unicast NA with ARO status field set to two. 524 DAO NACK: Section 9.3 of RPL [RFC6550] specifies on how can the 525 parent node react to DAOs from child. In case the parent could 526 not make a NCE on behalf of the child node, a negative ACK with 527 status (between 127-255) should be sent to the child node. The 528 natural reaction of the child node would be to switch to an 529 alternate parent. 531 PANA Failure: PaC's auth session starts with a PaC discovering a 532 PRE. The discovery procedure is not standardized and can be based 533 upon various factors including signal strength of discovery 534 messages from PRE. Post discovery, the PaC needs to send an 535 unsecured unicast NS message with an ARO containings its link- 536 local IPv6 address. NS helps to determine whether the PRE can 537 allocate an NCE for the PaC. PRE accordingly sends a NA response 538 with appropriate status field. 540 2.5.2. Proactive Approach 542 Neighbor cache availability could be proactively advertised by the 543 parent nodes in the DIO messages and in the PRE discovery messages. 544 A child RPL node may additionally use this information from DIO as 545 part of parent selection process. In case of new joinee node, the 546 node may use PRE discovery messages with space availability 547 information to select an appropriate PRE. Proactive signaling of 548 neighbor cache space availability will help the nodes to select the 549 parent node or relay node such that the failure signaling due to 550 cache full event can be reduced. 552 Currently there is no standard way of signaling such neighbor cache 553 space availability information. RPL's DIO messages carry metric 554 information and can be augmented with neighbor cache space as an 555 additional metric. In case of PRE discovery however there is no 556 standard way of defining this information since the PRE discovery 557 procedure itself is not standardized. 559 In a wireless or shared bus network, a multicast DIO metric 560 advertisement may reach several child nodes eventually everyone 561 responding by selecting the same parent node causing neighbor cache 562 to be exhausted. Thus the failure handling approaches defined in the 563 Reactive Approach section applies here as well. But importantly the 564 failure signaling will be significantly reduced because of proactive 565 advertisement. 567 3. Reservation based Neighbor Management Policy 569 This section defines a sample neighbor management policy, with the 570 primary objective to reduce NCE churn and to ensure stability of 571 routing adjacencies. The scheme uses a reservation based policy to 572 reserve NCEs for: 574 +-----------------------------+----------------------------+--------+ 575 | NCE Entry for | MAX count | Reason | 576 +-----------------------------+----------------------------+--------+ 577 | Routing Parent | MAX_ROUTING_PARENT_NCE_NUM | PARENT | 578 | | | | 579 | Routing child | MAX_ROUTING_CHILD_NCE_NUM | CHILD | 580 | | | | 581 | Others such as pre-auth | MAX_OTHER_NCE_NUM | OTHER | 582 | sessions | | | 583 +-----------------------------+----------------------------+--------+ 585 Table 1: Neighbor Cache Entry reservation 587 Note that reservation policy depends upon identification of the 588 reason behind making an NCE . In case of pre-auth sessions, the 589 corresponding NCE is created based on the unsecured NS/NA. In case 590 of storing MOP, CHILD_ENT NCEs are created either based on DAO (as 591 shown in Figure 3) or based on secured NS/NA messaging (as shown in 592 Figure 4). In case of non-storing MOP, a secured NS/NA messaging as 593 shown in Figure 4 needs to be used. 595 <- - - - - - - - - - - Routing Parents - - - - - - - - - - - - -> 596 +---------------------------------------------------------------+ 597 | | | | 598 +-----------------------------------------------------+---------+ 599 Routing Child Routing Parents Other 601 Figure 5: Reservation of NCEs in neighbor table 603 As shown in the figure, the neighbor cache is partitioned into 604 different entry types. The routing parents can possibly occupy any 605 entry type if found vacant since in case an eviction is sought the 606 non-preferred routing parent could be evicted without much impact on 607 the functioning or on the control traffic. The eviction could be 608 done based on reasons specified in Section 2.3.3. 610 Routing Child entries are made in context to directly connected peers 611 and these entries are not deleted unless they are unreacable or there 612 is any reason for the parent node to believe that it is no longer the 613 preferred parent for the child node. Deletion may happen based on 614 reasons mentioned in Section 2.3.2. 616 Other entries (OTHER) may be made in response to temporary 617 requirement of making an NCE. One such case is the pre 618 authentication phase where in the relay node makes an entry of the 619 PaC temporarily till the time the authentication phase is completed. 620 The NCE made thus is garbage collected at the end of the lifetime. 621 Also an implementation may choose to keep a lower lifetime for such 622 NCEs depending upon the time taken to complete the authentication 623 process. 625 3.1. Limitations of such a policy 627 The reservation based policy mentioned in this section may result in 628 sub-optimal path selection due to lack of NCE resource on the parent 629 nodes. Also the restriction of maximum pre-auth sessions in the form 630 of MAX_OTHER_NCE_NUM limits the maximum relay sessions that can be 631 supported on the relay node. 633 The reservation policy allows the parent node to reject the child 634 node's DAO or NS. But the child node cannot remember this rejection 635 and may reattempt the same parent after some time depending upon 636 triggers such as reception of DIO from the same parent who rejected 637 it previously. One of the only way to stop the child node from 638 reattempting such parent selection would be to also include a 639 proactive approach wherein the parent node signals its resource 640 availability in the DIO message as mentioned in Section 2.5.2. Such 641 a scheme of signalling parent node's resource availability is 642 currently not standardized. 644 RPL's storing MOP imposes additional restrictions. One such case is 645 where a child node may have a given parent node as its only parent 646 and that parent node's NCE are all used up. In such a case, the 647 child node would keep on retrying and failing to send a DAO through 648 the parent node. Ideally the parent node could have evicted a least 649 used child node or a child node who has an alternate parent 650 available. Evicting such a child node is a complex process and may 651 increase the control overhead as described in Section 2.3.3.1. Thus 652 the reservation based policy requires that the minimum node density 653 is sufficiently high so that every child finds a parent node in its 654 vicinity with enough resources. 656 4. Acknowledgements 658 Thanks to Malisa Vucinic for pointing towards security aspects of un- 659 authenticated nodes neighbor cache management. 661 5. IANA Considerations 663 This memo includes no request to IANA. 665 6. Security Considerations 667 The Join Relay or the PANA Relay Element allows the un-authenticated 668 nodes to join the network. Since the NS/NA signaling is unencrypted, 669 it is possible that a malicious node may try spoof and occupy all the 670 entries. This draft explains the use of reservation based policy for 671 managing such entries. Following points try to reduce the impact of 672 such attacks: Only a subset of entries are reserved for un- 673 authenticated nodes. 675 a. Only a subset of entries are reserved for un-authenticated nodes 676 doing plain-text NS/NA 678 b. It is recommended that NCE timeout be configured a lower value to 679 evict such entries as soon as possible. New joining nodes are 680 supposed to use these entries and thus are only needed during the 681 time the authentication is in progress. Thus a short-duration 682 NCE timeout will help reduce the impact of DoS attacks. 684 7. References 686 7.1. Normative References 688 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 689 Requirement Levels", BCP 14, RFC 2119, 690 DOI 10.17487/RFC2119, March 1997, 691 . 693 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 694 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 695 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 696 Low-Power and Lossy Networks", RFC 6550, 697 DOI 10.17487/RFC6550, March 2012, 698 . 700 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 701 Bormann, "Neighbor Discovery Optimization for IPv6 over 702 Low-Power Wireless Personal Area Networks (6LoWPANs)", 703 RFC 6775, DOI 10.17487/RFC6775, November 2012, 704 . 706 7.2. Informative References 708 [CONTIKI] Thingsquare, "Contiki: The Open Source OS for IoT", 2012, 709 . 711 [Dawans_et_al] 712 Dawans, S., Duquennoy, S., and O. Bonaventure, "On Link 713 Estimation in Dense RPL Deployments", 2012. 715 [I-D.ietf-6tisch-architecture] 716 Thubert, P., "An Architecture for IPv6 over the TSCH mode 717 of IEEE 802.15.4", draft-ietf-6tisch-architecture-13 (work 718 in progress), November 2017. 720 [I-D.ietf-6tisch-minimal-security] 721 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 722 "Minimal Security Framework for 6TiSCH", draft-ietf- 723 6tisch-minimal-security-04 (work in progress), October 724 2017. 726 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 727 and A. Yegin, "Protocol for Carrying Authentication for 728 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 729 May 2008, . 731 [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., Ed., and 732 A. Yegin, "Protocol for Carrying Authentication for 733 Network Access (PANA) Relay Element", RFC 6345, 734 DOI 10.17487/RFC6345, August 2011, 735 . 737 [Woo_et_al] 738 Woo, A., Tong, T., and D. Culler, "Taming the Underlying 739 Challenges of Reliable Multihop Routing in Sensor 740 Networks", 2003. 742 Authors' Addresses 743 Rahul Arvind Jadhav (editor) 744 Huawei 745 Kundalahalli Village, Whitefield, 746 Bangalore, Karnataka 560037 747 India 749 Phone: +91-080-49160700 750 Email: rahul.ietf@gmail.com 752 Rabi Narayan Sahoo 753 Huawei 754 Kundalahalli Village, Whitefield, 755 Bangalore, Karnataka 560037 756 India 758 Phone: +91-080-49160700 759 Email: rabinarayans@huawei.com 761 Simon Duquennoy 762 Inria 763 40 Avenue Halley 764 Building A 765 Villeneuve d'Ascq 766 France 768 Phone: +33 768227731 769 Email: simon.duquennoy@inria.fr 771 Joakim Eriksson 772 Yanzi Networks 774 Email: joakime@sics.se