idnits 2.17.1 draft-ietf-roll-enrollment-priority-05.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-6tisch-enrollment-enhanced-beacon], [I-D.ietf-6tisch-minimal-security]), 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 188 has weird spacing: '... exp a 4 bi...' == Line 191 has weird spacing: '...AG_Size a 12 ...' == Line 195 has weird spacing: '...riority a 7 b...' -- The document date (9 August 2021) is 984 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 == Outdated reference: A later version (-09) exists of draft-ietf-roll-capabilities-08 Summary: 3 errors (**), 0 flaws (~~), 5 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: 10 February 2022 Huawei Tech 6 P. Thubert 7 H. She 8 Cisco Systems 9 9 August 2021 11 Controlling Secure Network Enrollment in RPL networks 12 draft-ietf-roll-enrollment-priority-05 14 Abstract 16 [I-D.ietf-6tisch-enrollment-enhanced-beacon] defines a method by 17 which a potential [I-D.ietf-6tisch-minimal-security] enrollment proxy 18 can announce itself as a available for new Pledges to enroll on a 19 network. The announcement includes a priority for enrollment. This 20 document provides a mechanism by which a RPL DODAG root can disable 21 enrollment announcements, or adjust the base priority for enrollment 22 operation. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 10 February 2022. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Motivation and Overview . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 [RFC7554] describes the use of the time-slotted channel hopping 76 (TSCH) mode of [ieee802154]. [I-D.ietf-6tisch-minimal-security] and 77 [I-D.ietf-6tisch-dtsecurity-secure-join] describe mechanisms by which 78 a new node (the "pledge)" can use a friendly router as a Join Proxy. 79 [I-D.ietf-6tisch-enrollment-enhanced-beacon] describes an extension 80 to the 802.15.4 Enhanced Beacon that is used by a Join Proxy to 81 announce its existence such that Pledges can find them. 83 1.1. Motivation and Overview 85 It has become clear that not every routing member of the mesh ought 86 to announce itself as a _Join Proxy_. There are a variety of local 87 reasons by which a 6LR might not want to provide the _Join Proxy_ 88 function. They include available battery power, already committed 89 network bandwidth, and also total available memory available for 90 Neighbor Cache Entry slots. 92 There are other situations where the operator of the network would 93 like to selective enable or disable the enrollment process in a 94 particular DODAG. 96 As the enrollment process involves permitting unencrypted traffic 97 into the best effort part of a (TSCH) network, it would be better to 98 have the enrollment process off when no new nodes are expected. 100 A network operator might also be able to recognize when certain parts 101 of the network are overloaded and can not accomodate additional 102 enrollment traffic, and it would like to adjust the enrollment 103 priority (the proxy priority field of 104 [I-D.ietf-6tisch-enrollment-enhanced-beacon]) among all nodes in the 105 subtree of a congested link. 107 This document describes a RPL DIO option that can be used to announce 108 a minimum enrollment priority. The minimum priority expresses the 109 (lack of) willingness by the RPL DODAG globally to accept new joins. 110 It may derive from multiple constaining factors, e.g., the size of 111 the DODAG, the occupancy of the bandwidth at the Root, the memory 112 capacity at the DODAG Root, or an administrative decision. 114 Each potential _Join Proxy_ would this value as a base on which to 115 add values relating to local conditions such as its Rank and number 116 of pending joins, which would degrade even further the willingness to 117 take more joins. 119 When a RPL domain is composed of multiple DODAGs, nodes at the edge 120 of 2 DODAGs may not only join either DODAG but also move from one to 121 the other in order to keep their relative sizes balanced. For this, 122 the approximate knowledge of size of the DODAG is an essential 123 metric. Depending on the network policy, the size of the DODAG may 124 or may not affect the minimum enrollment priority. It would be 125 limiting its value to enforce that one is proportional to the other. 126 This is why the current size of the DODAG is advertised separately in 127 the new option. 129 As explained in [I-D.ietf-6tisch-enrollment-enhanced-beacon], higher 130 values decrease the likelyhood of an unenrolled node sending 131 enrollment traffic via this path. 133 A network operator can set this value to the maximum value allowed, 134 effectively disable all new enrollment traffic. 136 2. Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 140 "OPTIONAL" in this document are to be interpreted as described in 141 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 142 capitals, as shown here. 144 The term (1)"Join" has been used in documents like 145 [I-D.ietf-6tisch-minimal-security] to denote the activity of a new 146 node authenticating itself to the network in order to obtain 147 authorization to become a member of the network. 149 In the context of the [RFC6550] RPL protocol, the term (2)"Join" has 150 an alternate meaning: that of a node (already authenticating to the 151 network, and already authorized to be a member of the network), 152 deciding which part of the RPL DODAG to attach to. This term "Join" 153 has to do with parent selection processes. 155 In order to avoid the ambiguity of this term, this document refers to 156 the process (1)"Join" as enrollment, leaving the term "Join" to mean 157 (2)"Join". The term "onboarding" (or IoT Onboarding) is sometimes 158 used to describe the enrollment process. However, the term _Join 159 Proxy_ is retained with it's meaning from 160 [I-D.ietf-6tisch-minimal-security]. 162 3. Protocol Definition 164 With this specification, the following option is defined for 165 transmission in the DIO issued by the DODAG root and it MUST be 166 propagated down the DODAG. 168 A 6LR which would otherwise be willing to act as a _Join Proxy_, will 169 examine the minimum priority field, and to that number, add any 170 additional local consideration (such as upstream congestion). 172 The Enrollment Priority can only be increased by each 6LR in value, 173 to the maximum value of 0x7f. 175 The resulting priority, if less than 0x7f should enable the _Join 176 Proxy_ function. 178 0 1 2 3 179 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 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Type |Opt Length = 3 | exp | DODAG_Size | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 |R| min priority| 184 +-+-+-+-+-+-+-+-+ 186 Type To be assigned by IANA 188 exp a 4 bit unsigned integer, indicating the power of 2 that defines 189 the unit of the DODAG Size, such that (unit=2^exp). 191 DODAG_Size a 12 bit unsigned integer, expressing the size of the 192 DODAG in units that depend on the exp field. The size of the 193 DODAG is computed as (DAG_Size*2^exp). 195 min.priority a 7 bit field which provides a base value for the 196 Enhanced Beacon Join priority. A value of 0x7f (127) disables the 197 _Join Proxy_ function entirely. 199 R a reserved bit that SHOULD be set to 0 by senders, and MUST be 200 ignored by receivers. This reserved bit SHOULD be copied to 201 options created. 203 This document uses the extensions mechanism designed into [RFC6550]. 204 It does not need any mechanism to enable it. 206 The size of the DODAG is measured by the Root based one the DAO 207 activity. It represents a number of routes not a number of nodes, 208 and can only be used to infer a load in an homogeneous network where 209 each node advertises the same number of addresses and generates 210 roughly the same amount of traffic. The size may slightly change 211 between a DIO and the next, so the value transmitted must be 212 considered as an approxmation. 214 Future work like [I-D.ietf-roll-capabilities] will enable collection 215 of capabilities such as this one in reports to the DODAG root. 217 3.1. Upwards compatibility 219 A 6LR which did not support this option would not act on it, or copy 220 it into it's DIO messages. Children and grandchildren nodes would 221 therefore not receive any telemetry via that path, and need to assume 222 a default value. 224 6LRs that support this option, but whose parent does not send it 225 SHOULD assume a value of 0x40 as their base value. The nodes then 226 adjust this base value based upon their observed congestion, emitting 227 their adjusted DIO value to their children. 229 A 6LR downstream of a 6LR where there was an interruption in the 230 telemetry could err in two directions: 232 * if the value implied by the base value of 0x40 was too low, then a 233 6LR might continue to attract enrollment traffic when none should 234 have been collected. This is a stressor for the network, but this 235 would also be what would occur without this option at all. 237 * if the value implied by the base value of 0x40 was too high, then 238 a 6LR might deflect enrollment traffic to other parts of the DODAG 239 tree, possibly refusing any enrollment traffic at all. In order 240 for this to happen, some significant congestion must be seen in 241 the sub-tree where the implied 0x40 was introduced. 243 The 0x40 is only the half-way point, so if such an amount of 244 congestion was present, then this sub-tree of the DODAG simply winds 245 up being more cautious than it needed to be. 247 It is possible that the temporal alternation of the above two 248 situations might introduce cycles of accepting and then rejecting 249 enrollment traffic. This is something an operator should consider if 250 when they incrementally deploy this option to an existing LLN. In 251 addition, an operator would be unable to turn off enrollment traffic 252 by sending a maximum value enrollment priority to the sub-tree. This 253 situation is unfortunate, but without this option, the the situation 254 would occur all over the DODAG, rather than just in the sub-tree 255 where the option was omitted. 257 4. Security Considerations 259 As per [RFC7416], RPL control frames either run over a secured layer 260 2, or use the [RFC6550] Secure DIO methods. This option can be 261 placed into either a "clear" (layer-2 secured) DIO, or a layer-3 262 Secure DIO. As such this option will have both integrity and 263 confidentiality mechanisms applied to it. 265 A malicious node (that was part of the RPL control plane) could see 266 these options and could, based upon the observed minimal enrollment 267 priority signal a confederate that it was a good time to send 268 malicious join traffic. 270 Such as a malicious node, being already part of the RPL control 271 plane, could also send DIOs with a different minimal enrollment 272 priority which would cause downstream mesh routers to change their 273 _Join Proxy_ behaviour. 275 Lower minimal priorities would cause downstream nodes to accept more 276 pledges than the network was expecting, and higher minimal priorities 277 cause the enrollment process to stall. 279 The use of layer-2 or layer-3 security for RPL control messages 280 prevents the above two attacks, by preventing malicious nodes from 281 becoming part of the control plane. A node that is attacked and has 282 malware placed on it creates vulnerabilities in the same way such an 283 attack on any node involved in Internet routing protocol does. The 284 rekeying provisions of [I-D.ietf-6tisch-minimal-security] exist to 285 permit an operator to remove such nodes from the network easily. 287 5. Privacy Considerations 289 There are no new privacy issues caused by this extension. 291 6. IANA Considerations 293 Allocate a new number TBD01 from Registry RPL Control Message 294 Options. This entry should be called Minimum Enrollment Priority. 296 7. Acknowledgements 298 This has been reviewed by Konrad Iwanicki and Thomas Wattenye. 300 8. References 302 8.1. Normative References 304 [I-D.ietf-6tisch-enrollment-enhanced-beacon] 305 (editor), D. D. and M. Richardson, "Encapsulation of 306 6TiSCH Join and Enrollment Information Elements", Work in 307 Progress, Internet-Draft, draft-ietf-6tisch-enrollment- 308 enhanced-beacon-14, 21 February 2020, 309 . 312 [I-D.ietf-6tisch-minimal-security] 313 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 314 "Constrained Join Protocol (CoJP) for 6TiSCH", Work in 315 Progress, Internet-Draft, draft-ietf-6tisch-minimal- 316 security-15, 10 December 2019, 317 . 320 [ieee802154] 321 IEEE standard for Information Technology, ., "IEEE Std. 322 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 323 and Physical Layer (PHY) Specifications for Low-Rate 324 Wireless Personal Area Networks", n.d., 325 . 328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 329 Requirement Levels", BCP 14, RFC 2119, 330 DOI 10.17487/RFC2119, March 1997, 331 . 333 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 334 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 335 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 336 Low-Power and Lossy Networks", RFC 6550, 337 DOI 10.17487/RFC6550, March 2012, 338 . 340 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 341 and M. Richardson, Ed., "A Security Threat Analysis for 342 the Routing Protocol for Low-Power and Lossy Networks 343 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 344 . 346 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 347 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 348 Internet of Things (IoT): Problem Statement", RFC 7554, 349 DOI 10.17487/RFC7554, May 2015, 350 . 352 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 353 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 354 May 2017, . 356 8.2. Informative References 358 [I-D.ietf-6tisch-dtsecurity-secure-join] 359 Richardson, M., "6tisch Secure Join protocol", Work in 360 Progress, Internet-Draft, draft-ietf-6tisch-dtsecurity- 361 secure-join-01, 25 February 2017, 362 . 365 [I-D.ietf-roll-capabilities] 366 Jadhav, R. A., Thubert, P., Richardson, M., and R. N. 367 Sahoo, "RPL Capabilities", Work in Progress, Internet- 368 Draft, draft-ietf-roll-capabilities-08, 17 March 2021, 369 . 372 Appendix A. Change history 374 version 00. 376 Contributors 378 Authors' Addresses 380 Michael Richardson 381 Sandelman Software Works 383 Email: mcr+ietf@sandelman.ca 385 Rahul Arvind Jadhav 386 Huawei Tech 388 Email: rahul.ietf@gmail.com 390 Pascal Thubert 391 Cisco Systems 393 Email: pthubert@cisco.com 395 Huimin She 396 Cisco Systems 398 Email: hushe@cisco.com