idnits 2.17.1 draft-tiloca-6tisch-robust-scheduling-00.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 (June 29, 2018) is 2127 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-06 ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 1 error (**), 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 S. Duquennoy 4 Intended status: Standards Track RISE SICS 5 Expires: December 31, 2018 G. Dini 6 University of Pisa 7 June 29, 2018 9 Robust scheduling against selective jamming in 6TiSCH networks 10 draft-tiloca-6tisch-robust-scheduling-00 12 Abstract 14 This document defines a method to generate robust TSCH schedules in a 15 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4-2015) network, so as 16 to protect network nodes against selective jamming attack. Network 17 nodes independently compute the new schedule at each slotframe, by 18 altering the one originally available from 6top or alternative 19 protocols, while preserving a consistent and collision-free 20 communication pattern. This method can be added on top of the 21 minimal security framework for 6TiSCH. 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 http://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 December 31, 2018. 40 Copyright Notice 42 Copyright (c) 2018 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 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Properties of TSCH that simplify selective jamming . . . . . 3 60 3. Attack example . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Building robust schedules . . . . . . . . . . . . . . . . . . 6 62 5. Adaptation to the 6TiSCH minimal security framework . . . . . 8 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 6.1. Effectiveness of schedule shuffling . . . . . . . . . . . 9 65 6.2. Renewal of key material . . . . . . . . . . . . . . . . . 9 66 6.3. Static timeslot allocations . . . . . . . . . . . . . . . 9 67 6.4. Network joining through randez-vous cells . . . . . . . . 10 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 72 9.2. Informative References . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 Nodes in a 6TiSCH network communicate using the IEEE 802.15.4-2015 78 standard and its Timeslotted Channel Hopping (TSCH) mode. Some 79 properties of TSCH make schedule units, i.e. cells, and their usage 80 predictable, even if security services are used at the MAC layer. 82 This allows an external adversary to easy derive the communication 83 pattern of a victim node. After that, the adversary can perform a 84 selective jamming attack, by efficiently and effectively transmitting 85 over the only exact cell(s) in the victim's schedule. 87 This document describes a method to counteract such an attack. At 88 each slotframe, every node autonomously computes a TSCH schedule, as 89 a pseudo-random permutation of the one originally available from 6top 90 [I-D.ietf-6tisch-6top-protocol] or alternative protocols. 92 The resulting schedule is provided to TSCH and used to communicate 93 during the next slotframe. In particular, the new communication 94 pattern results unpredictable for an external adversary. Besides, 95 since all nodes compute the same pseudo-random permutation, the new 96 communication pattern remains consistent and collision-free. 98 Furthermore, this document specifies how this method can be added on 99 top of the minimal security framework for 6TiSCH described in 100 [I-D.ietf-6tisch-minimal-security]. 102 1.1. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in BCP 107 14 [RFC2119] [RFC8174] when, and only when, they appear in all 108 capitals, as shown here. 110 Readers are expected to be familiar with terms and concepts defined 111 in [I-D.ietf-6tisch-minimal-security], [I-D.ietf-6tisch-terminology] 112 and [RFC8152]. 114 This document refers also to the following terminology: 116 o Permutation key. A cryptographic key shared by network nodes and 117 used to permute schedules. Different keys are used to permute the 118 utilization pattern of timeslots and of channelOffsets. 120 2. Properties of TSCH that simplify selective jamming 122 This section highlights a number of properties of the TSCH cell usage 123 that greatly simplify the performance of the selective jamming attack 124 described in Section 3. 126 Given: 128 o The channel 'f' to communicate at timeslot 's' with ASN and 129 channelOffset 'chOff' computed as f = F[(ASN + chOff) mod N_C]; 131 And assuming for simplicity that: 133 o N_S and N_C are coprime values; 135 o The channel hopping sequence is N_C in size and equal to {0, 1, 136 ..., N_C - 1}; 138 Then, the following properties hold: 140 o Periodicity property. The sequence of channels used for 141 communication by a certain cell repeats with period (N_C x N_S) 142 timeslots. 144 o Usage property. Within a period, every cell uses all the 145 available channels, each of which only once. 147 o Offset property. All cells follow the same sequence of channels 148 with a certain offset. 150 o Predictability property. For each cell, the sequence of channels 151 is predictable. That is, by knowing the channel used by a cell in 152 a given timeslot, it is possible to compute the remaining channel 153 hopping sub-sequence. 155 In fact, given a cell active on channel 'f' and timeslot 's' on 156 slotframe 'T', and since ASN = (s + T x N_S), it holds that 158 f = [(s + T x N_S + c) mod N_C] (Eq. 1) 160 By solving this equation in 'c', one can predict the channels used 161 by the cell in the next sloframes. Note that, in order to do 162 that, one does not need to know the absolute number 'T' of the 163 slotframe (and thus the exact ASN) in which timeslot 's' uses a 164 certain channel 'f'. In fact, one can re-number slotframes 165 starting from any arbitrarily assumed "starting-slotframe". 167 3. Attack example 169 This section describes how an external adversary can exploit the 170 proterties in Section 2, and determine the full schedule of a victim 171 node, even if security services at the MAC layer are used. It is 172 also assumed that the victim node actually transmits/receives during 173 all its allocated cells at each slotframe. 175 The example considers Figure 1, where N_S = 3, N_C = 4, and the 176 channel hopping sequence is {0,1,2,3}. The shown schedule refers to a 177 network node that uses three cells 'L_1', 'L_2' and 'L_3', with 178 {0,3}, {1,1} and {2,0} as pairs {timeslot, channelOffset}, 179 respectively. 181 |==|===================================================================| 182 |Ch| ASN | 183 | |===================================================================| 184 |Of| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |10 |11 |12 |13 |14 |15 |16 | 185 |==|===================================================================| 186 |0 | | |f=2| | |f=1| | |f=0| | |f=3| | |f=2| | | 187 |--|-------------------------------------------------------------------| 188 |1 | |f=2| | |f=1| | |f=0| | |f=3| | |f=2| | |f=1| 189 |--|-------------------------------------------------------------------| 190 |2 | | | | | | | | | | | | | | | | | | 191 |--|-------------------------------------------------------------------| 192 |3 |f=3| | |f=2| | |f=1| | |f=0| | |f=3| | |f=2| | 193 |==|===================================================================| 194 | | | | | | | | | | | | | | | | | 195 |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 196 | | | | | | 197 | T = 0 | T = 1 | T = 2 | T = 3 | T = 4 | T = 5 198 | 199 \__ t = 0 201 Figure 1: Attack example with slotframe re-numbering 203 1. The adversary starts the attack at absolute slotframe T = 1, 204 which is assumed as "starting-slotframe" and thus renamed as 205 slotframe t = 0. The renaming is possible due to the offset and 206 predictability properties. 208 2. The adversary picks a channel 'f*' at random, and monitors it for 209 N_C consecutive slotframes to determine the timeslots in which 210 the victim node communicates on that channel. Due to the usage 211 property, the number of such timeslots is equal to the number of 212 cells assigned to the victim node. 214 With reference to Figure 1, if, for example, f* = 1, the 215 adversary determines that the victim node uses channel 'f*' in 216 timeslots s = 1 and s = 2 of slotframe t = 0 and in timeslot s = 217 0 of slotframe t = 1. The adversary can then deduce that the 218 victim node uses three different cells 'L_1', 'L_2' and 'L_3', in 219 timeslots 0, 1 and 2, respectively. 221 3. The adversary determines the channels on which the victim node is 222 going to transmit in the next slotframes, by exploiting the 223 predictability property. 225 That is, by instantiating Equation 1 for cell L_1, timeslot s = 0 226 and slotframe t = 1, one gets [1 = (3 + c_1) mod 4], which has 227 solution for c_1 = 2. Hence, the function to predict the channel 228 'f_1' to be used by cell 'L_1' in a slotframe 't', t >= 1, is f_1 229 = [(2 + 3 x t) mod 4], which produces the correct periodic 230 sequence of channels {1, 0, 3, 2}. Similarly, one can instantiate 231 Equation 1 for cells 'L_2' and 'L_3', so producing the respective 232 periodic sequence of channels {1,0,3,2} and {1,0,3,2}. 234 4. The adversary has discovered the full schedule of the victim node 235 and can proceed with the actual selective jamming attack. That 236 is, according to the found schedule, the adversary transmits over 237 the exact cells used by the victim node for transmission/ 238 reception, while staying quiet and saving energy otherwise. This 239 results in a highly effective, highly efficient and hard to 240 detect attack against communications of network nodes. 242 4. Building robust schedules 244 This section defines a method to protect network nodes against the 245 selective jamming attack described in Section 3. The proposed method 246 alters the communication pattern of all network nodes at every 247 slotframe, in a way unpredictable for an external adversary. 249 At each slotframe 'T', network nodes autonomously compute the 250 communication pattern for the next slotframe 'T+1' as a pseudo-random 251 permutation of the one originally available. In order to ensure that 252 the new communication pattern remains consistent and collision-free, 253 all nodes compute the same permutation of the original one. In 254 particular, at every slotframe, each node separately and 255 independently permutes its timeslot utilization pattern (optionally) 256 as well as its channelOffset utilization pattern. 258 To perform the required permutations, all network nodes rely on a 259 same secure pseudo-random number generator (SPRNG) as shown in 260 Figure 2, where E(x,y) denotes a cipher which encrypts a plaintext 261 'y' by means of a key 'x'. Network nodes MUST support the AES-CCM- 262 16-64-128 algorithm from [RFC8152]. 264 unsigned random(unsigned K, unsigned z) { 265 unsigned val = E(K,z); 266 return val; 267 } 269 Figure 2: Secure Pseudo-Random Number Generator 271 All network nodes share the same following pieces of information. 273 o K_s, a permutation key used to permute the timeslot utilization 274 pattern, and used as input to the random() function in Figure 2. 275 K_s is provided upon joining the network, and MAY be provided as 276 described in Section 5. 278 o K_c, a permutation key used to permute the channelOffset 279 utilization pattern, and used as input to the random() function in 280 Figure 2. K_c is provided upon joining the network, and MAY be 281 provided as described in Section 5. 283 o z_s, a counter used to permute the timeslot utilization pattern, 284 and used as input to the random() function in Figure 2. At the 285 beginning of each slotframe, z_s is equal to the ASN value of the 286 first timeslot of that slotframe. Then, z_s grows by N_S from the 287 beginning of a slotframe to the beginning of the next one. 289 o z_c, a counter used to permute the channelOffset utilization 290 pattern, and used as input to the random() function in Figure 2. 291 At the beginning of each slotframe, z_c is equal to [N_C x 292 floor(ASN* / N_S)], where ASN* is the ASN value of the first 293 timeslot of that slotframe. Then, z_c grows by N_C from the 294 beginning of a slotframe to the beginning of the next one. 296 Then, at every slotframe, each network node takes the following 297 steps, and generates its own permuted communication schedule to be 298 used at the following slotframe. The actual permutation of cells 299 relies on the well-known Fisher-Yates algorithm, that requires to 300 generate n pseudo-random numbers in order to pseudo-randomly shuffle 301 a vector of n elements. 303 1. First, a pseudo-random permutation is performed on the timeslot 304 dimension of the slotframe. This requires N_S invocations of 305 random(K,z), consistently with the Fisher-Yates algorithm. In 306 particular, K = K_s, while z_s is passed as second argument and 307 is incremented by 1 after each invocation. The result of this 308 step is a permuted timeslot utilization pattern, while the 309 channelOffset utilization pattern is not permuted yet. 311 2. Second, a pseudo-random permutation is performed on the 312 channelOffset dimension of the slotframe. This requires N_C 313 invocations of random(K,z), consistently with the Fisher-Yates 314 algorithm. In particular, K = K_c, while z_c is passed as second 315 argument and is incremented by 1 after each invocation. The 316 result of this step is a fully shuffled communication pattern. 318 The resulting schedule is then provided to TSCH and considered for 319 sending/receiving traffic during the next slotframe. 321 As further discussed in Section 6.3, it is possible, although NOT 322 RECOMMENDED, to skip step 1 above, and hence permute only the 323 channeOffset utilization pattern, while keeping a static timeslot 324 utilization pattern. 326 Note for implementation: the process described above can be 327 practically implemented by using two vectors, i.e. one for shuffling 328 the timeslot utilization pattern and one for shuffling the 329 channelOffset utilization pattern. 331 5. Adaptation to the 6TiSCH minimal security framework 333 The security mechanism described in this specification can be added 334 on top of the minimal security framework for 6TiSCH 335 [I-D.ietf-6tisch-minimal-security]. 337 That is, the two permutation keys K_s and K_c can be provided to a 338 pledge when performing 6TiSCH Join Protocol (6JP). To this end, the 339 payload of the Join Response defined in Section 9.2 of 340 [I-D.ietf-6tisch-minimal-security] is extended with a further 341 COSE_KeySet specified in [RFC8152]. 343 Specifically, this COSE_KeySet contains one or two permutations keys 344 and is interpreted as follows. If two keys are present, they are 345 used as K_s and K_c to permute the timeslot utilization pattern and 346 the channelOffset utilization pattern, respectively, as per 347 Section 4. Instead, if only one key is present, it is used as K_c to 348 permute the channelOffset utilization pattern as per Section 4. 350 The resulting payload of Join Responses becomes as follows: 352 response_payload = [ 353 COSE_KeySet, 354 short_address, 355 ? JRC_address : bstr, 356 ? COSE_KeySet, 357 ] 359 6. Security Considerations 361 With reference to Section 3.9 of [RFC7554], this specification 362 achieves an additional "Secure Communication" objective, namely it 363 defines a mechanism to build and enforce a TSCH schedule which is 364 robust against selective jamming attack, while at the same time 365 consistent and collision-free. 367 Furthermore, the same security considerations from the minimal 368 security framework for 6TiSCH [I-D.ietf-6tisch-minimal-security] hold 369 for this document. The rest of this section discusses a number of 370 additional security considerations. 372 6.1. Effectiveness of schedule shuffling 374 The countermeasure defined in Section 4 practically makes each node's 375 schedule look random to an external observer. Hence, it prevents the 376 adversary from performing the attack described in Section 3. 378 Then, a still available strategy for the adversary is to jam a number 379 of cells selected at random, possibly on a per-slotframe basis. This 380 considerably reduces the attack effectiveness in successfully 381 jeopardizing victims' communications. 383 At the same time, nodes using different cells than the intended 384 victims' would experience an overall slightly higher fraction of 385 corrupted messages. In fact, the communications of such accidental 386 victims might be corrupted by the adversary, when they occur during a 387 jammed timeslot and exactly over the channelOffset chosen at random. 389 6.2. Renewal of key material 391 It is RECOMMENDED that the two permutation keys K_s and K_c are 392 revoked and renewed every time a node leaves the network. This 393 prevents a leaving node to keep the permutation keys, which may be 394 exploited to selectively jam communications in the network. 396 This rekeying operation is supposed to be performed anyway upon every 397 change of network membership, in order to preserve backward and 398 forward security. In particular, new IEEE 802.15.4 link-layer keys 399 are expected to be distributed before a new pledge can join the 400 network, or after one ore more nodes have left the network. 402 The specific approach to renew the two permutation keys, possibly 403 together with other security material, is out of the scope of this 404 specification. 406 6.3. Static timeslot allocations 408 As mentioned in Section 4 and Section 5, it is possible to permute 409 only the channelOffset utilization pattern, while preserving the 410 originally scheduled timeslot utilization pattern. This can be 411 desirable, or even unavoidable in some scenarios, in order to 412 guarantee end-to-end latencies in multi-hop networks, as per 413 accordingly designed schedules. 415 However, it is NOT RECOMMENDED to preserve a static timeslot 416 utilization pattern, as this would considerably increase the attack 417 surface for a random jammer adversary. That is, the adversary would 418 immediately learn the timeslot utilization pattern of a victim node, 419 and would have a chance to successfully jam a victim's cell equal to 420 (1/N_C), where N_C is the number of available channelOffsets. 422 6.4. Network joining through randez-vous cells 424 As described in [I-D.ietf-6tisch-minimal-security], a pledge joins a 425 6TiSCH network through a Join Proxy (JP), according to 6TiSCH Join 426 Protocol (6JP) and based on the information conveyed in Enhanced 427 Beacons (EBs). In particular, the pledge will communicate with the 428 JP over indicated randez-vous cells. In practice, such cells are 429 typically part of a dedicate slotframe sequence, which is different 430 from the slotframe sequence used for EB and data transmission. 432 In order to keep the join process deterministic, the solution 433 described in this specification can not be applied to the slotframe 434 sequence with the randez-vous cells. That is, an adversary would 435 remain able to selectively jam the randez-vous cells, so potentially 436 jeopardizing the 6JP and preventing pledges to join altogether. 438 7. IANA Considerations 440 This document has no actions for IANA. 442 8. Acknowledgments 444 The authors sincerely thank Malisa Vucinic for the initial discussion 445 about this document. 447 The work on this document has been partly supported by the EIT- 448 Digital High Impact Initiative ACTIVE. 450 9. References 452 9.1. Normative References 454 [I-D.ietf-6tisch-minimal-security] 455 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 456 "Minimal Security Framework for 6TiSCH", draft-ietf- 457 6tisch-minimal-security-06 (work in progress), May 2018. 459 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 460 Requirement Levels", BCP 14, RFC 2119, 461 DOI 10.17487/RFC2119, March 1997, . 464 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 465 RFC 8152, DOI 10.17487/RFC8152, July 2017, 466 . 468 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 469 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 470 May 2017, . 472 9.2. Informative References 474 [I-D.ietf-6tisch-6top-protocol] 475 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 476 Operation Sublayer Protocol (6P)", draft-ietf-6tisch-6top- 477 protocol-12 (work in progress), June 2018. 479 [I-D.ietf-6tisch-terminology] 480 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 481 "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", 482 draft-ietf-6tisch-terminology-10 (work in progress), March 483 2018. 485 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 486 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 487 Internet of Things (IoT): Problem Statement", RFC 7554, 488 DOI 10.17487/RFC7554, May 2015, . 491 Authors' Addresses 493 Marco Tiloca 494 RISE SICS 495 Isafjordsgatan 22 496 Kista SE-16440 Stockholm 497 Sweden 499 Email: marco.tiloca@ri.se 501 Simon Duquennoy 502 RISE SICS 503 Isafjordsgatan 22 504 Kista SE-16440 Stockholm 505 Sweden 507 Email: simon.duquennoy@ri.se 508 Gianluca Dini 509 University of Pisa 510 Largo L. Lazzarino 2 511 Pisa 56122 512 Italy 514 Email: gianluca.dini@unipi.it