idnits 2.17.1 draft-vilajosana-6tisch-globaltime-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 19, 2018) is 2138 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) == Unused Reference: 'RFC6690' is defined on line 344, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-6tisch-minimal-security-06 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Downref: Normative reference to an Informational RFC: RFC 7554 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-14 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH X. Vilajosana, Ed. 3 Internet-Draft P. Tuset 4 Intended status: Standards Track B. Martinez 5 Expires: December 21, 2018 Universitat Oberta de Catalunya 6 J. Munoz 7 Inria 8 June 19, 2018 10 Global Time Distribution in 6TiSCH Networks 11 draft-vilajosana-6tisch-globaltime-01 13 Abstract 15 This specification defines an optional extension to the Constrained 16 Join Protocol (CoJP) defined by the Minimal Security Framework for 17 6TiSCH. The extension aims at providing global time distribution 18 support so nodes in the 6TiSCH network can exploit global time 19 information instead of relying only in relative network time based on 20 the Absolute Sequence Number (ASN). The specification also defines a 21 mechanism for resynchronization, to handle leap seconds or to enable 22 periodic global time updates relying on a CoAP service. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 28 "OPTIONAL" in this document are to be interpreted as described in 29 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on December 21, 2018. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Global Time Source . . . . . . . . . . . . . . . . . . . . . 3 67 3. Global Time Extension to the Join Response . . . . . . . . . 4 68 4. Resynchronization . . . . . . . . . . . . . . . . . . . . . . 7 69 5. Leap Second handling . . . . . . . . . . . . . . . . . . . . 8 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 7.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 Time Synchronized Channel Hopping (TSCH) exploits node 79 synchronization to build up deterministic access networks through 80 scheduling [RFC7554]. 6TiSCH defines a control plane architecture to 81 enable IEEE802.15.4 TSCH networks to securely bootstrap and in a 82 distributed manner self-organize in order to meet application traffic 83 needs [I-D.ietf-6tisch-architecture]. The synchronization accuracy 84 between the nodes' clocks in a 6TiSCH network is dependent on the 85 network maintenance traffic (Keep Alives), application traffic, and 86 MAC layer guard time duration. It is well-known that, for a given 87 traffic, the smaller the guard time, the smaller the tolerated drift 88 between two nodes, and hence, the more precise their synchronization. 90 The concept of network synchronization is achieved through a virtual 91 counter referred as Absolute Sequence Number (ASN). In a 6TiSCH 92 network, each node updates its ASN at every slot, giving the nodes 93 the same notion of time (with timeslot granularity). This time is 94 relative to the moment the network started or reset and hence cannot 95 be used to compare tagged events from different networks. 97 This document defines a data structure to map ASN and absolute time. 98 The document then defines the procedure to transport the structure to 99 the 6TiSCH nodes: 101 o As an optional extension to the Constrained Join Protocol (CoJP) 102 Join Response procedure within the Minimal Security Framework for 103 6TiSCH [I-D.ietf-6tisch-minimal-security]. 104 o As a CoAP Response [RFC7252] to a global time service exposed by 105 the Join Registrar/Cordinator (JRC). 107 2. Global Time Source 109 In order to distribute global time information in a 6TiSCH network at 110 least one component must be acting as a global time source and 111 enabling nodes in the network to obtain the absolute time reference 112 from it. The way global time is obtained and maintained in this 113 network component is out of scope of this specification. As an 114 example, this component can account for the global time in the 115 network internally, can use an external source to obtain global time 116 (e.g. GPS, NTP [RFC5905]) or, can be synchronized through a 117 precision time protocol (PTP) such the IEEE-1588 [IEEE1588] to 118 another network. 120 We use the example network in Figure 1 throughout this specification 121 for illustration. The Join Registrar/Coordinator (JRC) acts as the 122 global time information source for a node when it joins. How the JRC 123 obtains such global time information is out of scope of this 124 specification. The JRC can be a component outside of the 6TiSCH 125 network. However it is required to be synchronize to it through the 126 ASN. How the JRC obtains such synchronization to the 6TiSCH network 127 is out of the scope of this specification. This specification 128 defines how the JRC formats and distributes the absolute time 129 reference to the 6TiSCH nodes in the network. 131 ---+-------- ............ 132 | External Network 133 | NTP/GPS/PTP 134 +-----+ 135 | | LLN Border 136 | | router/JRC/global 137 +-----+ time source 138 o o o 139 o o o o o 140 JP o o 6TiSCH o o 141 | o o o o 142 x o o 143 Pledge 145 Figure 1: An example network 147 A Pledge node obtains its global time reference during the Secure 148 Join Process with the JRC [I-D.ietf-6tisch-minimal-security]. This 149 specification extends the Join Response message with an optional data 150 structure which includes the global time reference and optionally the 151 period for absolute time updates. 153 The global time reference is a mapping between the ASN of the network 154 and the global time at the moment of processing the Join Response. 155 After having obtained the global time reference, a 6TiSCH node 156 maintains internally its timing until it updates it, resets or is 157 disconnected from the network. Optionally, periodic refresh messages 158 can be issued by the 6TiSCH node to the JRC using the JRC URI 159 exposing the time service. These optional refresh messages MAY be 160 used to cope with the clock drift caused by any possible imprecision 161 between the configured timeslot length and the actual timeslot 162 length. As an example, a timeslot can be configured to be 10ms long 163 but because of the nature of the crystal in the device the timeslot 164 becomes 10.1ms. 166 3. Global Time Extension to the Join Response 168 This document extends the Join Response message within the 169 Constrained Join Protocol (CoJP) defined in 170 [I-D.ietf-6tisch-minimal-security] with: 172 o A byte string containing the ASN at which the CoAP Response (e.g, 173 Join Response) is processed at the JRC. The 5-byte ASN is carried 174 in network byte order. 175 o An 8-bit unsigned integer containing an era counter. The era 176 counter is used to account for wraps of the seconds counter. It 177 starts at 0 and increments approximately every 136 years as per 178 definition of era in NTP [RFC5905]. Era 0 starts at 0h UTC 1st of 179 January 1900. 180 o A 32-bit unsigned integer containing a timestamp in seconds, 181 captured at the beginning of the timeslot at which the CoAP 182 Response (e.g. Join Response) is processed. Carried in network 183 byte order. The seconds and fraction fields are based on the 184 specification described in the NTP standard [RFC5905] for the 185 Timestamp format. The seconds field accounts for seconds elapsed 186 since the 0h on the 1 January 1900 UTC, as described by the NTP 187 standard [RFC5905]. 188 o A 32-bit unsigned integer containing the number of picoseconds 189 elapsed after the last entire second at the beginning of the 190 timeslot at which the CoAP Response (e.g. Join Response) is 191 processed. Carried in network byte order. Its granularity is 192 described in the NTP standard [RFC5905]. 193 o Optionally, a byte string encoding a global time service URI in 194 core-link format. The default value is 'gt'. 195 o Optionally, an unsigned word lease value indicating the number of 196 minutes of freshness of the assigned global time information. If 197 this value is not provided the lease time is considered to be 198 infinite. If this value is 0, a node does not refresh the global 199 time information. 201 global_time_option = { 202 0 : bstr, ; ASN 203 1 : uint8, ; era counter 204 2 : uint32 ; seconds counter 205 3 : uint32 ; fraction 206 ? 4 : bstr ; gt_service 207 ? 5 : uint16 ; gt_lease 208 } 209 +------------+-------+----------+------------+ 210 | Name | Label | CBOR | Reference | 211 | | | type | | 212 +------------+-------+----------+------------+ 213 | ASN | 0 | byte | [[this | 214 | | | string | document]] | 215 | | | | | 216 | era | 1 | unsigned | [[this | 217 | counter | | integer | document]] | 218 | | | (uint8) | | 219 | | | | | 220 | seconds | 2 | unsigned | [[this | 221 | counter | | integer | document]] | 222 | | | (uint32) | | 223 | | | | | 224 | fraction | 3 | unsigned | [[this | 225 | | | integer | document]] | 226 | | | (uint32) | | 227 | | | | | 228 | gt_service | 4 | byte | [[this | 229 | (optional) | | string | document]] | 230 | | | | | 231 | | | | | 232 | gt_lease | 5 | unsigned | [[this | 233 | (optional) | | integer | document]] | 234 | | | (uint16) | | 235 +------------+-------+----------+------------+ 237 To take into account possible leap seconds. An optional 238 leap_second_option is defined by: 240 o An 8-bit unsigned integer containing the action to be performed 241 when the next leap second day is reached. 242 o A 16-bit unsigned integer containing an offset in days to the 243 beginning of the day (0 h UTC) when the next leap second must be 244 applied. Carried in network byte order. 246 leap_second_option = { 247 0 : uint8, ; leap_indicator 248 1 : uint16, ; leap_offset 249 } 250 +----------------+-------+----------+------------+ 251 | Name | Label | CBOR | Reference | 252 | | | type | | 253 +----------------+-------+----------+------------+ 254 | leap_indicator | 0 | unsigned | [[this | 255 | | | integer | document]] | 256 | | | (uint8) | | 257 | | | | | 258 | leap_offset | 1 | unsigned | [[this | 259 | | | integer | document]] | 260 | | | (uint16) | | 261 +----------------+-------+----------+------------+ 263 The optional leap_second_option defines a leap second indicator, 264 which identifies the type of correction that needs to be applied once 265 the next leap second day is reached. The types are described in 266 Figure 9 of the RFC5905 [RFC5905]. 268 A leap_offset contains the offset in days to when the next leap 269 second needs to be applied, following the action described in the 270 leap second indicator. 272 The global_time_option and the leap_second_option, if present, SHOULD 273 be appended following the Join Response Payload and MUST be encoded 274 as a CBOR map objects [RFC7049]. 276 4. Resynchronization 278 When a pledge receives the Join Response containing the 279 global_time_option, it updates its internal absolute time clock/ 280 counter. If present, it also stores the gt_service link-format URI 281 and the lease time. 283 After correcting a leap second or when the lease period is reached, a 284 node MAY want to update the global time information values to keep 285 track of the next leap second correction event or to renew its global 286 time synchronization lease. This resynchronization is conducted 287 through a CoAP GET Request to the JRC address and gt_service URI. 289 o The request method is GET. 290 o The type is Non-confirmable (NON). 291 o The Proxy-Scheme option is set to "coap". 292 o The Uri-Host option is defined by the JRC URI. 293 o The Uri-Path option is set to gt_service. 294 o The payload is empty. 296 The response is a CoAP Response Message with Response Code 2.05 297 (Content) containing the global_time_option as payload. The response 298 MAY contain a leap_second_option in case a leap second update is 299 needed. Both options if present are encoded as CBOR dictionaries. 301 5. Leap Second handling 303 When a 6TiSCH node receives a global time synchronization message and 304 this response contains a leap_second_option, the node MUST store the 305 values until the leap second offset is reached. 307 When a leap second offset is reached, the leap second is corrected 308 adding or substracting a second to the last minute of the day as 309 indicated by the leap_indicator field. 311 6. Security Considerations 313 The global time synchronization option is transported as part of the 314 payload of the 6P Join Response message and secured by OSCORE (Object 315 Security for Constrained RESTful Environments) as per 316 [I-D.ietf-6tisch-minimal-security]. Since the JRC acts as the global 317 time synchronization server, comprimising the JRC will result in a 318 compromise of the transported information. 320 A malicious 6N attacker may use a short lease time to generate high 321 volumes of traffic in the network or even to try to denial the 322 service to the JRC. Is up to the JRC to implement temporal 323 blacklisting policies to avoid any DoS attack. 325 7. References 327 7.1. Normative References 329 [I-D.ietf-6tisch-minimal-security] 330 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 331 "Minimal Security Framework for 6TiSCH", draft-ietf- 332 6tisch-minimal-security-06 (work in progress), May 2018. 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, 336 DOI 10.17487/RFC2119, March 1997, 337 . 339 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 340 "Network Time Protocol Version 4: Protocol and Algorithms 341 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 342 . 344 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 345 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 346 . 348 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 349 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 350 October 2013, . 352 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 353 Application Protocol (CoAP)", RFC 7252, 354 DOI 10.17487/RFC7252, June 2014, 355 . 357 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 358 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 359 Internet of Things (IoT): Problem Statement", RFC 7554, 360 DOI 10.17487/RFC7554, May 2015, 361 . 363 7.2. Informative References 365 [I-D.ietf-6tisch-architecture] 366 Thubert, P., "An Architecture for IPv6 over the TSCH mode 367 of IEEE 802.15.4", draft-ietf-6tisch-architecture-14 (work 368 in progress), April 2018. 370 [IEEE1588] 371 IEEE standard for Information Technology, "IEEE Standard 372 for a Precision Clock Synchronization Protocol for 373 Networked Measurement and Control Systems," in IEEE Std 374 1588-2008 (Revision of IEEE Std 1588-2002) , vol., no., 375 pp.1-300", July 2008. 377 Authors' Addresses 379 Xavier Vilajosana (editor) 380 Universitat Oberta de Catalunya 381 156 Rambla Poblenou 382 Barcelona, Catalonia 08018 383 Spain 385 Email: xvilajosana@uoc.edu 386 Pere Tuset 387 Universitat Oberta de Catalunya 388 156 Rambla Poblenou 389 Barcelona, Catalonia 08018 390 Spain 392 Email: peretuset@uoc.edu 394 Borja Martinez 395 Universitat Oberta de Catalunya 396 156 Rambla Poblenou 397 Barcelona, Catalonia 08018 398 Spain 400 Email: bmartinezh@uoc.edu 402 Jonathan Munoz 403 Inria 404 2 rue Simone Iff 405 Paris 75012 406 France 408 Email: jonathan.munoz@inria.fr