--- 1/draft-ietf-lwig-nbr-mgmt-policy-01.txt 2018-08-24 09:13:17.800264574 -0700 +++ 2/draft-ietf-lwig-nbr-mgmt-policy-02.txt 2018-08-24 09:13:17.840265541 -0700 @@ -1,45 +1,48 @@ LWIG R. Jadhav, Ed. Internet-Draft R. Sahoo Intended status: Informational Huawei -Expires: August 26, 2018 S. Duquennoy +Expires: February 25, 2019 S. Duquennoy Inria J. Eriksson Yanzi Networks - February 22, 2018 + August 24, 2018 Neighbor Management Policy for 6LoWPAN - draft-ietf-lwig-nbr-mgmt-policy-01 + draft-ietf-lwig-nbr-mgmt-policy-02 Abstract This document describes the problems associated with neighbor cache - management in constrained multihop networks and a sample neighbor - management policy to deal with it. + management in multihop networks involving resource-constrained + devices. Thereafter, it also presents a sample neighbor management + policy that allows efficient cache management in multihop LLNs (low- + power and lossy networks such as LoWPAN) with resource-constrained + devices. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 26, 2018. + This Internet-Draft will expire on February 25, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -64,36 +67,36 @@ 2.3.4. NCE Reinforcement . . . . . . . . . . . . . . . . . . 12 2.4. Requirements of a good neighbor management policy . . . . 12 2.5. Approaches to neighbor management policy . . . . . . . . 13 2.5.1. Reactive Approach . . . . . . . . . . . . . . . . . . 13 2.5.2. Proactive Approach . . . . . . . . . . . . . . . . . 13 3. Reservation based Neighbor Management Policy . . . . . . . . 14 3.1. Limitations of such a policy . . . . . . . . . . . . . . 15 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 7.2. Informative References . . . . . . . . . . . . . . . . . 17 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction - In a wireless multihop network, the node densities (maximum number of - devices connected on a single hop) may vary significantly depending - upon deployments/scenarios. While there is some policy control - possible with regards to the network size in terms of maximum number - of devices connected, it is especially difficult to set a figure on - what will be the maximum node density given a deployment. For e.g. - A network can put an upper limit on max 1000 devices but it is - impossible to state what the node density will be in this 1000 node - network. + In a wireless multihop LLN, the node densities (maximum nodes + reachable on the same hop) may vary significantly depending upon + deployments and scenarios. Examples of such networks is LoWPAN [REF] + networks. While there is some policy control possible with regards + to the network size in terms of maximum number of devices connected, + it is especially difficult to set a figure on what will be the + maximum node density given a deployment. For e.g. A network can put + an upper limit on max 1000 devices but it is impossible to state what + the node density will be in this 1000 node network. A neighbor cache is used for populating neighboring one-hop connected nodes information such as MAC address, link local IP address and other reachability state information. Node density has direct implications on the neighbor cache and in constrained network scenario the size of the neighbor cache will be limited. Thus there are chances that a node may not be able to fit all the neighboring nodes in its cache in which case it has to prioritize entries and thus needs a neighbor management policy. @@ -143,31 +146,49 @@ +--------------------------+ Figure 1: Sample Topology 1.1. Requirements Language and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. + NDP: Neighbor Discovery protocol [REF] + + NS: Neighbor Solicitation + + NA: Neighbor Advertisement + + LLN: Low Power and Lossy Networks + + RPL: Routing Protocol for LLNs [REF] + + DAO: DODAG Advertisement Object + DIO: DODAG Information Object + + ARO: Address Registration Option defined as part of IPv6 NDP + PaC (PANA Client): New joining node which is yet to be authenticated. PRE (PANA Relay Element): An already authenticated and network joined node which is willing to act as a relay element for PaCs to complete their authentication procedure on multi-hop networks. [RFC6345] describes the details of PRE. PAA (PANA Auth Agent): Auth server which hosts the credentials database. PaC will handshake with PAA to complete authentication procedure. + PCI: PANA Client Initiation is the first message sent by the PaC + which initiates the authentication procedure + Routing Child: A downstream node who is part of the routing table of the parent. For e.g. in the sample topology above N5 is the directly connected routing child for N3. N6 and N7 are also part of N3 routing table, they are routing child nodes but not directly connected. For N6 and N7 the document might alternatively use a term grand-child. Routing Parent: In Figure 1, N1 and N2 are possible routing parents for N3. @@ -272,40 +293,40 @@ neighbor entry may get added. Node Joining procedure: A new joinee node discovers a relay element to initiate its auth procedure. At the end of the discovery phase the new joinee node would have known the link local IP address of the relay element. The joinee node will send an unsecured-NS to the relay element to solicit its NA. The PRE may send a NA with the suitable status code as defined in section 6.5.3 of [RFC6775]. RPL - New PRE Parent PAA + PaC PRE Parent PAA | | | | | PRE Disc | | | |<----------->| | | | | | | | UNSEC-NS | | | |------------>| | | | | | | | addNCE(new,reason=PANA)| | | | | | | UNSEC-NA(status) | | |<------------| | | | | | | addNCE(PRE,reason=PANA) | | | | | | | PCI | | | |------------>| | | | | | | | | AUTHPROC | | - |<----------->|<----------------------->| + |<===========>|<=======================>| | | | | Figure 2: NCE creation between PaC and PRE during relay discovery process Relay element does not hold any state information on behalf of the new joinee node except for its neighbor cache entry. Thus in the Figure 1 the new joinee node may select node N3 as its PRE, in which case N3 has to add a neighbor entry on behalf of the new joinee node. @@ -329,21 +350,21 @@ node. For example, in the Figure 1, node N3 needs to maintain a neighbor entry on behalf of N5 which is its directly connected child node. Nodes N6 and N7 are grand-child nodes for node N3 for whom no neighbor entry is required. As mentioned in Section 10.3.2 of [RFC6775], the NCEs on parent and child can be added directly as a result of RPL DIO/DAO signalling without any explicit NS/NA messaging. RPL - New PRE Parent PAA + PaC PRE Parent PAA | | | | | | AuthProc | | |<----------->|<----------------------->| | | | | | | RPL-DIO | | |<-------------------------| | | | | | addNCE(parent,reason=PARENT) | | | | | | | | RPL-DAO | | @@ -359,21 +380,21 @@ source routing header carries the global addresses and thus the NCE of the child node should contain the global address. Secondly, the RPL DAO is addressed directly to the root node in case of non-storing mode. Thus RPL messaging cannot be used for creating NCE entries on parent and child, unlike storing MOP. The child node may send a secure unicast NS with ARO option containing its global address to be registered on the parent node. The child node can still use RPL DIO to create an NCE on behalf of the parent node. RPL - New PRE Parent Root + PaC PRE Parent Root | | | | | | AuthProc | | |<----------->|<----------------------->| | | | | | | RPL-DIO | | |<-------------------------| | | | | | addNCE(parent,reason=PARENT) | | | | | | | sec-NS(ARO=GlobalIPv6) | | @@ -577,37 +598,47 @@ | Routing Parent | MAX_ROUTING_PARENT_NCE_NUM | PARENT | | | | | | Routing child | MAX_ROUTING_CHILD_NCE_NUM | CHILD | | | | | | Others such as pre-auth | MAX_OTHER_NCE_NUM | OTHER | | sessions | | | +-----------------------------+----------------------------+--------+ Table 1: Neighbor Cache Entry reservation + Table 1 denotes that the NCEs are reserved dependending upon the + reason for its addition. MAX_ROUTING_PARENT_NCE_NUM specifies + maximum number of parent entries a node should allow. + MAX_ROUTING_CHILD_NCE_NUM specifies maximum number of child entries + that are allowed after which the node SHOULD decline the DAO + signalling. MAX_OTHER_NCE_NUM specifies any other entries that might + be created. Pre-auth session entries are usually short-lived and + should be considered part of this category. + Note that reservation policy depends upon identification of the reason behind making an NCE . In case of pre-auth sessions, the - corresponding NCE is created based on the unsecured NS/NA. In case - of storing MOP, CHILD_ENT NCEs are created either based on DAO (as - shown in Figure 3) or based on secured NS/NA messaging (as shown in - Figure 4). In case of non-storing MOP, a secured NS/NA messaging as - shown in Figure 4 needs to be used. + corresponding NCE is created based on unsecured NS/NA. In case of + storing MOP, CHILD NCEs are created either based on DAO (as shown in + Figure 3) or based on secured NS/NA messaging (as shown in Figure 4). + + In case of non-storing MOP, a secured NS/NA messaging as shown in + Figure 4 needs to be used. <- - - - - - - - - - - Routing Parents - - - - - - - - - - - - -> +---------------------------------------------------------------+ | | | | +-----------------------------------------------------+---------+ Routing Child Routing Parents Other Figure 5: Reservation of NCEs in neighbor table - As shown in the figure, the neighbor cache is partitioned into + As shown in the Figure 5, the neighbor cache is partitioned into different entry types. The routing parents can possibly occupy any entry type if found vacant since in case an eviction is sought the non-preferred routing parent could be evicted without much impact on the functioning or on the control traffic. The eviction could be done based on reasons specified in Section 2.3.3. Routing Child entries are made in context to directly connected peers and these entries are not deleted unless they are unreacable or there is any reason for the parent node to believe that it is no longer the preferred parent for the child node. Deletion may happen based on @@ -648,39 +679,39 @@ the parent node. Ideally the parent node could have evicted a least used child node or a child node who has an alternate parent available. Evicting such a child node is a complex process and may increase the control overhead as described in Section 2.3.3.1. Thus the reservation based policy requires that the minimum node density is sufficiently high so that every child finds a parent node in its vicinity with enough resources. 4. Acknowledgements - Thanks to Malisa Vucinic for pointing towards security aspects of un- - authenticated nodes neighbor cache management. + Thanks to Mohit Sethi for the review and feedback. Thanks to Malisa + Vucinic for pointing towards security aspects of un-authenticated + nodes neighbor cache management. 5. IANA Considerations This memo includes no request to IANA. 6. Security Considerations The Join Relay or the PANA Relay Element allows the un-authenticated nodes to join the network. Since the NS/NA signaling is unencrypted, - it is possible that a malicious node may try spoof and occupy all the - entries. This draft explains the use of reservation based policy for - managing such entries. Following points try to reduce the impact of - such attacks: Only a subset of entries are reserved for un- - authenticated nodes. + it is possible that a malicious node may try to spoof and occupy all + the entries. This draft explains the use of reservation based policy + for managing such entries. Following points try to reduce the impact + of such attacks: a. Only a subset of entries are reserved for un-authenticated nodes - doing plain-text NS/NA + doing plain-text NS/NA. b. It is recommended that NCE timeout be configured a lower value to evict such entries as soon as possible. New joining nodes are supposed to use these entries and thus are only needed during the time the authentication is in progress. Thus a short-duration NCE timeout will help reduce the impact of DoS attacks. 7. References 7.1. Normative References @@ -707,28 +738,27 @@ [CONTIKI] Thingsquare, "Contiki: The Open Source OS for IoT", 2012, . [Dawans_et_al] Dawans, S., Duquennoy, S., and O. Bonaventure, "On Link Estimation in Dense RPL Deployments", 2012. [I-D.ietf-6tisch-architecture] Thubert, P., "An Architecture for IPv6 over the TSCH mode - of IEEE 802.15.4", draft-ietf-6tisch-architecture-13 (work - in progress), November 2017. + of IEEE 802.15.4", draft-ietf-6tisch-architecture-14 (work + in progress), April 2018. [I-D.ietf-6tisch-minimal-security] Vucinic, M., Simon, J., Pister, K., and M. Richardson, "Minimal Security Framework for 6TiSCH", draft-ietf- - 6tisch-minimal-security-04 (work in progress), October - 2017. + 6tisch-minimal-security-06 (work in progress), May 2018. [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, May 2008, . [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., Ed., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA) Relay Element", RFC 6345, DOI 10.17487/RFC6345, August 2011,