idnits 2.17.1 draft-aanchal-time-implementation-guidance-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 (October 22, 2018) is 2013 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'CLOCKDRIFT' is defined on line 319, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 329, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Malhotra 3 Internet-Draft Boston University 4 Intended status: Informational K. Teichel 5 Expires: April 25, 2019 PTB 6 M. Hoffmann 7 W. Toorop 8 NLnet Labs 9 October 22, 2018 11 On Implementing Time 12 draft-aanchal-time-implementation-guidance-01 14 Abstract 16 This document describes the properties of different types of clocks 17 available on digital systems. It provides implementors of 18 applications with guidance on choices they have to make when working 19 with time to provide basic functionality and security guarantees. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 25, 2019. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 1. Introduction 55 It is hard to understate the importance of time in modern digital 56 systems. The functionality and security of applications (distributed 57 or local to one system) and that of network protocols generally hinge 58 on some notion of time. For implementation, these applications and 59 protocols have to choose one of the types of clocks available on 60 their system, each of which has its own specific properties. 61 However, currently many of these applications seem to be oblivious to 62 the implications of choosing one or the other clock for 63 implementation. This behavior can be attributed to: a) the lack of 64 clear understanding of the distinct properties of these clocks, b) 65 trade-offs of using one or the other for an application, and c) 66 availability and compatibility of these clocks on different systems. 67 This document discusses a) and b). 69 More specifically, in this document we first define different methods 70 used by protocols and applications to express time. We then define 71 properties of clocks maintained by modern digital systems. Next we 72 describe how systems obtain these values from these clocks and the 73 security considerations of using these values to implement protocols 74 and applications that use time. Finally we discuss trade-offs 75 between security and precision of choosing a clock. The document 76 aims to provide guidance to the implementors make an informed choice 77 with an example of POSIX system. 79 2. Scope of the document 81 This document aims to provide software developers implementing 82 protocols and applications that have to deal with time with the 83 knowledge and understanding to make informed decisions regarding the 84 available clocks and their respective trade-offs. 86 It does not describe functionality that is specific to the 87 architecture of a PC, or other devices such as phones, IoT devices, 88 switches, routers, base stations, or synchrophasors. Nor is the 89 document applicable to a specific operating system. Throughout the 90 document we assume that one or the other clock is available on most 91 devices. How these clocks are available on different PCs or other 92 devices is out of scope of this document. 94 We do not exactly recommend which clock should be used. We discuss 95 the available options and trade-offs. The final decision would vary 96 depending on the availability of clocks and the security requirements 97 of the specific application under implementation. 99 Note: Since there is a lack of standards on terminology related to 100 time, we define some terms in the following section. Also, 101 throughout the document, we define the terms as they become relevant. 102 Different systems, depending on their OS, may use different terms for 103 the same types of clocks. A survey on this is not in the scope of 104 this document. We provide a discussion on how to access these values 105 on POSIX and Windows systems. On other systems, implementors will 106 have to determine themselves which of these values are available. 108 3. Expressing Time 110 Protocols and applications can express time in several forms, 111 depending on whether they need to express a point in time or a time 112 interval. 114 3.1. Absolute Time 116 Absolute time expresses a universally agreed upon reference to a 117 specific point in time. Such a reference can be expressed in 118 different ways. For instance, Unix Time refers to the number of 119 seconds since midnight UTC, January 1st, 1970, while in everyday 120 life, we reference such a point through year, month, day, and so on. 122 Because absolute time expresses a shared view of time, a system needs 123 to synchronize its clock with a common reference clock, for instance 124 one based on UTC. 126 Absolute time is often used to express the start or end of the 127 validity of objects with a limited lifetime that are shared over the 128 network. 130 3.2. Relative Time 132 Relative time measures the time interval that has elapsed from some 133 well-defined reference point (e.g., 20 minutes from the time of your 134 query). 136 Since relative time does not express a point in time, it does not 137 rely on synchronized clocks between systems but only on a shared rate 138 of passage of this time. 140 Relative time is commonly used in network protocols, for instance to 141 determine when a packet should be considered dropped or to express 142 Time To Live (TTL) values that govern the length of time for which an 143 object is valid or usable. 145 4. Keeping Time: Different Clocks 147 Because time is relative to an observer, there cannot be a 148 universally agreed upon time. At best we can achieve an 149 approximation by constantly updating our own clocks against a common 150 reference clock. Remaining close to this reference clock is a 151 complex process that comes with its own set of difficulties. 153 In this section, we will have a look at the different clocks a system 154 uses and how it maintains these clocks. 156 4.1. Native Clock 158 Each system has its own perception of time. It gains access to it 159 via its native clock. Typcially, this clock counts cycles of an 160 oscillator but some systems use process CPU times or thread CPU 161 timers (via timers provided by the CPU). The quality of the native 162 clock therefore dependends on either the stability of the oscillator 163 or the CPU timer. 165 The timescale of the native clock is purely subjective -- no general 166 meaning can be attached to any specific clock value. One can only 167 obtain relative time by comparing two values. Because the value of 168 the native clock always grows at a steady pace, never decreases, 169 never make unexpected jumps, and never skips, the difference between 170 two clock values provides the time interval between the two 171 measurements. 173 The independence of the native clock from any external time sources 174 renders it resistant to any manipulation but in return there is no 175 guarantee that its clock rate is similar to that of any other system. 176 This difference in rate, especially when compared to a reference 177 clock, is called clock drift. 179 Clock drift depends on the quality of the clock itself but also on 180 factors such as system load or ambient temperatur which makes it hard 181 to predict. 183 4.2. World Clock 185 The native clock only provides means to measure relative time. In 186 order to be able to also process absolute time, the system needs to 187 be synchronized with a global reference clock. Since this clock 188 strives to be the same on all systems, we call it the world clock. 190 There are a number of ways to maintain the world clock based on the 191 system's native clock. 193 The first is to manually maintain an offset between values of the 194 native clock and the reference world clock. Because of the clock 195 drift of the native clock, this offset needs to be updated from time 196 to time if a minimal divergence from the reference clock is to be 197 maintained. 199 Secondly, a hardware clock provided by the system and set to be 200 equivalent to the reference time can be used, allowing the system to 201 retain the offset across reboots. 203 Finally, the reference clock can be obtained from an external time 204 source. Typically, the Internet is used through a variety of timing 205 protocols including the Network Time Protocol (NTP) [RFC5905], 206 Chrony, SNTP, OpenNTP and others. 208 Each of these approaches has own problems attached to it. 210 Manual configurations can be subject to errors and misconfiguration. 211 Also, for mobile devices, when moving between time zones, the offset 212 must be corrected manually. 214 Accessing the hardware clock requires an I/O operation which is 215 resource intensive, therefore many systems use the hardware clock 216 only upon reboot, to initialize the clock offset; subsequent updates 217 are made either manually or through timing protocols. 219 Further, on many systems the quality of the hardware clock isn't very 220 high, leading to a large clock drift if solely relying on it. Worse, 221 systems like microcontrollers that operate within embedded systems 222 (e.g., Raspberry Pi, Arduino, etc.) often lack hardware clocks 223 altogether. These systems rely on external time sources upon reboot 224 and have no means to process absolute time until synchronization with 225 these sources has completed. 227 Relying on Internet timing protocols opens up the system time to 228 attack. Recent papers show vulnerabilities in NTP [SECNTP], [MCBG] 229 and SNTP that allow attackers to maliciously alter system's world 230 clock -- pushing it into the past or even into the future. Moreover, 231 many of these time-shifting attacks can be performed by off-path 232 attackers, who do not occupy a privileged position on the network 233 between the victim system and its time sources on the Internet. 234 Researchers have also demonstrated off-path denial of service attacks 235 on timing protocols that prevent systems from synchronizing their 236 clocks. 238 In other words, the process of obtaining the offset necessary to 239 provide a world clock creates dependencies that can be exploited. 241 5. Implementation Approaches 243 Because absolute time relies on a shared interpretation of a value 244 expressing time, the world clock is necessary when processing such 245 values. 247 For relative time, however, where only the rate of passage of time 248 needs to be close enough to that of the other systems involved, there 249 is no need to rely on the world clock when determining whether an 250 interval has passed. 252 Instead, by obtaining a value from the native clock when the interval 253 has started only the native clock is necessary to determine when this 254 interval ends. As the native clock does not rely on any external 255 time sources, the implementation becomes resistant to the 256 difficulties of coordinating with these sources. 258 However, using the native clock in this way comes with a caveat. 259 Since the native clock is not subject to any adjustments by timing 260 protocols, it is not adjusted for the error introduced by clock 261 drift. While this is likely of little consequence for short 262 intervals, it may become significant for intervals that span long 263 periods of time. 265 Consequently, the choice of clock to be used is application-specific. 266 If applications can tolerate a certain amount of clock drift or if 267 the time intervals are short, implementers may prefer using the 268 native clock. If the application relies on precise timing over long 269 periods one has no choice but to fall back to the world clock. 271 6. Accessing the Native Clock on Selected Operating Systems 273 In most operating systems, the standard functions to access time use 274 the world clock since that is normally what users would expect. This 275 section provides an overview how the native clock can be accesses on 276 some common operating systems. 278 6.1. POSIX 280 POSIX defines a system C API function which may provide native time: 281 clock_gettime(), when used with a clock_id of CLOCK_MONOTONIC (when 282 supported by the system). POSIX does not make a distinction between 283 raw time and adjusted raw time in the definition of this function. 284 Beware that, with some systems, CLOCK_MONOTONIC deliveres adjusted 285 raw time and that CLOCK_MONOTONIC_RAW needs to be used as clock_id to 286 get unadjusted raw time. Non-POSIX systems may provide different 287 APIs. 289 6.2. Microsoft Windows 291 In the Microsoft Windows operating system, native time is called 292 'Windows Time' and can be accessed through the GetTickCount and 293 GetTickCount64 API functions. The returned value is normally the 294 number of milliseconds since system start. GetTickCount will return 295 a 32 bit value while GetTickCount64 returns a value 64 bits wide that 296 will wrap around less often. 298 7. Acknowledgements 300 We are thankful to Sharon Goldberg and Benno Overreinder for useful 301 discussions. 303 8. IANA Considerations 305 This memo includes no request to IANA. 307 9. Security Considerations 309 Time is a fundamental component for the security guarantees claimed 310 by various applications. A system that uses a time distribution 311 protocol may be affected by the security aspects of the time 312 protocol. The security considerations of time protocols in general 313 are discussed in [RFC7384]. This document discusses the security 314 considerations with respect to implementing time values in 315 applications in various sections. 317 10. Informative References 319 [CLOCKDRIFT] 320 Marouani, H. and M. Dagenais, "Internal clock drift 321 estimation in computer clusters", 2008, 322 . 325 [MCBG] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg, 326 "Attacking the Network Time Protocol", 2015, 327 . 329 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 330 Housley, R., and W. Polk, "Internet X.509 Public Key 331 Infrastructure Certificate and Certificate Revocation List 332 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 333 . 335 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 336 "Network Time Protocol Version 4: Protocol and Algorithms 337 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 338 . 340 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 341 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 342 October 2014, . 344 [SECNTP] Malhotra, A., Gundy, M., Varia, M., Kennedy, H., Gardner, 345 J., and S. Goldberg, "The Security of NTP's Datagram 346 Protocol", 2016, . 348 Authors' Addresses 350 Aanchal Malhotra 351 Boston University 352 111 Cummington Mall 353 Boston 02215 354 USA 356 Email: aanchal4@bu.edu 358 Kristof Teichel 359 Physikalisch-Technische Bundesanstalt 360 Bundesallee 100 361 Braunschweig D-38116 362 Germany 364 Email: kristof.teichel@ptb.de 366 Martin Hoffmann 367 NLnet Labs 368 Science Park 400 369 Amsterdam 1098 XH 370 Netherlands 372 Email: martin@nlnetlabs.nl 373 Willem Toorop 374 NLnet Labs 375 Science Park 400 376 Amsterdam 1098 XH 377 Netherlands 379 Email: willem@nlnetlabs.nl