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/