< draft-aanchal-time-implementation-guidance-01.txt   draft-aanchal-time-implementation-guidance-02.txt >
Internet Engineering Task Force A. Malhotra NTP Working Group A. Malhotra
Internet-Draft Boston University Internet-Draft Boston University
Intended status: Informational K. Teichel Intended status: Informational K. Teichel
Expires: April 25, 2019 PTB Expires: January 9, 2020 PTB
M. Hoffmann M. Hoffmann
W. Toorop W. Toorop
NLnet Labs NLnet Labs
October 22, 2018 July 8, 2019
On Implementing Time On Implementing Time
draft-aanchal-time-implementation-guidance-01 draft-aanchal-time-implementation-guidance-02
Abstract Abstract
This document describes the properties of different types of clocks This document describes the properties of different types of clocks
available on digital systems. It provides implementors of available on digital systems. It provides implementors of
applications with guidance on choices they have to make when working applications with guidance on choices they have to make when working
with time to provide basic functionality and security guarantees. with time to provide basic functionality and security guarantees.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Scope of the document . . . . . . . . . . . . . . . . . . . . 3
3. Expressing Time . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Absolute Time . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Relative Time . . . . . . . . . . . . . . . . . . . . . . 4
4. Keeping Time: Different Clocks . . . . . . . . . . . . . . . 4
4.1. Native Clock . . . . . . . . . . . . . . . . . . . . . . 4
4.2. World Clock . . . . . . . . . . . . . . . . . . . . . . . 5
5. Implementation Approaches . . . . . . . . . . . . . . . . . . 6
6. Accessing the Native Clock on Selected Operating Systems . . 7
6.1. POSIX . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.2. Microsoft Window . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
It is hard to understate the importance of time in modern digital It is hard to overstate the importance of time in modern digital
systems. The functionality and security of applications (distributed systems. The functionality and security of applications (distributed
or local to one system) and that of network protocols generally hinge or local to one system) and that of network protocols generally hinge
on some notion of time. For implementation, these applications and on some notion of time. For implementation, these applications and
protocols have to choose one of the types of clocks available on protocols have to choose one of the types of clocks available on
their system, each of which has its own specific properties. their system, each of which has its own specific properties.
However, currently many of these applications seem to be oblivious to However, currently many of these applications seem to be oblivious to
the implications of choosing one or the other clock for the implications of choosing one or the other clock for
implementation. This behavior can be attributed to: a) the lack of implementation. This behavior can be attributed to:
clear understanding of the distinct properties of these clocks, b)
trade-offs of using one or the other for an application, and c) a. the lack of clear understanding of the distinct properties of
availability and compatibility of these clocks on different systems. these clocks,
b. trade-offs of using one or the other for an application, and
c. availability and compatibility of these clocks on different
systems.
This document discusses a) and b). This document discusses a) and b).
More specifically, in this document we first define different methods More specifically, in this document we first define different methods
used by protocols and applications to express time. We then define used by protocols and applications to express time. We then define
properties of clocks maintained by modern digital systems. Next we properties of clocks maintained by modern digital systems. Next we
describe how systems obtain these values from these clocks and the describe how systems obtain these values from these clocks and the
security considerations of using these values to implement protocols security considerations of using these values to implement protocols
and applications that use time. Finally we discuss trade-offs and applications that use time. Finally we discuss trade-offs
between security and precision of choosing a clock. The document between security and precision of choosing a clock. The document
aims to provide guidance to the implementors make an informed choice aims to provide guidance to the implementors make an informed choice
skipping to change at page 3, line 28 skipping to change at page 4, line 11
Protocols and applications can express time in several forms, Protocols and applications can express time in several forms,
depending on whether they need to express a point in time or a time depending on whether they need to express a point in time or a time
interval. interval.
3.1. Absolute Time 3.1. Absolute Time
Absolute time expresses a universally agreed upon reference to a Absolute time expresses a universally agreed upon reference to a
specific point in time. Such a reference can be expressed in specific point in time. Such a reference can be expressed in
different ways. For instance, Unix Time refers to the number of different ways. For instance, Unix Time refers to the number of
seconds since midnight UTC, January 1st, 1970, while in everyday seconds since midnight UTC, January 1st, 1970, while in everyday
life, we reference such a point through year, month, day, and so on. life, we referenced such a point through year, month, day, and so on.
Because absolute time expresses a shared view of time, a system needs Because absolute time expresses a shared view of time, a system needs
to synchronize its clock with a common reference clock, for instance to synchronize its clock with a common reference clock, for instance
one based on UTC. one base on UTC.
Absolute time is often used to express the start or end of the Absolute time is often used to express the start or end of the
validity of objects with a limited lifetime that are shared over the validity of objects with a limited lifetime that are shared over the
network. network.
3.2. Relative Time 3.2. Relative Time
Relative time measures the time interval that has elapsed from some Relative time measures the time interval that has elapsed from some
well-defined reference point (e.g., 20 minutes from the time of your well-defined reference point (e.g., 20 minutes from the time of your
query). query).
Since relative time does not express a point in time, it does not
rely on synchronized clocks between systems but only on a shared rate
of passage of this time.
Relative time is commonly used in network protocols, for instance to Relative time is commonly used in network protocols, for instance to
determine when a packet should be considered dropped or to express determine when a packet should be considered dropped or to express
Time To Live (TTL) values that govern the length of time for which an Time To Live (TTL) values that govern the length of time for which an
object is valid or usable. object is valid or usable.
4. Keeping Time: Different Clocks Since relative time does not express a point in time, it does not
rely on synchronized clocks between systems but only on a shared
clock rate.
Because time is relative to an observer, there cannot be a 4. Keeping Time: Different Clocks
universally agreed upon time. At best we can achieve an
approximation by constantly updating our own clocks against a common
reference clock. Remaining close to this reference clock is a
complex process that comes with its own set of difficulties.
In this section, we will have a look at the different clocks a system In this section, we will have a look at the different clocks a system
uses and how it maintains these clocks. uses and how it maintains these clocks
4.1. Native Clock 4.1. Native Clock
Each system has its own perception of time. It gains access to it Each system has its own perception of time. It gains access it via
via its native clock. Typcially, this clock counts cycles of an its native clock. Typcially, this clock counts cycles of an
oscillator but some systems use process CPU times or thread CPU oscillator but some systems use process CPU times or thread CPU
timers (via timers provided by the CPU). The quality of the native timers (via timers provided by the CPU). The quality of the native
clock therefore dependends on either the stability of the oscillator clock therefore dependends on either the stability of the oscillator
or the CPU timer. or the CPU timer.
The timescale of the native clock is purely subjective -- no general The timescale of the native clock is a purely subjective -- no
meaning can be attached to any specific clock value. One can only general meaning can be attached to any specific clock value. One can
obtain relative time by comparing two values. Because the value of only obtain relative time by comparing two values. Because the value
the native clock always grows at a steady pace, never decreases, of the native clock always grows at a steady pace, never decreases,
never make unexpected jumps, and never skips, the difference between never make unexpected jumps, and never skips, the difference between
two clock values provides the time interval between the two two clock values provides the time intervall between the two
measurements. measurements.
The independence of the native clock from any external time sources The independence of the native clock from any external time sources
renders it resistant to any manipulation but in return there is no renders it resistant to any manipulation but in return there is no
guarantee that its clock rate is similar to that of any other system. guarantee that its clock rate is similar to that of any other system.
This difference in rate, especially when compared to a reference This difference in rate, especially when compared to a reference
clock, is called clock drift. clock, is called clock drift.
Clock drift depends on the quality of the clock itself but also on Clock drift depends on the quality of the clock itself but also on
factors such as system load or ambient temperatur which makes it hard factors such as system load or ambient temperatur which makes it hard
to predict. to predict.
4.2. World Clock 4.2. World Clock
The native clock only provides means to measure relative time. In The native clock only provides means to measure relative time. In
order to be able to also process absolute time, the system needs to order to be able to also process absolute time, it needs to be
be synchronized with a global reference clock. Since this clock synchronized with a global reference clock. Since this clock strives
strives to be the same on all systems, we call it the world clock. to be the same on all systems, we call it the world clock.
There are a number of ways to maintain the world clock based on the There are a number of ways to maintain the world clock based on the
system's native clock. system's native clock.
The first is to manually maintain an offset between values of the o The first is to manually maintain an offset between values of the
native clock and the reference world clock. Because of the clock native clock and the reference world clock. Because of the clock
drift of the native clock, this offset needs to be updated from time drift of the native clock, this offset needs to be updated from
to time if a minimal divergence from the reference clock is to be time to time if a minimal divergence from the reference clock is
maintained. to be maintained.
Secondly, a hardware clock provided by the system and set to be o Secondly, a hardware clock provided by the system and set to be
equivalent to the reference time can be used, allowing the system to equivalent to the reference time can be used, allowing the system
retain the offset across reboots. to retain the offset across reboots.
Finally, the reference clock can be obtained from an external time o Finally, the reference clock can be obtained from an external time
source. Typically, the Internet is used through a variety of timing source. Typically, the Internet is used through a variety of
protocols including the Network Time Protocol (NTP) [RFC5905], timing protocols including the Network Time Protocol2 (NTP),
Chrony, SNTP, OpenNTP and others. Chrony, SNTP, OpenNTP and others.
Each of these approaches has own problems attached to it. Each of these approaches has own problems attached to it.
Manual configurations can be subject to errors and misconfiguration. o Manual configurations can be subject to errors and
Also, for mobile devices, when moving between time zones, the offset misconfiguration.
must be corrected manually.
Accessing the hardware clock requires an I/O operation which is o Accessing the hardware clock requires an I/O operation which is
resource intensive, therefore many systems use the hardware clock resource intensive, therefore many systems use the hardware clock
only upon reboot, to initialize the clock offset; subsequent updates only upon reboot, to initialize the clock offset; subsequent
are made either manually or through timing protocols. updates are made either manually or through timing protocols.
Further, on many systems the quality of the hardware clock isn't very Further, on many systems the quality of the hardware clock isn't
high, leading to a large clock drift if solely relying on it. Worse, very high, leading to a large clock drift if solely relying on it.
systems like microcontrollers that operate within embedded systems Worse, systems like microcontrollers that operate within embedded
(e.g., Raspberry Pi, Arduino, etc.) often lack hardware clocks systems (e.g., Raspberry Pi, Arduino, etc.) often lack hardware
altogether. These systems rely on external time sources upon reboot clocks altogether. These systems rely on external time sources
and have no means to process absolute time until synchronization with upon reboot and have no means to process absolute time until
these sources has completed. synchronization with these sources has completed.
Relying on Internet timing protocols opens up the system time to o Relying on Internet timing protocols opens up the system time to
attack. Recent papers show vulnerabilities in NTP [SECNTP], [MCBG] attack. Recent papers show vulnerabilities in NTP
and SNTP that allow attackers to maliciously alter system's world [ANTP][ANABM][SECNTP] and SNTP [BPHSTS] that allow attackers to
clock -- pushing it into the past or even into the future. Moreover, maliciously alter system's world clock -- pushing it into the past
many of these time-shifting attacks can be performed by off-path or even into the future. Moreover, many of these time-shifting
attackers, who do not occupy a privileged position on the network attacks can be performed by off-path attackers, who do not occupy
between the victim system and its time sources on the Internet. a privileged position on the network between the victim system and
Researchers have also demonstrated off-path denial of service attacks its time sources on the Internet. Researchers have also
on timing protocols that prevent systems from synchronizing their demonstrated off-path denial of service attacks on timing
clocks. protocols that prevent systems from synchronizing their clocks.
In other words, the process of obtaining the offset necessary to In other words, the process of obtaining the offset necessary to
provide a world clock creates dependencies that can be exploited. provide a world clock creates dependencies that can be exploited.
5. Implementation Approaches 5. Implementation Approaches
Because absolute time relies on a shared interpretation of a value Because absolute time relies on a shared interpretation of a value
expressing time, the world clock is necessary when processing such expressing time, the world clock is necessary when processing such
values. values.
skipping to change at page 6, line 29 skipping to change at page 7, line 5
time sources, the implementation becomes resistant to the time sources, the implementation becomes resistant to the
difficulties of coordinating with these sources. difficulties of coordinating with these sources.
However, using the native clock in this way comes with a caveat. However, using the native clock in this way comes with a caveat.
Since the native clock is not subject to any adjustments by timing Since the native clock is not subject to any adjustments by timing
protocols, it is not adjusted for the error introduced by clock protocols, it is not adjusted for the error introduced by clock
drift. While this is likely of little consequence for short drift. While this is likely of little consequence for short
intervals, it may become significant for intervals that span long intervals, it may become significant for intervals that span long
periods of time. periods of time.
Consequently, the choice of clock to be used is application-specific. The choice of clock to be used is situation-specific. If a certain
If applications can tolerate a certain amount of clock drift or if amount of clock drift can be tolerated or if time intervals are
the time intervals are short, implementers may prefer using the short, implementors may prefer to use the native clock. However, if
native clock. If the application relies on precise timing over long precise timing over long periods is required, then the implementors
periods one has no choice but to fall back to the world clock. have no choice but to fall back to world clock
6. Accessing the Native Clock on Selected Operating Systems 6. Accessing the Native Clock on Selected Operating Systems
In most operating systems, the standard functions to access time use In most operating systems, the standard functions to access time use
the world clock since that is normally what users would expect. This the world clock since that is normally what users would expect. This
section provides an overview how the native clock can be accesses on section provides an overview how the native clock can be accesses on
some common operating systems. some common operating systems.
6.1. POSIX 6.1. POSIX
POSIX defines a system C API function which may provide native time: POSIX defines a system C API function which may provide native time:
clock_gettime(), when used with a clock_id of CLOCK_MONOTONIC (when "clock_gettime()", when used with a "clock_id" of "CLOCK_MONOTONIC".
supported by the system). POSIX does not make a distinction between
raw time and adjusted raw time in the definition of this function.
Beware that, with some systems, CLOCK_MONOTONIC deliveres adjusted
raw time and that CLOCK_MONOTONIC_RAW needs to be used as clock_id to
get unadjusted raw time. Non-POSIX systems may provide different
APIs.
6.2. Microsoft Windows
In the Microsoft Windows operating system, native time is called Note that on some systems "CLOCK_MONOTONIC" is still influenced by an
'Windows Time' and can be accessed through the GetTickCount and external time source (for syntonizing the clock rate) and the non-
GetTickCount64 API functions. The returned value is normally the standard "CLOCK_MONITONIC_RAW" needs to be used for clock values not
number of milliseconds since system start. GetTickCount will return influenced by an external time source and not susceptible for time-
a 32 bit value while GetTickCount64 returns a value 64 bits wide that shifting attacks.
will wrap around less often.
7. Acknowledgements 6.2. Microsoft Window
We are thankful to Sharon Goldberg and Benno Overreinder for useful In the Microsoft Windows operating system, native time is called
discussions. 'Windows Time' and can be accessed through the "GetTickCount" and
"GetTickCount64" API functions. The returned value is nomially the
number of milliseconds since system start. "GetTickCount" will
return a 32 bit value while "GetTickCount64" returns a value 64 bits
wide that will wrap around less
8. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
9. Security Considerations 8. Security Considerations
Time is a fundamental component for the security guarantees claimed Time is a fundamental component for the security guarantees claimed
by various applications. A system that uses a time distribution by various applications. A system that uses a time distribution
protocol may be affected by the security aspects of the time protocol may be affected by the security aspects of the time
protocol. The security considerations of time protocols in general protocol. The security considerations of time protocols in general
are discussed in [RFC7384]. This document discusses the security are discussed in [RFC7384]. This document discusses the security
considerations with respect to implementing time values in considerations with respect to implementing time values in
applications in various sections. applications in various sections.
10. Informative References 9. References
[CLOCKDRIFT]
Marouani, H. and M. Dagenais, "Internal clock drift
estimation in computer clusters", 2008,
<http://downloads.hindawi.com/journals/
jcnc/2008/583162.pdf>.
[MCBG] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg,
"Attacking the Network Time Protocol", 2015,
<https://eprint.iacr.org/2015/1020>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 9.1. Normative References
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>. October 2014, <https://www.rfc-editor.org/info/rfc7384>.
9.2. Informative References
[ANABM] Malhotra, A. and S. Goldberg, "Attacking NTP's
Authenticated Broadcast Mode", 2016,
<https://eprint.iacr.org/2016/055>.
[ANTP] Malhotra, A., Cohen, I., Brakke, E., and S. Goldberg,
"Attacking the Network Time Protocol", 2015,
<https://eprint.iacr.org/2015/1020>.
[BPHSTS] Jose, J., "Bypassing HTTP Strict Transport Security",
2014, <https://www.blackhat.com/docs/eu-14/materials/eu-
14-Selvi-Bypassing-HTTP-Strict-Transport-Security-wp.pdf>.
[SECNTP] Malhotra, A., Gundy, M., Varia, M., Kennedy, H., Gardner, [SECNTP] Malhotra, A., Gundy, M., Varia, M., Kennedy, H., Gardner,
J., and S. Goldberg, "The Security of NTP's Datagram J., and S. Goldberg, "The Security of NTP's Datagram
Protocol", 2016, <http://eprint.iacr.org/2016/1006>. Protocol", 2016, <http://eprint.iacr.org/2016/1006>.
Appendix A. Acknowledgements
We are thankful to Sharon Goldberg and Benno Overreinder for useful
discussions. Thanks to Dieter Sibold, Joachim Fabini and Denis
Reilly, for value input and suggestions.
Authors' Addresses Authors' Addresses
Aanchal Malhotra Aanchal Malhotra
Boston University Boston University
111 Cummington Mall 111 Cummington Mall
Boston 02215 Boston 02215
USA USA
Email: aanchal4@bu.edu Email: aanchal4@bu.edu
Kristof Teichel Kristof Teichel
Physikalisch-Technische Bundesanstalt Physikalisch-Technische Bundesanstalt
Bundesallee 100 Bundesallee 100
Braunschweig D-38116 Braunschweig D-38116
Germany Germany
Email: kristof.teichel@ptb.de Email: kristof.teichel@ptb.de
Martin Hoffmann Martin Hoffmann
NLnet Labs NLnet Labs
 End of changes. 38 change blocks. 
117 lines changed or deleted 133 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/