]>

sarah.grant.ietf@gmail.com

Internet Network Time Protocols This document describes considerations of synchronisation algorithms with version 5 of the Network Time Protocol (NTP), and provides guidance on the use of NTP version 4's algorithms when used with NTP version 5. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Network Time Protocols Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction NTP version 4 (NTPv4) defines various algorithms and logic which handle several different aspects of acquiring and maintaining synchronisation of NTP clients including filtering of measurements, security mechanisms, source selection, and clock control, amongst others. Over time NTPv4 has seen additional algorithms be defined to improve security and accuracy, with Khronos defining a companion method to run alongside with NTPv4 clients that aims to detect and mitigate time-shifting based attacks, and interleaved modes which defines additional operational modes for both clients and servers by holding additional state and performing additional checks on timestamp values. However, NTP version 5 (NTPv5) explicitly does not define these algorithms in conjunction with the wire protocol to allow for the creation and evolution of new algorithms and implementations which may be optimised for specific deployment use case or system constraints. For all implementations there are many factors that should be taken into consideration in the development of both new algorithms as well as the porting of existing algorithms to NTPv5, such as trade-offs between precision and security, costs of complexity, etc. The decoupling of algorithms to their dependent wire protocol is not new - PTP has the concept of "profiles", each of which define different behaviours and algorithms adapted for specific deployments (for example in automotive or power industries), and may even include additional capabilities to the protocol, for example the "daily jam" function in SMPTE ST-2059 where discontinuity is deliberately transmitted to remove built up discrepancies in values.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses the terminology established in .

Algorithm Considerations TODO: General considerations, including interop (When Algorithms Collide) TODO: Signalling of algorithms? If so, this would likely require an IANA registry

Extension Fields Algorithms may choose to use additional information be sent by either client or server, however this brings the risk of these fields not being correctly handled by peers which do not support them. Algorithms must have explicit behaviours defined when any required extension fields are not present.

Non-UTC timescales In addition to UTC, NTPv5 includes support for the transmission of TAI, UT1, and leap-smeared UTC timescales. Algorithms may choose to support a limited subset of timescales, and use different logic depending on the timescale supported. Implementations shouldn't mix timestamps from different timescales when performing calculations, and it's recommended they minimise the conversion of timescales where possible to reduce potential confusion and aide in accuracy.

Leap Seconds and Leap Second Smearing Existing NTP implementations commonly use one of several known approaches to applying leap seconds to system time: they may "freeze" the clock where the leap second is inserted at the beginning of the last second of the day, or the system clock is "slewed" or "smeared" either before or commencing from the leap second , keeping system time monotonic but less accurate during the period. Server implementations which use drifting mechanisms to smooth the leap second insertion such as slewing or smearing must only apply it to only to UTC, and must set the timescale flag in packets to clients as "Leap-smeared UTC".

Use of NTPv4 Algorithms with NTPv5 Support for NTPv4 algorithms is not required for NTPv5 implementations, however those supporting both versions of NTP may find it easy to include as a default or fall-back option in configurations where others are not set. NTPv5 introduces several key differences to NTPv4 that implementations should be aware of when either building new implementations of the NTPv4 algorithms or when adapting existing. Most notably, the timestamp format has been changed with NTPv5 to ensure longevity and prevent rollover in the immediate future, which should be taken into consideration when processing and producing packets. TODO: Interleaved mode

Security Considerations General security considerations for time protocols are discussed in RFC 7384 , and security considerations specific to NTPv5 should also be noted. Not all threats can be sufficiently mitigated through the use of algorithms, for example packet manipulation, spoofing, and cryptographic performance attacks may be better mitigated through the use of authenticated encryption via NTS . Designers of new algorithms should take into consideration the expected threat model of deployments and should describe which threats could potentially be mitigated from those which are not in scope for the intended use cases, for example closed network deployments have a very different set of risks in comparison to deployments on the internet. TODO: Discuss general attacks on time via algorithms, e.g. time-shifting

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. This document discusses issues that arise when RTP sessions span Coordinated Universal Time (UTC) leap seconds. It updates RFC 3550 by describing how RTP senders and receivers should behave in the presence of leap seconds. As time and frequency distribution protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of security requirements for time protocols, focusing on the Precision Time Protocol (PTP) and the Network Time Protocol (NTP). This document also discusses the security impacts of time protocol practices, the performance implications of external security practices on time protocols, and the dependencies between other security services and time synchronization. This memo specifies Network Time Security (NTS), a mechanism for using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for the client-server mode of the Network Time Protocol (NTP). NTS is structured as a suite of two loosely coupled sub-protocols. The first (NTS Key Establishment (NTS-KE)) handles initial authentication and key establishment over TLS. The second (NTS Extension Fields for NTPv4) handles encryption and authentication during NTP time synchronization via extension fields in the NTP packets, and holds all required state only on the client via opaque cookies. The Network Time Protocol version 4 (NTPv4), as defined in RFC 5905, is the mechanism used by NTP clients to synchronize with NTP servers across the Internet. This document describes a companion application to the NTPv4 client, named "Khronos", that is used as a "watchdog" alongside NTPv4 and that provides improved security against time-shifting attacks. Khronos involves changes to the NTP client's system process only. Since it does not affect the wire protocol, the Khronos mechanism is applicable to current and future time protocols. This document specifies interleaved modes for the Network Time Protocol (NTP). These new modes improve the accuracy of time synchronization by enabling the use of more accurate transmit timestamps that are available only after the transmission of NTP messages. These enhancements are intended to improve timekeeping in environments where high accuracy is critical. This document updates RFC 5905 by defining these new operational modes. Red Hat Huawei The Network Time Protocol (NTP) is a widely deployed protocol that allows hosts to obtain the current time of day from time servers. This document specifies version 5 of the protocol (NTPv5), which adopts a client-server model as its sole mode of operation. Legacy operational modes supported in earlier versions have been removed to improve protocol robustness and clarity. While this specification defines the protocol used for time distribution, it does not define the algorithms or heuristics employed by clients to determine or adjust their local time. IEEE

Acknowledgments TODO acknowledge that perhaps this was not the smartest idea.