idnits 2.17.1 draft-ietf-roll-enrollment-priority-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC9031], [RFC9032]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 181 has weird spacing: '... Type to be...' == Line 183 has weird spacing: '... exp a 4 bi...' == Line 186 has weird spacing: '...AG_Size a 12 ...' == Line 190 has weird spacing: '...riority a 7 b...' -- The document date (28 February 2022) is 789 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ieee802154' ** Downref: Normative reference to an Informational RFC: RFC 7416 ** Downref: Normative reference to an Informational RFC: RFC 7554 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Standards Track R.A. Jadhav 5 Expires: 1 September 2022 Huawei Tech 6 P. Thubert 7 H. She 8 Cisco Systems 9 28 February 2022 11 Controlling Secure Network Enrollment in RPL networks 12 draft-ietf-roll-enrollment-priority-06 14 Abstract 16 [RFC9032] defines a method by which a potential [RFC9031] enrollment 17 proxy can announce itself as a available for new Pledges to enroll on 18 a network. The announcement includes a priority for enrollment. 19 This document provides a mechanism by which a RPL DODAG root can 20 disable enrollment announcements, or adjust the base priority for 21 enrollment operation. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 1 September 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Motivation and Overview . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 4 61 3.2. Upwards compatibility . . . . . . . . . . . . . . . . . . 5 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 8.2. Informative References . . . . . . . . . . . . . . . . . 8 69 Appendix A. Change history . . . . . . . . . . . . . . . . . . . 8 70 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 [RFC7554] describes the use of the time-slotted channel hopping 76 (TSCH) mode of [ieee802154]. [RFC9031] and [RFC9032] describe 77 mechanisms by which a new node (the "pledge") can use a friendly 78 router as a Join Proxy. [RFC9032] describes an extension to the 79 802.15.4 Enhanced Beacon that is used by a Join Proxy to announce its 80 existence such that Pledges can find them. 82 1.1. Motivation and Overview 84 It has become clear that not every routing member of the mesh ought 85 to announce itself as a _Join Proxy_. There are a variety of local 86 reasons by which a 6LR might not want to provide the _Join Proxy_ 87 function. They include available battery power, already committed 88 network bandwidth, and also total available memory available for 89 Neighbor Cache Entry slots. 91 There are other situations where the operator of the network would 92 like to selectively enable or disable the enrollment process in a 93 particular DODAG. 95 As the enrollment process involves permitting unencrypted traffic 96 into the best effort part of a (TSCH) network, it would be better to 97 have the enrollment process off when no new nodes are expected. 99 A network operator might also be able to recognize when certain parts 100 of the network are overloaded and can not accomodate additional 101 enrollment traffic, and it would like to adjust the enrollment 102 priority (the proxy priority field of [RFC9032]) among all nodes in 103 the subtree of a congested link. 105 It may derive from multiple constraining factors, e.g., the size of 106 the DODAG, the occupancy of the bandwidth at the Root, the memory 107 capacity at the DODAG Root, or an administrative decision. 109 Each potential _Join Proxy_ would utilize this value as a base on 110 which to add values relating to local conditions such as its Rank and 111 number of pending joins, which would degrade even further the 112 willingness to take more joins. 114 When a RPL domain is composed of multiple DODAGs, nodes at the edge 115 of 2 DODAGs may not only join either DODAG but also move from one to 116 the other in order to keep their relative sizes balanced. For this, 117 the approximate knowledge of size of the DODAG is an essential 118 metric. Depending on the network policy, the size of the DODAG may 119 or may not affect the minimum enrollment priority. It would be 120 limiting its value to enforce that one is proportional to the other. 121 This is why the current size of the DODAG is advertised separately in 122 the new option. 124 As explained in [RFC9032], higher values decrease the likelihood of 125 an unenrolled node sending enrollment traffic via this path. 127 A network operator can set this value to the maximum value allowed, 128 effectively disabling all new enrollment traffic. 130 Updates to the option propagate through the network according to the 131 trickle algorithm. The contents of the option are generated at the 132 DODAG Root and do not change at any hop. If the contents represent 133 an update that is considered important (e.g., quickly disabling any 134 enrollments), the option can trigger trickle timer resets at the 135 nodes to speed up its propagation. 137 2. Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in 142 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 143 capitals, as shown here. 145 The term (1)"Join" has been used in documents like [RFC9031] to 146 denote the activity of a new node authenticating itself to the 147 network in order to obtain authorization to become a member of the 148 network. 150 In the context of the [RFC6550] RPL protocol, the term (2)"Join" has 151 an alternative meaning: that of a node (already authenticating to the 152 network, and already authorized to be a member of the network), 153 deciding which part of the RPL DODAG to attach to. This term "Join" 154 has to do with preferred parent selection processes. 156 In order to avoid the ambiguity of this term, this document refers to 157 the process (1)"Join" as enrollment, leaving the term "Join" to mean 158 (2)"Join". The term "onboarding" (or IoT Onboarding) is increasingly 159 used to describe what was called enrollment in other documents. 160 However, the term _Join Proxy_ is retained with its meaning from 161 [RFC9031]. 163 3. Protocol Definition 165 This document uses the extensions mechanism designed into [RFC6550]. 166 No mechanism is needed to enable it. 168 3.1. Option Format 170 The resulting priority, if less than 0x7f should enable the _Join 171 Proxy_ function. 173 0 1 2 3 174 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Type |Opt Length = 3 | exp | DODAG_Size | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 |R| min priority| 179 +-+-+-+-+-+-+-+-+ 181 Type to be assigned by IANA. 183 exp a 4 bit unsigned integer, indicating the power of 2 that defines 184 the unit of the DODAG Size, such that (unit=2^exp). 186 DODAG_Size a 12 bit unsigned integer, expressing the size of the 187 DODAG in units that depend on the exp field. The size of the 188 DODAG is computed as (DAG_Size*2^exp). 190 min.priority a 7 bit field which provides a base value for the 191 Enhanced Beacon Join priority. A value of 0x7f (127) disables the 192 _Join Proxy_ function entirely. 194 R a reserved bit that SHOULD be set to 0 by senders, and MUST be 195 ignored by receivers. This reserved bit SHOULD be copied to 196 options created. 198 This document uses the extensions mechanism designed into [RFC6550]. 199 It does not need any mechanism to enable it. 201 The size of the DODAG is measured by the Root based one the DAO 202 activity. It represents a number of routes not a number of nodes, 203 and can only be used to infer a load in a homogeneous network where 204 each node advertises the same number of addresses and generates 205 roughly the same amount of traffic. The size may slightly change 206 between a DIO and the next, so the value transmitted MUST be 207 considered as an approximation. 209 Future work like [I-D.ietf-roll-capabilities] will enable collection 210 of capabilities such as this one in reports to the DODAG root. 212 3.2. Upwards compatibility 214 A 6LR which did not support this option would not act on it, or copy 215 it into it's DIO messages. Children and grandchildren nodes would 216 therefore not receive any telemetry via that path, and need to assume 217 a default value. 219 A 6LR which did not support this option would not act on it or 220 propagate it in its DIO messages. In effect, the 6LR's children and 221 grandchildren nodes could not receive any telemetry via that path. 222 Therefore, 6LRs that support this option but do not receive it via 223 any path SHOULD assume a default value of 0x40 as their base value 224 for the Enhanced Beacon Join Priority. 226 A 6LR downstream of a 6LR where there was an interruption in the 227 telemetry could err in two directions: 229 * if the value implied by the base value of 0x40 was too low, then a 230 6LR might continue to attract enrollment traffic when none should 231 have been collected. This is a stressor for the network, but this 232 would also be what would occur without this option at all. 234 * if the value implied by the base value of 0x40 was too high, then 235 a 6LR might deflect enrollment traffic to other parts of the DODAG 236 tree, possibly refusing any enrollment traffic at all. In order 237 for this to happen, some significant congestion must be seen in 238 the sub-tree where the implied 0x40 was introduced. 240 The 0x40 is only the half-way point, so if such an amount of 241 congestion was present, then this sub-tree of the DODAG simply winds 242 up being more cautious than it needed to be. 244 It is possible that the temporal alternation of the above two 245 situations might introduce cycles of accepting and then rejecting 246 enrollment traffic. This is something an operator should consider if 247 when they incrementally deploy this option to an existing LLN. In 248 addition, an operator would be unable to turn off enrollment traffic 249 by sending a maximum value enrollment priority to the sub-tree. This 250 situation is unfortunate, but without this option, the the situation 251 would occur all over the DODAG, rather than just in the sub-tree 252 where the option was omitted. 254 4. Security Considerations 256 As per [RFC7416], RPL control frames either run over a secured layer 257 2, or use the [RFC6550] Secure DIO methods. This option can be 258 placed into either a "clear" (layer-2 secured) DIO, or a layer-3 259 Secure DIO. As such this option will have both integrity and 260 confidentiality mechanisms applied to it. 262 A malicious node (that was part of the RPL control plane) could see 263 these options and could, based upon the observed minimal enrollment 264 priority signal a confederate that it was a good time to send 265 malicious join traffic. 267 Such as a malicious node, being already part of the RPL control 268 plane, could also send DIOs with a different minimal enrollment 269 priority which would cause downstream mesh routers to change their 270 _Join Proxy_ behavior. 272 Lower minimal priorities would cause downstream nodes to accept more 273 pledges than the network was expecting, and higher minimal priorities 274 cause the enrollment process to stall. 276 The use of layer-2 or layer-3 security for RPL control messages 277 prevents the above two attacks, by preventing malicious nodes from 278 becoming part of the control plane. A node that is attacked and has 279 malware placed on it creates vulnerabilities in the same way such an 280 attack on any node involved in Internet routing protocol does. The 281 rekeying provisions of [RFC9031] exist to permit an operator to 282 remove such nodes from the network easily. 284 5. Privacy Considerations 286 There are no new privacy issues caused by this extension. 288 6. IANA Considerations 290 Allocate a new number TBD01 from Registry RPL Control Message 291 Options. This entry should be called Minimum Enrollment Priority. 293 7. Acknowledgements 295 This has been reviewed by Konrad Iwanicki and Thomas Watteyne. 297 8. References 299 8.1. Normative References 301 [ieee802154] 302 IEEE standard for Information Technology, ., "IEEE Std. 303 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 304 and Physical Layer (PHY) Specifications for Low-Rate 305 Wireless Personal Area Networks", n.d., 306 . 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119, 311 DOI 10.17487/RFC2119, March 1997, 312 . 314 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 315 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 316 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 317 Low-Power and Lossy Networks", RFC 6550, 318 DOI 10.17487/RFC6550, March 2012, 319 . 321 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 322 and M. Richardson, Ed., "A Security Threat Analysis for 323 the Routing Protocol for Low-Power and Lossy Networks 324 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 325 . 327 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 328 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 329 Internet of Things (IoT): Problem Statement", RFC 7554, 330 DOI 10.17487/RFC7554, May 2015, 331 . 333 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 334 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 335 May 2017, . 337 [RFC9031] Vučinić, M., Ed., Simon, J., Pister, K., and M. 338 Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH", 339 RFC 9031, DOI 10.17487/RFC9031, May 2021, 340 . 342 [RFC9032] Dujovne, D., Ed. and M. Richardson, "Encapsulation of 343 6TiSCH Join and Enrollment Information Elements", 344 RFC 9032, DOI 10.17487/RFC9032, May 2021, 345 . 347 8.2. Informative References 349 [I-D.ietf-roll-capabilities] 350 Jadhav, R. A., Thubert, P., Richardson, M., and R. N. 351 Sahoo, "RPL Capabilities", Work in Progress, Internet- 352 Draft, draft-ietf-roll-capabilities-09, 9 November 2021, 353 . 356 Appendix A. Change history 358 version 00. 360 Contributors 362 Authors' Addresses 364 Michael Richardson 365 Sandelman Software Works 366 Email: mcr+ietf@sandelman.ca 367 Rahul Arvind Jadhav 368 Huawei Tech 369 Email: rahul.ietf@gmail.com 371 Pascal Thubert 372 Cisco Systems 373 Email: pthubert@cisco.com 375 Huimin She 376 Cisco Systems 377 Email: hushe@cisco.com