idnits 2.17.1 draft-ietf-lwig-nbr-mgmt-policy-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 21, 2019) is 1891 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'REF' is mentioned on line 165, but not defined == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-19 == Outdated reference: A later version (-15) exists of draft-ietf-6tisch-minimal-security-09 == Outdated reference: A later version (-18) exists of draft-ietf-roll-efficient-npdao-09 == Outdated reference: A later version (-03) exists of draft-richardson-6tisch-roll-enrollment-priority-02 Summary: 0 errors (**), 0 flaws (~~), 6 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 25, 2019 S. Duquennoy 6 Inria 7 J. Eriksson 8 Yanzi Networks 9 February 21, 2019 11 Neighbor Management Policy for 6LoWPAN 12 draft-ietf-lwig-nbr-mgmt-policy-03 14 Abstract 16 This document describes the problems associated with neighbor cache 17 management in multihop networks involving resource-constrained 18 devices. Thereafter, it also presents a sample neighbor management 19 policy that allows efficient cache management in multihop LLNs (low- 20 power and lossy networks such as LoWPAN) with resource-constrained 21 devices. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 25, 2019. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Requirements Language and Terminology . . . . . . . . . . 4 59 2. Neighbor Management . . . . . . . . . . . . . . . . . . . . . 5 60 2.1. Significance of Neighbor management policy . . . . . . . 5 61 2.2. Trivial neighbor management policies . . . . . . . . . . 6 62 2.3. Lifecycle of a NCE . . . . . . . . . . . . . . . . . . . 7 63 2.3.1. NCE Insertion . . . . . . . . . . . . . . . . . . . . 7 64 2.3.2. NCE Deletion . . . . . . . . . . . . . . . . . . . . 10 65 2.3.3. NCE Eviction . . . . . . . . . . . . . . . . . . . . 11 66 2.3.3.1. Eviction for directly connected routing entries . 11 67 2.3.4. NCE Reinforcement . . . . . . . . . . . . . . . . . . 12 68 2.4. Requirements of a good neighbor management policy . . . . 12 69 2.5. Approaches to neighbor management policy . . . . . . . . 13 70 2.5.1. Reactive Approach . . . . . . . . . . . . . . . . . . 13 71 2.5.2. Proactive Approach . . . . . . . . . . . . . . . . . 13 72 3. Reservation based Neighbor Management Policy . . . . . . . . 14 73 3.1. Limitations of such a policy . . . . . . . . . . . . . . 16 74 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 79 7.2. Informative References . . . . . . . . . . . . . . . . . 18 80 Appendix A. Performance Result . . . . . . . . . . . . . . . . . 19 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 83 1. Introduction 85 In a wireless multihop LLN, the node densities (maximum nodes 86 reachable on the same hop) may vary significantly depending upon 87 deployments and scenarios. Examples of such networks is LoWPAN [REF] 88 networks. While there is some policy control possible with regards 89 to the network size in terms of maximum number of devices connected, 90 it is especially difficult to set a figure on what will be the 91 maximum node density given a deployment. For e.g. A network can put 92 an upper limit on max 1000 devices but it is impossible to state what 93 the node density will be in this 1000 node network. 95 A neighbor cache is used for populating neighboring one-hop connected 96 nodes information such as MAC address, link local IP address and 97 other reachability state information. Node density has direct 98 implications on the neighbor cache and in constrained network 99 scenario the size of the neighbor cache will be limited. Thus there 100 are chances that a node may not be able to fit all the neighboring 101 nodes in its cache in which case it has to prioritize entries and 102 thus needs a neighbor management policy. 104 This draft presents problems related to neighbor management policies 105 by considering a security-enabled multi-hop 6lo network. This 106 document considers RPL [RFC6550] as a routing protocol and PANA (EAP- 107 PANA) [RFC5191] as a network access protocol. For RPL, both the 108 storing and non-storing mode of operations are considered. We also 109 provide a sample neighbor management policy which can be used in such 110 networks and its limitations. The aim of such a policy is to retain 111 set of neighbor cache entries with high quality links such that 112 routing adjacencies are stablized. 114 The problem statement and the proposed solution described is also 115 relevant to other multihop constrained scenarios such as 6TiSCH 116 [I-D.ietf-6tisch-architecture]. [I-D.ietf-6tisch-minimal-security] 117 talks about a pledge (new joinee) node authenticating via a Join 118 Proxy. The considerations mentioned in this document are applicable 119 for such networks as well. 121 +--------+ 122 | PAA/ | 123 +------| Auth | 124 | | Server | 125 | +--------+ 126 +------------|-------------+ 127 | | | 128 | (BR) | 129 | / \ | 130 | / \ | 131 | / \ | 132 | (N1) (N2) | 133 | / : / \ | 134 | / : / \ | 135 | / : / \ | 136 | (N8) (N3) (N4) | 137 | : / \ : | 138 | : / \ : | 139 | : / \ : | 140 | (N5) (New) | 141 | / \ | 142 | / \ | 143 | / \ | 144 | (N6) (N7) | 145 | | 146 | 6Lo Network | 147 +--------------------------+ 149 Figure 1: Sample Topology 151 1.1. Requirements Language and Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in RFC 2119 [RFC2119]. 157 NDP: Neighbor Discovery protocol [REF] 159 NS: Neighbor Solicitation 161 NA: Neighbor Advertisement 163 LLN: Low Power and Lossy Networks 165 RPL: Routing Protocol for LLNs [REF] 167 DAO: DODAG Advertisement Object 168 DIO: DODAG Information Object 170 ARO: Address Registration Option defined as part of IPv6 NDP 172 PaC (PANA Client): New joining node which is yet to be authenticated. 174 PRE (PANA Relay Element): An already authenticated and network joined 175 node which is willing to act as a relay element for PaCs to complete 176 their authentication procedure on multi-hop networks. [RFC6345] 177 describes the details of PRE. 179 PAA (PANA Auth Agent): Auth server which hosts the credentials 180 database. PaC will handshake with PAA to complete authentication 181 procedure. 183 PCI: PANA Client Initiation is the first message sent by the PaC 184 which initiates the authentication procedure 186 Routing Child: A downstream node who is part of the routing table of 187 the parent. For e.g. in the sample topology above N5 is the directly 188 connected routing child for N3. N6 and N7 are also part of N3 189 routing table, they are routing child nodes but not directly 190 connected. For N6 and N7 the document might alternatively use a term 191 grand-child. 193 Routing Parent: In Figure 1, N1 and N2 are possible routing parents 194 for N3. 196 Neighbor Cache Entry (NCE): A neighbor entry managed on behalf of 197 directly connected peer. 199 This document also uses terminology described in [RFC6550] and 200 [RFC6775]. 202 2. Neighbor Management 204 2.1. Significance of Neighbor management policy 206 Multihop mesh networks present unique challenges to neighbor 207 management especially with resource constrained nodes. In cases 208 where the node density is higher that the neighbor cache size, the 209 entries have to be prioritized. [Woo_et_al] and [Dawans_et_al] talk 210 about prioritization of neighbor entries by using link quality 211 estimation techniques. But prioritization alone may not necessarily 212 be optimal in all cases. The reason or function why neighbor entry 213 was added also needs to be taken in consideration. For example, 214 evicting a routing direct child might have a ripple effect in turn 215 impacting all the sub-childs as well. 217 In case of key management protocols deployed above MAC layer in 218 multihop network, the neighbor management kicks in early even before 219 the routing adjacencies are established. Since a new joining node 220 needs to discover/attach to a relay element for completing its 221 authentication procedure, the neighbor cache entries have to be 222 appropriately populated both on a PaC and on the PRE. If a neighbor 223 entry whose authentication is in progress is evicted, it will 224 negatively impact the authentication procedure. 226 Another important consideration is that with increased node density, 227 the prioritization based on link estimation parameters might not help 228 since there might be more well connected peers. In dense deployments 229 the number of directly attached neighbors with good quality links 230 might still be higher than the max entries in neighbor cache size. 232 2.2. Trivial neighbor management policies 234 This section investigates policies which are used by most of the 235 current operating systems for constrained nodes. While such policies 236 are trivial to implement they may not be able to deal with the 237 constrained network scenario. Note that such policies can still be 238 used if it is known apriori that the neighbor cache can hold entries 239 for maximum node density. 241 a. First Come First Serve (FCFS) policy 243 b. Least Recently Used (LRU) policy 245 The primary distinction between these policies is how it treats a new 246 entry when the neighbor cache is full. In case of FCFS policy, the 247 new entry is simply rejected while with LRU, the new entry replaces 248 the least recently used entry. 250 RPL works by initiating a downstream multicast DIO to establish 251 upstream network path. Subsequently DAO messages might be sent by 252 the nodes to establish downstream paths to the nodes. Thus the 253 network is flooded with multicast DIO messages initially and 254 similarly there are chances that the same node is ended up been 255 selected as a preferred parent by most of the child nodes and thus 256 receives a DAO message from all these child nodes. Note that once a 257 node establishes a parent entry or a routing entry on behalf of a 258 directly connected node then it has to also provision a neighbor 259 cache entry for it for subsequent unicast traffic. 261 In case of FCFS policy, a node might end up hosting all the neighbor 262 entries based on DIO or DAO messages. Once the cache is full all the 263 subsequent attempts to add an NCE will fail. 265 In case of LRU policy, a node might end up churning lot of neighbor 266 entries because once the cache gets full and there is a request for 267 new entry, it would result in evicting the least recently used (but 268 active) entry. If at later point of time, there is a traffic for the 269 evicted entry then the old entry has to be reinstated using IPv6 NDP 270 procedure. This would mean reinstating the entry by evicting another 271 least recently used entry. If the node density is very high, then 272 this churn would be substantially high to extent that it would 273 disrupt any routing adjacencies to be established in the network in a 274 stable way. 276 2.3. Lifecycle of a NCE 278 2.3.1. NCE Insertion 280 IPv6 NDP [RFC6775] defines signaling involved in resolving the IPv6 281 addresses to its corresponding MAC addresses which gets populated in 282 the neighbor cache. In case of constrained network, it is desired 283 that such control traffic is minimized and thus the neighbor cache 284 entries are populated as part of existing messaging. One example 285 would be when the node receives a DAO message from its immediate 286 child node, it not only makes an addition to the routing table but 287 also creates a neighbor cache entry for the node. Thus it eliminates 288 need for additional IPv6 NDP NS/NA messaging involved to resolve MAC 289 address. Similar hueristic is used to add neighbor entries in other 290 cases as well. Section 10.3.2 of [RFC6775] describes update and 291 addition of such NCEs based on roting information packets. 293 Following are the possible signaling scenarios in which case a 294 neighbor entry may get added. 296 Node Joining procedure: A new joinee node discovers a relay element 297 to initiate its auth procedure. At the end of the discovery phase 298 the new joinee node would have known the link local IP address of the 299 relay element. The joinee node will send an unsecured-NS to the 300 relay element to solicit its NA. The PRE may send a NA with the 301 suitable status code as defined in section 6.5.3 of [RFC6775]. 303 RPL 304 PaC PRE Parent PAA 305 | | | | 306 | PRE Disc | | | 307 |<----------->| | | 308 | | | | 309 | UNSEC-NS | | | 310 |------------>| | | 311 | | | | 312 | addNCE(new,reason=PANA)| | 313 | | | | 314 | UNSEC-NA(status) | | 315 |<------------| | | 316 | | | | 317 addNCE(PRE,reason=PANA) | | 318 | | | | 319 | PCI | | | 320 |------------>| | | 321 | | | | 322 | | AUTHPROC | | 323 |<===========>|<=======================>| 324 | | | | 326 Figure 2: NCE creation between PaC and PRE during relay discovery 327 process 329 Relay element does not hold any state information on behalf of the 330 new joinee node except for its neighbor cache entry. Thus in the 331 Figure 1 the new joinee node may select node N3 as its PRE, in which 332 case N3 has to add a neighbor entry on behalf of the new joinee node. 334 Post authentication the node enters into network discovery phase. 335 The node selects one or more of its neighboring peer as its preferred 336 parent based on the DIO received from these peers. Note that the 337 node's selected relay element and its preferred parent may not be 338 same. The preferred parent serves as a default router node to which 339 all its upstream traffic is directed. Thus an NCE on behalf of 340 preferred parent needs to be added. In Figure 1 node N5 selects N3 341 as its preferred parent. N5 needs to add neighbor entry on behalf of 342 N3 which is its directly connected RPL preferred parent. 344 In case of RPL storing MOP (mode of operation), the node may send a 345 DAO message containing its reachability information to its preferred 346 parent. The parent node in turn may pass this information upstream 347 to its parent by generating a DAO retaining the child node's 348 reachability information, establishing a downstream routing path 349 towards the node who originated the DAO. The preferred parent has to 350 maintain a neighbor entry on behalf of the directly connected child 351 node. For example, in the Figure 1, node N3 needs to maintain a 352 neighbor entry on behalf of N5 which is its directly connected child 353 node. Nodes N6 and N7 are grand-child nodes for node N3 for whom no 354 neighbor entry is required. 356 As mentioned in Section 10.3.2 of [RFC6775], the NCEs on parent and 357 child can be added directly as a result of RPL DIO/DAO signalling 358 without any explicit NS/NA messaging. 360 RPL 361 PaC PRE Parent PAA 362 | | | | 363 | | AuthProc | | 364 |<----------->|<----------------------->| 365 | | | | 366 | | RPL-DIO | | 367 |<-------------------------| | 368 | | | | 369 addNCE(parent,reason=PARENT) | | 370 | | | | 371 | | RPL-DAO | | 372 |------------------------->| | 373 | | | | 374 | | addNCE(new,reason=CHILD) 375 | | | | 377 Figure 3: NCE creation call Flow for RPL storing MOP 379 In case of non-storing MOP, the parent node needs to know the global 380 IPv6 address of the immediate child nodes. This is needed since the 381 source routing header carries the global addresses and thus the NCE 382 of the child node should contain the global address. Secondly, the 383 RPL DAO is addressed directly to the root node in case of non-storing 384 mode. Thus RPL messaging cannot be used for creating NCE entries on 385 parent and child, unlike storing MOP. The child node may send a 386 secure unicast NS with ARO option containing its global address to be 387 registered on the parent node. The child node can still use RPL DIO 388 to create an NCE on behalf of the parent node. 390 RPL 391 PaC PRE Parent Root 392 | | | | 393 | | AuthProc | | 394 |<----------->|<----------------------->| 395 | | | | 396 | | RPL-DIO | | 397 |<-------------------------| | 398 | | | | 399 addNCE(parent,reason=PARENT) | | 400 | | | | 401 | sec-NS(ARO=GlobalIPv6) | | 402 |------------------------->| | 403 | | | | 404 | | addNCE(new,reason=CHILD) 405 | sec-NA(status) | | 406 |<-------------------------| | 407 | | | | 408 | | RPL-DAO | | 409 |-------------------------------------->| 410 | | | | 412 Figure 4: NCE creation call Flow for non-storing MOP 414 This document expects the neighbor management policy to remember the 415 reason why the neighbor entry is inserted. Secondly, the router may 416 remember whether the NS received was secured or unsecured and 417 accordingly use it to prioritize eviction entries. As described in 418 the next sections, this reason will help the policy to prioritize the 419 entries in case an eviction is required. 421 2.3.2. NCE Deletion 423 It is imperative that an unwanted neighbor entry be removed as soon 424 as possible. This section talks about different cases in which 425 neighbor entry can be deleted. 427 Route Invalidation: In case of storing MOP, when the child node 428 decides to switch its preferred parent, the RPL specifications allows 429 the node to send a no-path DAO message to invalidate the route along 430 the previous path(s). A directly connected parent node can use this 431 message to clear the NCE. While the entry can be immediately 432 cleared, usually the implementations choose to wait a small amount of 433 time before clearing the entry. This is to avoid any impact on the 434 in-transit traffic. Thus this also establishes the importance of 435 route invalidation to achieve optimized neighbor cache utilization. 437 Efficient neighbor cache management depends upon efficient route 438 invalidation since the neighbor cache entries are associated with 439 routing entries. With regards to RPL, issues with the route 440 invalidation has been highlighted in [I-D.ietf-roll-efficient-npdao]. 441 [I-D.ietf-roll-efficient-npdao] also defines a new mechanism for 442 improved route invalidation in storing MOP which helps optimized 443 cleanup of neighbor cache entries. 445 In case of non-storing mode, the no-path DAO cannot be not employed 446 since the previous parent does not having any routing information to 447 be invalidated. But the previous parent may still contain the NCE on 448 behalf of the child node. This document recommends use of [RFC6775] 449 section 6.5.3. which allows sending a zero lifetime ARO option in NS 450 for deregistering the corresponding neighbor entry. 452 [RFC6775], ND optimizations for 6LoWPANs, section 5.5.3. talks about 453 deleting the entries in case the NUD (neighbor unreachability 454 detection) fails either due to no response to NS messages or due to 455 failure response. NCEs in such cases should be deleted. An example 456 where NUD NS would fail because of no response is the case where the 457 child node switches its parent due to link unavailability. The 458 parent in such a case would not receive the no-path DAO message or 459 any other traffic from the child node. Thus on NCE lifetime expiry, 460 the parent node would send NS which would fail with no response, thus 461 triggering entry deletion. 463 2.3.3. NCE Eviction 465 The eviction rules have a major impact on the neighbor management 466 policy. Eviction rules are used when the policy has to forcibly 467 remove an active neighbor entry from the cache to make space for the 468 new (hopefully higher priority) entry. The eviction policy may take 469 into account several considerations such as the reason why the entry 470 was made, is the entry in active use currently, how good (for e.g., 471 based on link estimation) the entry currently is. 473 2.3.3.1. Eviction for directly connected routing entries 475 This section talks about implications of an eviction in which a 476 parent node decides of evicting a directly connected routing child 477 NCE. In the sample topology Figure 1, lets assume N3 needs to evict 478 N5 from its neighbor cache. In case of RPL's storing MOP, eviction 479 of directly connected routing child NCE also has impact on all the 480 sub-children. Thus not only will it result in impacting N5 but also 481 nodes N6 and N7. It is important to note that such an eviction has 482 less impact on RPL's non-storing MOP i.e. in case of non-storing mode 483 N5 might end up selecting alternate parent N8 and does not result in 484 any additional control overhead for node N6 and N7. 486 Thus RPL's non-storing MOP provides additional eviction flexibility 487 for a neighbor management policy in terms evicting directly connected 488 child entries. 490 2.3.4. NCE Reinforcement 492 It is expected that the latest reachability state and metric 493 information be maintained in context to the NCE. With wireless 494 networks, the neighbor cache entries prioritization may change over a 495 period of time especially the link quality estimation parameters or 496 the routing metrics. Reinforcement refers to updating the parameters 497 in context to the NCEs which helps in prioritizing the entries when 498 it comes to handling eviction. In wireless networks, on reception of 499 incoming packet, the receiver node's physical and MAC layer may 500 derive certain signal reception parameters (such as RSSI, LQI) which 501 can be considered for reinforcement purpose if the corresponding 502 transmitter/source entry in neighbor cache is found. It should be 503 noted that the signal quality parameters may have high variance in 504 6lo networks and thus statistical techniques (such as weighted 505 averaging) are usually employed for deciding about a link quality 506 over a period of time. Reinforcement can be achieved using one or 507 more of the following techniques: 509 Passive Monitoring: Reinforcing the quality parameters using packets 510 received from the source. Trickled DIO, periodic beacons, 511 application traffic etc can be used for such monitoring. 513 Active Probing: A node may select subset of entries for active 514 probing wherein it sends a message to the neighbor entry's target 515 and can expect a response message back. An example of such 516 probing is [CONTIKI] where unicast DIS is sent to solicit a 517 unicast DIO without impacting the trickle timers. Though it adds 518 a control overhead on the link, periodic probing can help to 519 ascertain connectivity in the absence of any other traffic from 520 the neighboring node. 522 2.4. Requirements of a good neighbor management policy 524 Route Stability: Stable NCEs will result in stable routing 525 adjacencies. Thus it is important to avoid unnecessary NCE churn 526 for routing path stability. 528 Control overhead: A neighbor management policy may have to use 529 signalling messages for policy handling (such as rejection of 530 NCE). It is required that such overhead be kept as low as 531 possible. 533 Scalability: Scalability with respect to large and uneven node 534 densities in the network. 536 2.5. Approaches to neighbor management policy 538 Neighbor management policy depends upon the neighbor cache space 539 availability and the same can be advertised proactively or can be 540 handled reactively. 542 2.5.1. Reactive Approach 544 In this approach, the nodes select their RPL parent or the relay 545 element purely based on link metrics and subsequently when they try 546 to allocate their NCE in the target node, it may fail due to 547 unavailability of the cache space. The failure can be communicated 548 depending upon the signaling involved: 550 NS failure: Section 6.5.3 of [RFC6775] defines a procedure for NS 551 failure handling in case the router's neighbor cache is full. It 552 results in a unicast NA with ARO status field set to two. 554 DAO NACK: Section 9.3 of RPL [RFC6550] specifies on how can the 555 parent node react to DAOs from child. In case the parent could 556 not make a NCE on behalf of the child node, a negative ACK with 557 status (between 127-255) should be sent to the child node. The 558 natural reaction of the child node would be to switch to an 559 alternate parent. 561 PANA Failure: PaC's auth session starts with a PaC discovering a 562 PRE. The discovery procedure is not standardized and can be based 563 upon various factors including signal strength of discovery 564 messages from PRE. Post discovery, the PaC needs to send an 565 unsecured unicast NS message with an ARO containings its link- 566 local IPv6 address. NS helps to determine whether the PRE can 567 allocate an NCE for the PaC. PRE accordingly sends a NA response 568 with appropriate status field. 570 2.5.2. Proactive Approach 572 Neighbor cache availability could be proactively advertised by the 573 parent nodes in the DIO messages and in the PRE discovery messages. 574 A child RPL node may additionally use this information from DIO as 575 part of parent selection process. 577 [I-D.richardson-6tisch-roll-enrollment-priority] defines a signalling 578 change in DIO messages to inform child nodes of the priority of the 579 6LR. The priority field signals whether the 6LR is ready and has 580 enough resources to serve new child nodes. If 6LR's neighbor cache 581 gets full it can set the min priority to 0x7f(127) to stop the 582 joining process via it. When a LR or leaf node receives DIO from a 583 parent LR with min priority set to 127 the below actions 585 1. If its not yet joined the DODAG don't choose this LR as preferred 586 parent to join the DODAG. 588 2. If the node is already in the DODAG and this LR is not in the 589 parent list don't add it to parent list. 591 3. If node is already in the DODAG and the LR is in its standby 592 parent list remove the LR from its standby parent list. 594 In case of new joinee node, the node may use PRE discovery messages 595 with space availability information to select an appropriate PRE. 596 Proactive signaling of neighbor cache space availability will help 597 the nodes to select the parent node or relay node such that the 598 failure signaling due to cache full event can be reduced. 600 Currently there is no standard way of signaling such neighbor cache 601 space availability information. RPL's DIO messages carry metric 602 information and can be augmented with neighbor cache space as an 603 additional metric. In case of PRE discovery however there is no 604 standard way of defining this information since the PRE discovery 605 procedure itself is not standardized. 607 In a wireless or shared bus network, a multicast DIO metric 608 advertisement may reach several child nodes eventually everyone 609 responding by selecting the same parent node causing neighbor cache 610 to be exhausted. Thus the failure handling approaches defined in the 611 Reactive Approach section applies here as well. But importantly the 612 failure signaling will be significantly reduced because of proactive 613 advertisement. 615 3. Reservation based Neighbor Management Policy 617 This section defines a sample neighbor management policy, with the 618 primary objective to reduce NCE churn and to ensure stability of 619 routing adjacencies. The scheme uses a reservation based policy to 620 reserve NCEs for: 622 +-----------------------------+----------------------------+--------+ 623 | NCE Entry for | MAX count | Reason | 624 +-----------------------------+----------------------------+--------+ 625 | Routing Parent | MAX_ROUTING_PARENT_NCE_NUM | PARENT | 626 | | | | 627 | Routing child | MAX_ROUTING_CHILD_NCE_NUM | CHILD | 628 | | | | 629 | Others such as pre-auth | MAX_OTHER_NCE_NUM | OTHER | 630 | sessions | | | 631 +-----------------------------+----------------------------+--------+ 633 Table 1: Neighbor Cache Entry reservation 635 Table 1 denotes that the NCEs are reserved dependending upon the 636 reason for its addition. MAX_ROUTING_PARENT_NCE_NUM specifies 637 maximum number of parent entries a node should allow. 638 MAX_ROUTING_CHILD_NCE_NUM specifies maximum number of child entries 639 that are allowed after which the node SHOULD decline the DAO 640 signalling. MAX_OTHER_NCE_NUM specifies any other entries that might 641 be created. Pre-auth session entries are usually short-lived and 642 should be considered part of this category. 644 Note that reservation policy depends upon identification of the 645 reason behind making an NCE . In case of pre-auth sessions, the 646 corresponding NCE is created based on unsecured NS/NA. In case of 647 storing MOP, CHILD NCEs are created either based on DAO (as shown in 648 Figure 3) or based on secured NS/NA messaging (as shown in Figure 4). 649 In case of non-storing MOP, a secured NS/NA messaging as shown in 650 Figure 4 needs to be used. 652 <- - - - - - - - - - - Routing Parents - - - - - - - - - - - - -> 653 +---------------------------------------------------------------+ 654 | | | | 655 +-----------------------------------------------------+---------+ 656 Routing Child Routing Parents Other 658 Figure 5: Reservation of NCEs in neighbor table 660 As shown in the Figure 5, the neighbor cache is partitioned into 661 different entry types. The routing parents can possibly occupy any 662 entry type if found vacant since in case an eviction is sought the 663 non-preferred routing parent could be evicted without much impact on 664 the functioning or on the control traffic. The eviction could be 665 done based on reasons specified in Section 2.3.3. 667 Routing Child entries are made in context to directly connected peers 668 and these entries are not deleted unless they are unreacable or there 669 is any reason for the parent node to believe that it is no longer the 670 preferred parent for the child node. Deletion may happen based on 671 reasons mentioned in Section 2.3.2. 673 Other entries (OTHER) may be made in response to temporary 674 requirement of making an NCE. One such case is the pre 675 authentication phase where in the relay node makes an entry of the 676 PaC temporarily till the time the authentication phase is completed. 677 The NCE made thus is garbage collected at the end of the lifetime. 678 Also an implementation may choose to keep a lower lifetime for such 679 NCEs depending upon the time taken to complete the authentication 680 process. 682 3.1. Limitations of such a policy 684 The reservation based policy mentioned in this section may result in 685 sub-optimal path selection due to lack of NCE resource on the parent 686 nodes. Also the restriction of maximum pre-auth sessions in the form 687 of MAX_OTHER_NCE_NUM limits the maximum relay sessions that can be 688 supported on the relay node. 690 The reservation policy allows the parent node to reject the child 691 node's DAO or NS. But the child node cannot remember this rejection 692 and may reattempt the same parent after some time depending upon 693 triggers such as reception of DIO from the same parent who rejected 694 it previously. One of the only way to stop the child node from 695 reattempting such parent selection would be to also include a 696 proactive approach wherein the parent node signals its resource 697 availability in the DIO message as mentioned in Section 2.5.2. Such 698 a scheme of signalling parent node's resource availability is 699 currently not standardized. 701 RPL's storing MOP imposes additional restrictions. One such case is 702 where a child node may have a given parent node as its only parent 703 and that parent node's NCE are all used up. In such a case, the 704 child node would keep on retrying and failing to send a DAO through 705 the parent node. Ideally the parent node could have evicted a least 706 used child node or a child node who has an alternate parent 707 available. Evicting such a child node is a complex process and may 708 increase the control overhead as described in Section 2.3.3.1. Thus 709 the reservation based policy requires that the minimum node density 710 is sufficiently high so that every child finds a parent node in its 711 vicinity with enough resources. 713 4. Acknowledgements 715 Thanks to Mohit Sethi for the review and feedback. Thanks to Malisa 716 Vucinic for pointing towards security aspects of un-authenticated 717 nodes neighbor cache management. 719 5. IANA Considerations 721 This memo includes no request to IANA. 723 6. Security Considerations 725 The Join Relay or the PANA Relay Element allows the un-authenticated 726 nodes to join the network. Since the NS/NA signaling is unencrypted, 727 it is possible that a malicious node may try to spoof and occupy all 728 the entries. This draft explains the use of reservation based policy 729 for managing such entries. Following points try to reduce the impact 730 of such attacks: 732 a. Only a subset of entries are reserved for un-authenticated nodes 733 doing plain-text NS/NA. 735 b. It is recommended that NCE timeout be configured a lower value to 736 evict such entries as soon as possible. New joining nodes are 737 supposed to use these entries and thus are only needed during the 738 time the authentication is in progress. Thus a short-duration 739 NCE timeout will help reduce the impact of DoS attacks. 741 7. References 743 7.1. Normative References 745 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 746 Requirement Levels", BCP 14, RFC 2119, 747 DOI 10.17487/RFC2119, March 1997, 748 . 750 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 751 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 752 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 753 Low-Power and Lossy Networks", RFC 6550, 754 DOI 10.17487/RFC6550, March 2012, 755 . 757 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 758 Bormann, "Neighbor Discovery Optimization for IPv6 over 759 Low-Power Wireless Personal Area Networks (6LoWPANs)", 760 RFC 6775, DOI 10.17487/RFC6775, November 2012, 761 . 763 7.2. Informative References 765 [CONTIKI] Thingsquare, "Contiki: The Open Source OS for IoT", 2012, 766 . 768 [Dawans_et_al] 769 Dawans, S., Duquennoy, S., and O. Bonaventure, "On Link 770 Estimation in Dense RPL Deployments", 2012. 772 [I-D.ietf-6tisch-architecture] 773 Thubert, P., "An Architecture for IPv6 over the TSCH mode 774 of IEEE 802.15.4", draft-ietf-6tisch-architecture-19 (work 775 in progress), December 2018. 777 [I-D.ietf-6tisch-minimal-security] 778 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 779 "Minimal Security Framework for 6TiSCH", draft-ietf- 780 6tisch-minimal-security-09 (work in progress), November 781 2018. 783 [I-D.ietf-roll-efficient-npdao] 784 Jadhav, R., Thubert, P., Sahoo, R., and Z. Cao, "Efficient 785 Route Invalidation", draft-ietf-roll-efficient-npdao-09 786 (work in progress), October 2018. 788 [I-D.richardson-6tisch-roll-enrollment-priority] 789 Richardson, M., "Enabling secure network enrollment in RPL 790 networks", draft-richardson-6tisch-roll-enrollment- 791 priority-02 (work in progress), February 2019. 793 [LWIP] "lwIP: A Lightweight TCP/IP stack", 794 . 796 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 797 and A. Yegin, "Protocol for Carrying Authentication for 798 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 799 May 2008, . 801 [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., Ed., and 802 A. Yegin, "Protocol for Carrying Authentication for 803 Network Access (PANA) Relay Element", RFC 6345, 804 DOI 10.17487/RFC6345, August 2011, 805 . 807 [WHITEFIELD] 808 "Whitefield Framework", 809 . 811 [Woo_et_al] 812 Woo, A., Tong, T., and D. Culler, "Taming the Underlying 813 Challenges of Reliable Multihop Routing in Sensor 814 Networks", 2003. 816 Appendix A. Performance Result 818 This appendix provides the details of the performance evaluation of 819 this draft. 821 Setup: To perform the test [WHITEFIELD] framework was used with LwIP 822 [LWIP] as the network stack. A version of this draft is 823 implemented in the lwip to provide efficient neighbor cache 824 management policy that will work with relatively lower neighbor 825 cache size. RPL is used as routing protocol to form mesh network. 826 The available neighbor table size was split 60%, 30% and 10% among 827 direct child entries, parent entries and others respectively. 829 Topology: Test was performed with a 64 nodes network including the 830 border router. Grid topology based network was used and all the 831 nodes were in close range with each other simulating a dense 832 condition. 802.15.4 in 2.4GHz range with single channel and un- 833 slotted CSMA wireless RF was used. 835 Steps: Experiment has been conducted with different neighbor cache 836 sizes 10, 20 and 40. For each NC size we have collected sample 837 readings for packet delivery rate by enabling and disabling the 838 new neighbor Cache Management Policy. 840 Data transmission frequency: Each node in the network sends 104 841 bytes (IPv6 Header + RPI + UDP + Data) of UDP request to BR at 842 each 10 second interval. udp Server running at BR process these 843 requests and sends the response back , which is also of same size 844 104 bytes. A duration of 2 minutes delay is added, for network to 845 get stable, before nodes starts sending request messages at 10 sec 846 interval.To calculate PDR one request and response pair is 847 considered as one successful transaction. 849 Packet Delivery Rate Performance 850 +---------------------+---------------------+-----------------------+ 851 | Neighbor Cache Size | PDR With New policy | PDR Without New | 852 | | | policy | 853 +---------------------+---------------------+-----------------------+ 854 | 10 | 96.3 | 7.8 | 855 | 20 | 97.5 | 31.3 | 856 | 40 | 98.7 | 98.6 | 857 +---------------------+---------------------+-----------------------+ 859 Table 2: Packet delivery rate 861 Authors' Addresses 863 Rahul Arvind Jadhav (editor) 864 Huawei 865 Kundalahalli Village, Whitefield, 866 Bangalore, Karnataka 560037 867 India 869 Phone: +91-080-49160700 870 Email: rahul.ietf@gmail.com 872 Rabi Narayan Sahoo 873 Huawei 874 Kundalahalli Village, Whitefield, 875 Bangalore, Karnataka 560037 876 India 878 Phone: +91-080-49160700 879 Email: rabinarayans@huawei.com 881 Simon Duquennoy 882 Inria 883 40 Avenue Halley 884 Building A 885 Villeneuve d'Ascq 886 France 888 Phone: +33 768227731 889 Email: simon.duquennoy@inria.fr 891 Joakim Eriksson 892 Yanzi Networks 894 Email: joakime@sics.se