idnits 2.17.1 draft-tiloca-6tisch-robust-scheduling-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 17, 2018) is 1950 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) == Outdated reference: A later version (-15) exists of draft-ietf-6tisch-minimal-security-09 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH Working Group M. Tiloca 3 Internet-Draft RISE AB 4 Intended status: Standards Track S. Duquennoy 5 Expires: June 20, 2019 Yanzi Networks AB 6 G. Dini 7 University of Pisa 8 December 17, 2018 10 Robust Scheduling against Selective Jamming in 6TiSCH Networks 11 draft-tiloca-6tisch-robust-scheduling-01 13 Abstract 15 This document defines a method to generate robust TSCH schedules in a 16 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4-2015) network, so as 17 to protect network nodes against selective jamming attack. Network 18 nodes independently compute the new schedule at each slotframe, by 19 altering the one originally available from 6top or alternative 20 protocols, while preserving a consistent and collision-free 21 communication pattern. This method can be added on top of the 22 minimal security framework for 6TiSCH. 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 June 20, 2019. 41 Copyright Notice 43 Copyright (c) 2018 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 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Properties of TSCH that Simplify Selective Jamming . . . . . 3 61 3. Selective Jamming Attack . . . . . . . . . . . . . . . . . . 4 62 3.1. Adversary Model . . . . . . . . . . . . . . . . . . . . . 5 63 3.2. Attack Example . . . . . . . . . . . . . . . . . . . . . 5 64 4. Building Robust Schedules . . . . . . . . . . . . . . . . . . 7 65 5. Adaptation to the 6TiSCH Minimal Security Framework . . . . . 9 66 5.1. Error Handling . . . . . . . . . . . . . . . . . . . . . 10 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 6.1. Effectiveness of Schedule Shuffling . . . . . . . . . . . 11 69 6.2. Renewal of Key Material . . . . . . . . . . . . . . . . . 11 70 6.3. Static Timeslot Allocations . . . . . . . . . . . . . . . 11 71 6.4. Network Joining Through Randez-vous Cells . . . . . . . . 12 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 7.1. Permutation Key Set . . . . . . . . . . . . . . . . . . . 12 74 7.2. Permutation Cipher . . . . . . . . . . . . . . . . . . . 13 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 77 8.2. Informative References . . . . . . . . . . . . . . . . . 14 78 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 Nodes in a 6TiSCH network communicate using the IEEE 802.15.4-2015 84 standard and its Timeslotted Channel Hopping (TSCH) mode. Some 85 properties of TSCH make schedule units, i.e. cells, and their usage 86 predictable, even if security services are used at the MAC layer. 88 This allows an external adversary to easily derive the communication 89 pattern of a victim node. After that, the adversary can perform a 90 selective jamming attack, by covertly, efficiently, and effectively 91 transmitting over the only exact cell(s) in the victim's schedule. 93 This document describes a method to counteract such an attack. At 94 each slotframe, every node autonomously computes a TSCH schedule, as 95 a pseudo-random permutation of the one originally available from 6top 96 [RFC8480] or alternative protocols. 98 The resulting schedule is provided to TSCH and used to communicate 99 during the next slotframe. In particular, the new communication 100 pattern results unpredictable for an external adversary. Besides, 101 since all nodes compute the same pseudo-random permutation, the new 102 communication pattern remains consistent and collision-free. 104 The proposed solution is intended to operate on slotframes that are 105 used for data transmission by current network nodes, and that are not 106 used to join the network. In fact, since the TSCH schedule is 107 altered at each slotframe, the proposed method cannot be applied to 108 slotframes that include a "minimal cell" [RFC8180] and possible other 109 randez-vouz cells used for joining the 6TiSCH network. 111 This document specifies also how this method can be added on top of 112 the minimal security framework for 6TiSCH and its Constrained Join 113 Protocol (CoJP) [I-D.ietf-6tisch-minimal-security]. 115 1.1. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in BCP 120 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 Readers are expected to be familiar with terms and concepts defined 124 in [I-D.ietf-6tisch-minimal-security], [I-D.ietf-6tisch-terminology] 125 and [RFC8152]. 127 This document refers also to the following terminology. 129 o Permutation key. A cryptographic key shared by network nodes and 130 used to permute schedules. Different keys are used to permute the 131 utilization pattern of timeslots and of channelOffsets. 133 2. Properties of TSCH that Simplify Selective Jamming 135 This section highlights a number of properties of the TSCH cell usage 136 that greatly simplify the performance of the selective jamming attack 137 described in Section 3. 139 Given: 141 o N_S as the size of slotframes in timeslots; 143 o N_C as the number of available channelOffsets; 144 o The channel 'f' to communicate at timeslot 's' with ASN and 145 channelOffset 'chOff' computed as f = F[(ASN + chOff) mod N_C]; 147 And assuming for simplicity that: 149 o N_S and N_C are coprime values; 151 o The channel hopping sequence is N_C in size and equal to {0, 1, 152 ..., N_C - 1}; 154 Then, the following properties hold: 156 o Periodicity property. The sequence of channels used for 157 communication by a certain cell repeats with period (N_C x N_S) 158 timeslots. 160 o Usage property. Within a period, every cell uses all the 161 available channels, each of which only once. 163 o Offset property. All cells follow the same sequence of channels 164 with a certain offset. 166 o Predictability property. For each cell, the sequence of channels 167 is predictable. That is, by knowing the channel used by a cell in 168 a given timeslot, it is possible to compute the remaining channel 169 hopping sub-sequence. 171 In fact, given a cell active on channel 'f' and timeslot 's' on 172 slotframe 'T', and since ASN = (s + T x N_S), it holds that 174 f = [(s + T x N_S + c) mod N_C] (Eq. 1) 176 By solving this equation in 'c', one can predict the channels used 177 by the cell in the next sloframes. Note that, in order to do 178 that, one does not need to know the absolute number 'T' of the 179 slotframe (and thus the exact ASN) in which timeslot 's' uses a 180 certain channel 'f'. In fact, one can re-number slotframes 181 starting from any arbitrarily assumed "starting-slotframe". 183 3. Selective Jamming Attack 185 This section describes how an adversary can exploit the properties 186 listed in Section 2, and determine the full schedule of a victim 187 node, even if security services at the MAC layer are used. 189 This allows the adversary to selectively jam only the exact cell(s) 190 in the victim's schedule, while greatly limiting the exposure to 191 detection. At the same time, the attack is highly effective in 192 jeopardizing victim's communications, and is highly energy-efficient, 193 i.e., can be carried out on battery. 195 For simplicity, the following description also assumes that a victim 196 node actually transmits/receives during all its allocated cells at 197 each slotframe. 199 3.1. Adversary Model 201 This specification addresses an adversary with the following 202 properties. 204 o The adversary is external, i.e. it does not control any node 205 registered in the 6TiSCH network. 207 o The adversary wants to target precise network nodes and their 208 traffic. That is, it does not target the 6TiSCH network as a 209 whole, and does not perform a wide-band constant jamming. 211 o The adversary is able to target multiple victim nodes at the same 212 time. This may require multiple jamming sources and/or multiple 213 antennas per jamming source to carry out the attack. 215 Furthermore, compared to wide-band constant jamming, the considered 216 selective jamming attack deserves special attention to be addressed, 217 due to the following reasons. 219 o It is much more energy efficient. 221 o It minimizes the adversary's exposure and hence the chances to be 222 detected. 224 o It has the same effectiveness on the intended victim nodes. That 225 is, it achieves the same goal, while avoiding the unnecessarily 226 exposure and costs of wide-band constant jamming. 228 It is worth noting that a wide-band constant jamming can achieve the 229 same result more easily, in the extreme cases where the target 230 slotframe is (nearly) fully used by a few nodes only, or the 231 adversary has as many antennas as the number of available channels. 232 However, this would still come at the cost of high exposure and 233 higher energy consumption for the adversary. 235 3.2. Attack Example 237 The following example considers Figure 1, where N_S = 3, N_C = 4, and 238 the channel hopping sequence is {0,1,2,3}. The shown schedule refers 239 to a network node that uses three cells 'L_1', 'L_2' and 'L_3', with 240 {0,3}, {1,1} and {2,0} as pairs {timeslot, channelOffset}, 241 respectively. 243 |==|===================================================================| 244 |Ch| ASN | 245 | |===================================================================| 246 |Of| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |10 |11 |12 |13 |14 |15 |16 | 247 |==|===================================================================| 248 |0 | | |f=2| | |f=1| | |f=0| | |f=3| | |f=2| | | 249 |--|-------------------------------------------------------------------| 250 |1 | |f=2| | |f=1| | |f=0| | |f=3| | |f=2| | |f=1| 251 |--|-------------------------------------------------------------------| 252 |2 | | | | | | | | | | | | | | | | | | 253 |--|-------------------------------------------------------------------| 254 |3 |f=3| | |f=2| | |f=1| | |f=0| | |f=3| | |f=2| | 255 |==|===================================================================| 256 | | | | | | | | | | | | | | | | | 257 |s=0|s=1|s=2|s=0|s=1|s=2|s=0|s=1|s=2|s=0|s=1|s=2|s=0|s=1|s=2|s=0|s=1 258 | | | | | | 259 | T = 0 | T = 1 | T = 2 | T = 3 | T = 4 | T = 5 260 | 261 \__ t = 0 263 Figure 1: Attack Example with Slotframe Re-numbering 265 1. The adversary starts the attack at absolute slotframe T = 1, 266 which is assumed as "starting-slotframe" and thus renamed as 267 slotframe t = 0. The renaming is possible due to the offset and 268 predictability properties. 270 2. The adversary picks a channel 'f*' at random, and monitors it for 271 N_C consecutive slotframes to determine the timeslots in which 272 the victim node communicates on that channel. Due to the usage 273 property, the number of such timeslots is equal to the number of 274 cells assigned to the victim node. 276 With reference to Figure 1, if, for example, f* = 1, the 277 adversary determines that the victim node uses channel 'f*' in 278 timeslots s = 1 and s = 2 of slotframe t = 0 and in timeslot s = 279 0 of slotframe t = 1. The adversary can then deduce that the 280 victim node uses three different cells 'L_1', 'L_2' and 'L_3', in 281 timeslots 0, 1 and 2, respectively. 283 3. The adversary determines the channels on which the victim node is 284 going to transmit in the next slotframes, by exploiting the 285 predictability property. 287 That is, by instantiating Equation 1 for cell L_1, timeslot s = 0 288 and slotframe t = 1, one gets [1 = (3 + c_1) mod 4], which has 289 solution for c_1 = 2. Hence, the function to predict the channel 290 'f_1' to be used by cell 'L_1' in a slotframe 't', t >= 1, is f_1 291 = [(2 + 3 x t) mod 4], which produces the correct periodic 292 sequence of channels {1, 0, 3, 2}. Similarly, one can instantiate 293 Equation 1 for cells 'L_2' and 'L_3', so producing the respective 294 periodic sequence of channels {1,0,3,2} and {1,0,3,2}. 296 4. The adversary has discovered the full schedule of the victim node 297 and can proceed with the actual selective jamming attack. That 298 is, according to the found schedule, the adversary transmits over 299 the exact cells used by the victim node for transmission/ 300 reception, while staying quiet and saving energy otherwise. This 301 results in a highly effective, highly efficient and hard to 302 detect attack against communications of network nodes. 304 4. Building Robust Schedules 306 This section defines a method to protect network nodes against the 307 selective jamming attack described in Section 3. The proposed method 308 alters the communication pattern of all network nodes at every 309 slotframe, in a way unpredictable for the adversary. 311 At each slotframe 'T', network nodes autonomously compute the 312 communication pattern for the next slotframe 'T+1' as a pseudo-random 313 permutation of the one originally available. In order to ensure that 314 the new communication pattern remains consistent and collision-free, 315 all nodes compute the same permutation of the original one. In 316 particular, at every slotframe, each node separately and 317 independently permutes its timeslot utilization pattern (optionally) 318 as well as its channelOffset utilization pattern. 320 To perform the required permutations, all network nodes rely on a 321 same secure pseudo-random number generator (SPRNG) as shown in 322 Figure 2, where E(x,y) denotes a cipher which encrypts a plaintext 323 'y' by means of a key 'x'. Network nodes MUST support the AES-CCM- 324 16-64-128 algorithm. 326 unsigned random(unsigned K, unsigned z) { 327 unsigned val = E(K,z); 328 return val; 329 } 331 Figure 2: Secure Pseudo-Random Number Generator 333 All network nodes share the same following pieces of information. 335 o K_s, a permutation key used to permute the timeslot utilization 336 pattern, and used as input to the random() function in Figure 2. 337 K_s is provided upon joining the network, and MAY be provided as 338 described in Section 5. 340 o K_c, a permutation key used to permute the channelOffset 341 utilization pattern, and used as input to the random() function in 342 Figure 2. K_c is provided upon joining the network, and MAY be 343 provided as described in Section 5. 345 o z_s, a counter used to permute the timeslot utilization pattern, 346 and used as input to the random() function in Figure 2. At the 347 beginning of each slotframe, z_s is equal to the ASN value of the 348 first timeslot of that slotframe. Then, z_s grows by N_S from the 349 beginning of a slotframe to the beginning of the next one. 351 o z_c, a counter used to permute the channelOffset utilization 352 pattern, and used as input to the random() function in Figure 2. 353 At the beginning of each slotframe, z_c is equal to [N_C x 354 floor(ASN* / N_S)], where ASN* is the ASN value of the first 355 timeslot of that slotframe. Then, z_c grows by N_C from the 356 beginning of a slotframe to the beginning of the next one. 358 Then, at every slotframe, each network node takes the following 359 steps, and generates its own permuted communication schedule to be 360 used at the following slotframe. The actual permutation of cells 361 relies on the well-known Fisher-Yates algorithm, that requires to 362 generate n pseudo-random numbers in order to pseudo-randomly shuffle 363 a vector of n elements. 365 1. First, a pseudo-random permutation is performed on the timeslot 366 dimension of the slotframe. This requires N_S invocations of 367 random(K,z), consistently with the Fisher-Yates algorithm. In 368 particular, K = K_s, while z_s is passed as second argument and 369 is incremented by 1 after each invocation. The result of this 370 step is a permuted timeslot utilization pattern, while the 371 channelOffset utilization pattern is not permuted yet. 373 2. Second, a pseudo-random permutation is performed on the 374 channelOffset dimension of the slotframe. This requires N_C 375 invocations of random(K,z), consistently with the Fisher-Yates 376 algorithm. In particular, K = K_c, while z_c is passed as second 377 argument and is incremented by 1 after each invocation. The 378 result of this step is a fully shuffled communication pattern. 380 The resulting schedule is then provided to TSCH and considered for 381 sending/receiving traffic during the next slotframe. 383 As further discussed in Section 6.3, it is possible, although NOT 384 RECOMMENDED, to skip step 1 above, and hence permute only the 385 channelOffset utilization pattern, while keeping a static timeslot 386 utilization pattern. 388 Note for implementation: the process described above can be 389 practically implemented by using two vectors, i.e. one for shuffling 390 the timeslot utilization pattern and one for shuffling the 391 channelOffset utilization pattern. 393 5. Adaptation to the 6TiSCH Minimal Security Framework 395 The security mechanism described in this specification can be added 396 on top of the minimal security framework for 6TiSCH 397 [I-D.ietf-6tisch-minimal-security]. 399 That is, the two permutation keys K_s and K_c can be provided to a 400 pledge when performing the Constrained Join Protocol (CoJP) defined 401 in Section 8 of [I-D.ietf-6tisch-minimal-security]. 403 To this end, the Configuration CBOR object [RFC7049] used as payload 404 of the Join Response Message and defined in Section 8.4.2 of 405 [I-D.ietf-6tisch-minimal-security] is extended with two new CoJP 406 parameters defined in this specification, namely 'permutation key 407 set' and 'permutation cipher'. The resulting payload of the Join 408 Response message is as follows. 410 Configuration = { 411 ? 2 : [ +Link_Layer_Key ], ; link-layer key set 412 ? 3 : Short_Identifier, ; short identifier 413 ? 4 : bstr, ; JRC address 414 ? 6 : [ *bstr ], ; blacklist 415 ? 7 : uint, ; join rate 416 ? TBD : [ +Permutation_Key ], ; permutation key set 417 ? TBD : Permutation_Cipher ; permutation cipher 418 } 420 The parameter 'permutation key set' is an array encompassing one or 421 two permutation keys encoded as byte strings. That is, the encoding 422 of each individual permutation key is as follows. 424 Permutation_Key = ( 425 key_value : bstr 426 ( 428 If the 6TiSCH network uses the security mechanism described in this 429 specification, the parameter 'permutation key set' MUST be included 430 in the CoJP Join Response message and the pledge MUST interpret it as 431 follows. 433 o In case only one permutation key is present, it is used as K_c to 434 permute the channelOffset utilization pattern as per Section 4. 436 o In case two permutation keys are present, the first one is used as 437 K_s to permute the timeslot utilization pattern, while the second 438 one is used as K_c to permute the channelOffset utilization 439 pattern, as per Section 4. The two keys MUST have the same 440 length. 442 The parameter 'permutation cipher' indicates the encryption algorithm 443 used for the secure pseudo-random number generator as per Figure 2 in 444 Section 4. The value is one of the encryption algorithms defined for 445 COSE [RFC8152], and is taken from Tables 9, 10 and 11 of [RFC8152]. 446 In case the parameter is omitted, the default value of AES-CCM- 447 16-64-128 (COSE algorithm encoding: 10) MUST be assumed. 449 5.1. Error Handling 451 In case 'permutation key set' includes two permutation keys with 452 different length or more than two permutation keys, the pledge 453 considers 'permutation key set' not valid and MUST signal the error 454 as specified in Section 8.3.1 of [I-D.ietf-6tisch-minimal-security]. 456 The pledge MUST validate that keys included in 'permutation key set' 457 are appropriate for the encryption algorithm specified in 458 'permutation cipher' or assumed as default. In case of failed 459 validation, the pledge MUST signal the error as specified in 460 Section 8.3.1 of [I-D.ietf-6tisch-minimal-security]. 462 6. Security Considerations 464 With reference to Section 3.9 of [RFC7554], this specification 465 achieves an additional "Secure Communication" objective, namely it 466 defines a mechanism to build and enforce a TSCH schedule which is 467 robust against selective jamming attack, while at the same time 468 consistent and collision-free. 470 Furthermore, the same security considerations from the minimal 471 security framework for 6TiSCH [I-D.ietf-6tisch-minimal-security] hold 472 for this document. The rest of this section discusses a number of 473 additional security considerations. 475 6.1. Effectiveness of Schedule Shuffling 477 The countermeasure defined in Section 4 practically makes each node's 478 schedule look random to an external observer. Hence, it prevents the 479 adversary from performing the attack described in Section 3. 481 Then, a still available strategy for the adversary is to jam a number 482 of cells selected at random, possibly on a per-slotframe basis. This 483 considerably reduces the attack effectiveness in successfully 484 jeopardizing victims' communications. 486 At the same time, nodes using different cells than the intended 487 victims' would experience an overall slightly higher fraction of 488 corrupted messages. In fact, the communications of such accidental 489 victims might be corrupted by the adversary, when they occur during a 490 jammed timeslot and exactly over the channelOffset chosen at random. 492 6.2. Renewal of Key Material 494 It is RECOMMENDED that the two permutation keys K_s and K_c are 495 revoked and renewed every time a node leaves the network. This 496 prevents a leaving node to keep the permutation keys, which may be 497 exploited to selectively jam communications in the network. 499 This rekeying operation is supposed to be performed anyway upon every 500 change of network membership, in order to preserve backward and 501 forward security. In particular, new IEEE 802.15.4 link-layer keys 502 are expected to be distributed before a new pledge can join the 503 network, or after one or more nodes have left the network. 505 The specific approach to renew the two permutation keys, possibly 506 together with other security material, is out of the scope of this 507 specification. 509 6.3. Static Timeslot Allocations 511 As mentioned in Section 4 and Section 5, it is possible to permute 512 only the channelOffset utilization pattern, while preserving the 513 originally scheduled timeslot utilization pattern. This can be 514 desirable, or even unavoidable in some scenarios, in order to 515 guarantee end-to-end latencies in multi-hop networks, as per 516 accordingly designed schedules. 518 However, it is NOT RECOMMENDED to preserve a static timeslot 519 utilization pattern, as this would considerably increase the attack 520 surface for a random jammer adversary. That is, the adversary would 521 immediately learn the timeslot utilization pattern of a victim node, 522 and would have a chance to successfully jam a victim's cell equal to 523 (1 / N_C). 525 6.4. Network Joining Through Randez-vous Cells 527 As described in [I-D.ietf-6tisch-minimal-security], a pledge joins a 528 6TiSCH network through a Join Proxy (JP), according to the 529 Constrained Join Protocol (CoJP) and based on the information 530 conveyed in broadcast Enhanced Beacons (EBs). In particular, the 531 pledge will communicate with the JP over randez-vous cells indicated 532 in the EBs. 534 In practice, such cells are commonly part of a separate slotframe, 535 which includes one scheduled "minimal cell" [RFC8180], typically used 536 also for broadcasting EBs. Such slotframe, i.e. Slotframe 0, usually 537 differs from the slotframe(s) used for both EBs and data 538 transmission. 540 In order to keep the join process feasible and deterministic, the 541 solution described in this specification is not applied to Slotframe 542 0 or any other slotframes that include randez-vous cells for joining. 543 As a consequence, an adversary remains able to selectively jam the 544 "minimal cell" (or any randez-vous cell used for joining), so 545 potentially jeopardizing the CoJP and preventing pledges to join the 546 network altogether. 548 7. IANA Considerations 550 This document has the following actions for IANA. 552 7.1. Permutation Key Set 554 IANA is asked to enter the following value into the "Constrained Join 555 Protocol Parameters Registry" defined in 556 [I-D.ietf-6tisch-minimal-security] and within the "IPv6 over the TSCH 557 mode of IEEE 802.15.4e (6TISCH) parameters" registry. 559 +-------------+-------+-------+------------------------+------------+ 560 | Name | Label | CBOR | Description | Reference | 561 | | | type | | | 562 +-------------+-------+-------|------------------------+------------| 563 | permutation | TBD | array | Identifies the array | [[this | 564 | key set | | | including one or two | document]] | 565 | | | | permutation keys to | | 566 | | | | alter cell utilization | | 567 +-------------|-------+-------+------------------------+------------| 569 7.2. Permutation Cipher 571 IANA is asked to enter the following value into the "Constrained Join 572 Protocol Parameters Registry" defined in 573 [I-D.ietf-6tisch-minimal-security] and within the "IPv6 over the TSCH 574 mode of IEEE 802.15.4e (6TISCH) parameters" registry. 576 +-------------+-------+---------+-----------------------+------------+ 577 | Name | Label | CBOR | Description | Reference | 578 | | | type | | | 579 +-------------+-------+---------|-----------------------+------------| 580 | permutation | TBD | integer | Identifies the cipher | [[this | 581 | cipher | | | used for generating | document]] | 582 | | | | pseudo-random numbers | | 583 | | | | to alter cell | | 584 | | | | utilization | | 585 +-------------|-------+---------+-----------------------+------------| 587 8. References 589 8.1. Normative References 591 [I-D.ietf-6tisch-minimal-security] 592 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 593 "Minimal Security Framework for 6TiSCH", draft-ietf- 594 6tisch-minimal-security-09 (work in progress), November 595 2018. 597 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 598 Requirement Levels", BCP 14, RFC 2119, 599 DOI 10.17487/RFC2119, March 1997, 600 . 602 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 603 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 604 October 2013, . 606 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 607 RFC 8152, DOI 10.17487/RFC8152, July 2017, 608 . 610 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 611 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 612 May 2017, . 614 8.2. Informative References 616 [I-D.ietf-6tisch-terminology] 617 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 618 "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", 619 draft-ietf-6tisch-terminology-10 (work in progress), March 620 2018. 622 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 623 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 624 Internet of Things (IoT): Problem Statement", RFC 7554, 625 DOI 10.17487/RFC7554, May 2015, 626 . 628 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 629 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 630 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 631 May 2017, . 633 [RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH 634 Operation Sublayer (6top) Protocol (6P)", RFC 8480, 635 DOI 10.17487/RFC8480, November 2018, 636 . 638 Acknowledgments 640 The authors sincerely thank Malisa Vucinic for the initial discussion 641 about this document. 643 The work on this document has been partly supported by the EIT- 644 Digital High Impact Initiative ACTIVE. 646 Authors' Addresses 648 Marco Tiloca 649 RISE AB 650 Isafjordsgatan 22 651 Kista SE-16440 Stockholm 652 Sweden 654 Email: marco.tiloca@ri.se 655 Simon Duquennoy 656 Yanzi Networks AB 657 Isafjordsgatan 32C 658 Kista SE-16440 Stockholm 659 Sweden 661 Email: simon.duquennoy@yanzinetworks.com 663 Gianluca Dini 664 University of Pisa 665 Largo L. Lazzarino 2 666 Pisa 56122 667 Italy 669 Email: gianluca.dini@unipi.it