Network Time Protocol
| ← Previous revision | Revision as of 03:48, 21 April 2026 | ||
| Line 150: | Line 150: | ||
As NTP replaced the old [[Time Protocol]], some use cases nevertheless found the full protocol too complicated. In 1992, '''Simple Network Time Protocol''' ('''SNTP''') was defined to fill this niche. The SNTPv3 standard describes a way to use NTPv3 such that no storage of [[state (computer science)|state]] over an extended period is needed. The topology becomes essentially the same as with the Time Protocol, as only one server is used.{{Ref RFC|1361}} In 1996, SNTP was updated to SNTPv4,{{Ref RFC|2030}} with some features of the then-in-development NTPv4. SNTPv4 was merged into the main NTPv4 standard in 2010.{{Ref RFC|5905}} |
As NTP replaced the old [[Time Protocol]], some use cases nevertheless found the full protocol too complicated. In 1992, '''Simple Network Time Protocol''' ('''SNTP''') was defined to fill this niche. The SNTPv3 standard describes a way to use NTPv3 such that no storage of [[state (computer science)|state]] over an extended period is needed. The topology becomes essentially the same as with the Time Protocol, as only one server is used.{{Ref RFC|1361}} In 1996, SNTP was updated to SNTPv4,{{Ref RFC|2030}} with some features of the then-in-development NTPv4. SNTPv4 was merged into the main NTPv4 standard in 2010.{{Ref RFC|5905}} |
||
SNTP is fully interoperable with NTP since it does not define a new protocol{{Ref RFC|5905|rsection=14|notes=no|status=no|quote=Primary servers and clients complying with a subset of NTP, called the Simple Network Time Protocol (SNTPv4) [...], do not need to implement the mitigation algorithms [...] The fully developed NTPv4 implementation is intended for [...] servers with multiple upstream servers and multiple downstream servers [...] Other than these considerations, NTP and SNTP servers and clients are completely interoperable and can be intermixed [...]}}, as it utilizes the same packet format and port as NTP, ensuring compatibility with NTP servers. However, client/server will lack the complex algorithms required to filter network [[jitter]], analyze [[clock drift]], or cross-reference multiple time sources. This makes it suitable for [[ |
SNTP is fully interoperable with NTP since it does not define a new protocol{{Ref RFC|5905|rsection=14|notes=no|status=no|quote=Primary servers and clients complying with a subset of NTP, called the Simple Network Time Protocol (SNTPv4) [...], do not need to implement the mitigation algorithms [...] The fully developed NTPv4 implementation is intended for [...] servers with multiple upstream servers and multiple downstream servers [...] Other than these considerations, NTP and SNTP servers and clients are completely interoperable and can be intermixed [...]}}, as it utilizes the same packet format and port as NTP, ensuring compatibility with NTP servers. However, client/server will lack the complex algorithms required to filter network [[jitter]], analyze [[clock drift]], or cross-reference multiple time sources. This makes it suitable for [[IoT]] devices and basic hardware that require "good enough" time without the overhead of a full NTP application stack.{{Ref RFC|5905}} |
||
An SNTP client typically operates by querying a single server and applying the received time directly to the local clock. However, the simple algorithms provide times of reduced accuracy and thus it is inadvisable to sync time from an SNTP source. However, RFC 5905 notes that because the additional complexity of the full on-wire protocol is minimal, full implementation is encouraged even for simple clients.{{Ref RFC|5905}} |
An SNTP client typically operates by querying a single server and applying the received time directly to the local clock. However, the simple algorithms provide times of reduced accuracy and thus it is inadvisable to sync time from an SNTP source. However, RFC 5905 notes that because the additional complexity of the full on-wire protocol is minimal, full implementation is encouraged even for simple clients.{{Ref RFC|5905}} |
||
| Line 288: | Line 288: | ||
NTP itself includes support for authenticating servers to clients. NTPv3 supports a [[symmetric key]] mode, which is not useful against MITM. The [[public key]] system known as "autokey" in NTPv4 adapted from [[IPSec]] offers useful authentication, but is not practical for a busy server. Autokey was also later found to suffer from several design flaws,{{Cite conference|url=https://www.ietf.org/proceedings/83/slides/slides-83-tictoc-1.pdf|title=Analysis of NTP's Autokey Protocol|author1=Dieter Sibold|author2=Stephen Röttger|conference=IETF 83|date=2012}} with no correction published, save for a change in the [[message authentication code]].{{Ref RFC|8573}} Autokey should no longer be used.{{ref RFC|8633|section=4.2}} |
NTP itself includes support for authenticating servers to clients. NTPv3 supports a [[symmetric key]] mode, which is not useful against MITM. The [[public key]] system known as "autokey" in NTPv4 adapted from [[IPSec]] offers useful authentication, but is not practical for a busy server. Autokey was also later found to suffer from several design flaws,{{Cite conference|url=https://www.ietf.org/proceedings/83/slides/slides-83-tictoc-1.pdf|title=Analysis of NTP's Autokey Protocol|author1=Dieter Sibold|author2=Stephen Röttger|conference=IETF 83|date=2012}} with no correction published, save for a change in the [[message authentication code]].{{Ref RFC|8573}} Autokey should no longer be used.{{ref RFC|8633|section=4.2}} |
||
'''Network Time Security''' (NTS) is a secure version of NTPv4 with [[Transport Layer Security|TLS]] and [[ |
'''Network Time Security''' (NTS) is a secure version of NTPv4 with [[Transport Layer Security|TLS]] and [[AEAD]].{{Cite web|title=nts.time.nl homepage|url=https://nts.time.nl/|access-date=2021-08-19|website=nts.time.nl}} The main improvement over previous attempts is that a separate "key establishment" server handles the heavy asymmetric cryptography, which needs to be done only once. If the server goes down, previous users would still be able to fetch time without fear of MITM.{{Ref RFC|8915}} NTS is supported by several NTP servers including [[Cloudflare]] and [[Netnod]].{{Cite web|last=Langer|first=Martin|date=2019-12-05|title=Setting up NTS-Secured NTP with NTPsec|url=https://weberblog.net/setting-up-nts-secured-ntp-with-ntpsec/|access-date=2021-08-19|website=Weberblog.net|language=en-US}}{{Cite web|title=How to use NTS {{!}} Netnod|url=https://www.netnod.se/time-and-frequency/how-to-use-nts|access-date=2021-08-19|website=Netnod}} It can be enabled on {{Proper name|chrony}}, NTPsec, and ntpd-rs.{{cite web |date=13 August 2024 |title=Network Time Security · Cloudflare Time Services docs |url=https://developers.cloudflare.com/time-services/nts/ |access-date=12 January 2025 |website=developers.cloudflare.com |language=en}} |
||
Microsoft also has an approach to authenticate NTPv3/SNTPv4 packets using a [[Windows domain]] identity, known as MS-SNTP.{{cite web | url=https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-sntp/8106cb73-ab3a-4542-8bc8-784dd32031cc | title=[MS-SNTP]: Network Time Protocol (NTP) Authentication Extensions | date=24 June 2021 }} This system is implemented in the reference ntpd and chrony, using [[Samba (software)|samba]] for the domain connection.{{Cite web|title=Comparison of NTP implementations|url=https://chrony.tuxfamily.org/comparison.html|publisher=chrony.tuxfamily.org|accessdate=2019-10-08}} |
Microsoft also has an approach to authenticate NTPv3/SNTPv4 packets using a [[Windows domain]] identity, known as MS-SNTP.{{cite web | url=https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-sntp/8106cb73-ab3a-4542-8bc8-784dd32031cc | title=[MS-SNTP]: Network Time Protocol (NTP) Authentication Extensions | date=24 June 2021 }} This system is implemented in the reference ntpd and chrony, using [[Samba (software)|samba]] for the domain connection.{{Cite web|title=Comparison of NTP implementations|url=https://chrony.tuxfamily.org/comparison.html|publisher=chrony.tuxfamily.org|accessdate=2019-10-08}} |
||
| Line 454: | Line 454: | ||
This is especially useful for networks where devices are moving in and out, like [[cellular network]]. Reduce the need to defined directly on device. |
This is especially useful for networks where devices are moving in and out, like [[cellular network]]. Reduce the need to defined directly on device. |
||
These options are defined in RFC 4833{{Cite report |url=https://datatracker.ietf.org/doc/rfc4833/ |title=Timezone Options for DHCP |last=Lear |first=Eliot |last2=Eggert |first2=Paul |date=2007-04-01 |publisher=Internet Engineering Task Force |issue=RFC 4833|access-date=2026-01-26|url-status=live}} and apply to both [[ |
These options are defined in RFC 4833{{Cite report |url=https://datatracker.ietf.org/doc/rfc4833/ |title=Timezone Options for DHCP |last=Lear |first=Eliot |last2=Eggert |first2=Paul |date=2007-04-01 |publisher=Internet Engineering Task Force |issue=RFC 4833|access-date=2026-01-26|url-status=live}} and apply to both [[DHCP]] for [[IPv4]] ([[DHCPv4]]) and [[IPv6]] ([[DHCPv6]]). |
||
==== DHCPv4 time zone options ==== |
==== DHCPv4 time zone options ==== |
||
| Line 522: | Line 522: | ||
==== Relationship to NTP ==== |
==== Relationship to NTP ==== |
||
NTP distributes only absolute time ([[ |
NTP distributes only absolute time ([[UTC]]) and does not include any information about local time zones or daylight saving rules. DHCP time zone options complement NTP by allowing clients to automatically configure their local time representation after their clocks have been synchronised. |
||
In typical deployments: |
In typical deployments: |
||