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

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/