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/