draft-ietf-lwig-nbr-mgmt-policy-00.txt		draft-ietf-lwig-nbr-mgmt-policy-01.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: March 1, 2018 S. Duquennoy		Expires: August 26, 2018 S. Duquennoy
	Inria		Inria
	J. Eriksson		J. Eriksson
	Yanzi Networks		Yanzi Networks
	August 28, 2017		February 22, 2018
	Neighbor Management Policy for 6LoWPAN		Neighbor Management Policy for 6LoWPAN
	draft-ietf-lwig-nbr-mgmt-policy-00		draft-ietf-lwig-nbr-mgmt-policy-01
	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 constrained multihop networks and a sample neighbor
	management policy to deal with it.		management policy to deal with it.
	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 http://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 March 1, 2018.		This Internet-Draft will expire on August 26, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 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
	(http://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	skipping to change at page 2, line 21 ¶		skipping to change at page 2, line 21 ¶
	2. Neighbor Management . . . . . . . . . . . . . . . . . . . . . 5		2. Neighbor Management . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Significance of Neighbor management policy . . . . . . . 5		2.1. Significance of Neighbor management policy . . . . . . . 5
	2.2. Trivial neighbor management policies . . . . . . . . . . 6		2.2. Trivial neighbor management policies . . . . . . . . . . 6
	2.3. Lifecycle of a NCE . . . . . . . . . . . . . . . . . . . 7		2.3. Lifecycle of a NCE . . . . . . . . . . . . . . . . . . . 7
	2.3.1. NCE Insertion . . . . . . . . . . . . . . . . . . . . 7		2.3.1. NCE Insertion . . . . . . . . . . . . . . . . . . . . 7
	2.3.2. NCE Deletion . . . . . . . . . . . . . . . . . . . . 10		2.3.2. NCE Deletion . . . . . . . . . . . . . . . . . . . . 10
	2.3.3. NCE Eviction . . . . . . . . . . . . . . . . . . . . 11		2.3.3. NCE Eviction . . . . . . . . . . . . . . . . . . . . 11
	2.3.3.1. Eviction for directly connected routing entries . 11		2.3.3.1. Eviction for directly connected routing entries . 11
	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 . . . . . . . . 12		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 . . . . . . . . . . . . . . . . . . . . . . . . . 16
	7.1. Normative References . . . . . . . . . . . . . . . . . . 16		7.1. Normative References . . . . . . . . . . . . . . . . . . 16
	7.2. Informative References . . . . . . . . . . . . . . . . . 16		7.2. Informative References . . . . . . . . . . . . . . . . . 17
	Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	In a wireless multihop network, the node densities (maximum number of		In a wireless multihop network, the node densities (maximum number of
	devices connected on a single hop) may vary significantly depending		devices connected on a single hop) may vary significantly depending
	upon deployments/scenarios. While there is some policy control		upon deployments/scenarios. While there is some policy control
	possible with regards to the network size in terms of maximum number		possible with regards to the network size in terms of maximum number
	of devices connected, it is especially difficult to set a figure on		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.		what will be the maximum node density given a deployment. For e.g.
	skipping to change at page 12, line 48 ¶		skipping to change at page 12, line 48 ¶
	Route Stability: Stable NCEs will result in stable routing		Route Stability: Stable NCEs will result in stable routing
	adjacencies. Thus it is important to avoid unnecessary NCE churn		adjacencies. Thus it is important to avoid unnecessary NCE churn
	for routing path stability.		for routing path stability.
	Control overhead: A neighbor management policy may have to use		Control overhead: A neighbor management policy may have to use
	signalling messages for policy handling (such as rejection of		signalling messages for policy handling (such as rejection of
	NCE). It is required that such overhead be kept as low as		NCE). It is required that such overhead be kept as low as
	possible.		possible.
			Scalability: Scalability with respect to large and uneven node
			densities in the network.
	2.5. Approaches to neighbor management policy		2.5. Approaches to neighbor management policy
	Neighbor management policy depends upon the neighbor cache space		Neighbor management policy depends upon the neighbor cache space
	availability and the same can be advertised proactively or can be		availability and the same can be advertised proactively or can be
	handled reactively.		handled reactively.
	2.5.1. Reactive Approach		2.5.1. Reactive Approach
	In this approach, the nodes select their RPL parent or the relay		In this approach, the nodes select their RPL parent or the relay
	element purely based on link metrics and subsequently when they try		element purely based on link metrics and subsequently when they try
	skipping to change at page 16, line 7 ¶		skipping to change at page 16, line 11 ¶
	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
	This template was derived from an initial version written by Pekka		Thanks to Malisa Vucinic for pointing towards security aspects of un-
	Savola and contributed by him to the xml2rfc project.		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
	Add DoS attacks possibility on NBR table on PRE and what are the		The Join Relay or the PANA Relay Element allows the un-authenticated
	mechanisms already defined by standards (such as use of Enforcement		nodes to join the network. Since the NS/NA signaling is unencrypted,
	Point)		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.
	All drafts are required to have a security considerations section.		a. Only a subset of entries are reserved for un-authenticated nodes
	See RFC 3552 [RFC3552] for a guide.		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. References
	7.1. Normative References		7.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997, <https://www.rfc-		DOI 10.17487/RFC2119, March 1997,
	editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,		[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
	Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,		Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
	JP., and R. Alexander, "RPL: IPv6 Routing Protocol for		JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
	Low-Power and Lossy Networks", RFC 6550,		Low-Power and Lossy Networks", RFC 6550,
	DOI 10.17487/RFC6550, March 2012, <https://www.rfc-		DOI 10.17487/RFC6550, March 2012,
	editor.org/info/rfc6550>.		<https://www.rfc-editor.org/info/rfc6550>.
	[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.		[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
	Bormann, "Neighbor Discovery Optimization for IPv6 over		Bormann, "Neighbor Discovery Optimization for IPv6 over
	Low-Power Wireless Personal Area Networks (6LoWPANs)",		Low-Power Wireless Personal Area Networks (6LoWPANs)",
	RFC 6775, DOI 10.17487/RFC6775, November 2012,		RFC 6775, DOI 10.17487/RFC6775, November 2012,
	<https://www.rfc-editor.org/info/rfc6775>.		<https://www.rfc-editor.org/info/rfc6775>.
	7.2. Informative References		7.2. Informative References
	[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-12 (work		of IEEE 802.15.4", draft-ietf-6tisch-architecture-13 (work
	in progress), August 2017.		in progress), November 2017.
	[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-03 (work in progress), June 2017.		6tisch-minimal-security-04 (work in progress), October
			2017.
	[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
	Text on Security Considerations", BCP 72, RFC 3552,
	DOI 10.17487/RFC3552, July 2003, <https://www.rfc-
	editor.org/info/rfc3552>.
	[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, <https://www.rfc-		DOI 10.17487/RFC6345, August 2011,
	editor.org/info/rfc6345>.		<https://www.rfc-editor.org/info/rfc6345>.
	[Woo_et_al]		[Woo_et_al]
	Woo, A., Tong, T., and D. Culler, "Taming the Underlying		Woo, A., Tong, T., and D. Culler, "Taming the Underlying
	Challenges of Reliable Multihop Routing in Sensor		Challenges of Reliable Multihop Routing in Sensor
	Networks", 2003.		Networks", 2003.
	Appendix A. Additional Stuff
	This becomes an Appendix.
	Authors' Addresses		Authors' Addresses
	Rahul Arvind Jadhav (editor)		Rahul Arvind Jadhav (editor)
	Huawei		Huawei
	Kundalahalli Village, Whitefield,		Kundalahalli Village, Whitefield,
	Bangalore, Karnataka 560037		Bangalore, Karnataka 560037
	India		India
	Phone: +91-080-49160700		Phone: +91-080-49160700
	Email: rahul.ietf@gmail.com		Email: rahul.ietf@gmail.com
	Rabi Narayan Sahoo		Rabi Narayan Sahoo
	Huawei		Huawei
	Kundalahalli Village, Whitefield,		Kundalahalli Village, Whitefield,
	Bangalore, Karnataka 560037		Bangalore, Karnataka 560037
	India		India
	Phone: +91-080-49160700		Phone: +91-080-49160700
	Email: rabinarayans@huawei.com		Email: rabinarayans@huawei.com
	Simon Duquennoy		Simon Duquennoy
End of changes. 21 change blocks.
	36 lines changed or deleted		40 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/