OpenNTPD

OpenNTPD

"Saving the world again... on time"
Developer(s) The OpenBSD Project
Stable release 5.7p4 / 24 March 2015 (2015-03-24)
Development status Active
Written in C
Operating system BSD, Linux, Solaris and OS X[1]
Type Time synchronization
License ISC
Website www.openntpd.org
Standard(s) RFC 1305, RFC 5905
As of October 2015

OpenNTPD is a Unix system daemon implementing the Network Time Protocol to synchronize the local clock of a computer system with remote NTP servers. It is also able to act as an NTP server to NTP-compatible clients.

OpenNTPD is primarily developed by Henning Brauer as part of the OpenBSD project. Its design goals include being secure (non-exploitable), easy to configure, accurate enough for most purposes and with source code that can be distributed under an ISC license. Its portable version, like that of OpenSSH, is developed as a child project which adds the portability code to the OpenBSD version and releases it separately. The portable version is developed by Brent Cook. The most recent portable version was released in 2015. The project developers receive some funding from the OpenBSD Foundation.

History

The development of OpenNTPD was motivated by a combination of issues with current NTP daemons: difficult configuration, complicated and difficult to audit code, and unsuitable licensing.[2] OpenNTPD was designed to solve these problems and make time synchronization accessible to a wider userbase. After a period of development, OpenNTPD first appeared in OpenBSD 3.6.[3] Its first release was announced on November 2, 2004.[4]

Goals

OpenNTPD is an attempt by the OpenBSD team to produce an NTP daemon implementation that is secure, simple to security audit, trivial to set up and administer, and has small memory requirement that synchronizes local clock on the computer with remote NTP server with reasonable accuracy. As such, the design goals for OpenNTPD are: security, ease of use, and performance.[5] Security in OpenNTPD is achieved by robust validity check in the network input path, use of bounded buffer operations via strlcpy, and privilege separation to mitigate the effects of possible security bugs exploiting the daemon through privilege escalation. In order to simplify the use of NTP, OpenNTPD implements a smaller set of functionalities than those available in other NTP daemons, such as that provided by the Network Time Protocol Project. The objective is to provide enough features to satisfy typical usage at the risk of unsuitability for esoteric or niche requirements. OpenNTPD is configured through ntpd.conf configuration file.[6] A minimal number of options are offered: IP address or hostname on which OpenNTPD should listen, a timedelta sensor device to be used, and the set of servers from which the time will be synchronized. The accuracy of OpenNTPD is best-effort; the daemon attempts to be as accurate as possible but no specific accuracy is guaranteed.

Example

OpenNTPD gradually adjusts the system clock, as seen here in the example output of OpenNTPD running on an Arch Linux system:

$ grep ntpd /var/log/daemon.log | grep adjusting | tail -20
Aug  4 02:58:21 nikolai ntpd[4784]: adjusting local clock by -2.134620s
Aug  4 03:02:38 nikolai ntpd[4784]: adjusting local clock by -1.983869s
Aug  4 03:06:53 nikolai ntpd[4784]: adjusting local clock by -1.884521s
Aug  4 03:08:28 nikolai ntpd[4784]: adjusting local clock by -1.819296s
Aug  4 03:12:46 nikolai ntpd[4784]: adjusting local clock by -1.712934s
Aug  4 03:15:48 nikolai ntpd[4784]: adjusting local clock by -1.607747s
Aug  4 03:19:31 nikolai ntpd[4784]: adjusting local clock by -1.535188s
Aug  4 03:21:05 nikolai ntpd[4784]: adjusting local clock by -1.439628s
Aug  4 03:24:56 nikolai ntpd[4784]: adjusting local clock by -1.376086s
Aug  4 03:29:12 nikolai ntpd[4784]: adjusting local clock by -1.271529s
Aug  4 03:32:20 nikolai ntpd[4784]: adjusting local clock by -1.162333s
Aug  4 03:36:08 nikolai ntpd[4784]: adjusting local clock by -1.023899s
Aug  4 03:40:02 nikolai ntpd[4784]: adjusting local clock by -0.902637s
Aug  4 03:43:43 nikolai ntpd[4784]: adjusting local clock by -0.789431s
Aug  4 03:47:35 nikolai ntpd[4784]: adjusting local clock by -0.679320s
Aug  4 03:50:45 nikolai ntpd[4784]: adjusting local clock by -0.605858s
Aug  4 03:53:31 nikolai ntpd[4784]: adjusting local clock by -0.529821s
Aug  4 03:56:33 nikolai ntpd[4784]: adjusting local clock by -0.429573s
Aug  4 03:59:46 nikolai ntpd[4784]: adjusting local clock by -0.312575s
Aug  4 04:03:14 nikolai ntpd[4784]: adjusting local clock by -0.232646s
$

Criticism

OpenNTPD has been criticized[7] as being less accurate than the NTP daemon produced by Internet Software Consortium (ISC). Internally, OpenNTPD does not maintain millisecond accuracy and can vary 50-200ms from "real" time because it omits a variety of algorithms that increase accuracy in favour of code simplicity. The OpenNTPD project acknowledged the criticism, but pointed out that the lack of microsecond precision was a design tradeoff that benefited simplicity and security.[7] The OpenNTPD design goals state the project's intent is to "[r]each a reasonable accuracy" without sacrificing "secure design for getting that last nanosecond or obscure edge case."[8]

In September 2004, shortly after the release of OpenNTPD 3.6, ISC NTP contributor Brad Knowles published an article entitled OpenNTPd Considered Harmful[9] criticizing various aspects of OpenNTPD's implementation of the NTP protocol, as well as the split development model that the project employs, which is also used in the development of OpenSSH and OpenBGPD. In December 2004, Darren Tucker, the principal developer on the portable branch of OpenNTPD, wrote a detailed response to Knowles, acknowledging some issues as valid, rejecting several others as unwarranted, and considering yet others as misleading.[10] Among the more serious issues raised by Knowles was that OpenNTPD servers claimed to be stratum 1 servers. The issue had however already been fixed by the time of Tucker's response. In March 2005, Knowles acknowledged Tucker's response, and stated that he was "going to do everything [he could] to work with [Tucker] to get any remaining issues resolved."[11] The OpenBSD networking FAQ also added a section that responds to Knowles' initial criticism.[12]

As of August 2007, OpenNTPD 3.9p1 still served time with a zero dispersion.[13]

References

  1. "OpenNTPD Portable Release". OpenBSD. Retrieved 15 October 2015.
  2. The OpenNTPD Project (22 December 2004). "OpenNTPD Goals". The OpenNTPD Project. Retrieved 7 June 2014.
  3. The OpenBSD Project (1 November 2004). "OpenBSD 3.6". The OpenBSD Project. Retrieved 7 June 2014.
  4. Brauer, Henning (2 November 2004). "OpenNTPD 3.6 released". openbsd-announce (Mailing list). MARC. Retrieved 7 June 2014.
  5. Brauer, Henning (September 2004). "Page 3: OpenNTPD – Design Goals". The OpenBSD Project. Retrieved 16 September 2006.
  6. ntpd.conf(5)  OpenBSD File Formats Manual. 26 May 2006. Retrieved 16 September 2006.
  7. 1 2 The OpenBSD Project (21 August 2006). "FAQ 6.12.1: 'But OpenNTPD isn't as accurate as the ntp.org daemon!'". The OpenBSD Project. Retrieved 16 September 2006.
  8. OpenNTPD authors (2004), "Goals", OpenNTPD, OpenNTPD project.
  9. Knowles, Brad (22 September 2004). "OpenNTPd Considered Harmful". Considered Harmful. Archived from the original on 4 March 2005. Retrieved 16 September 2006.
  10. Tucker, Darren (12 December 2004). "Response to OpenNTPd Considered Harmful". Advogato: Blog for dtucker. Retrieved 16 September 2006.
  11. Knowles, Brad (12 March 2005). "Update: OpenNTPd...". Considered Harmful. Archived from the original on 19 March 2005. Retrieved 16 September 2006.
  12. The OpenBSD Project (21 August 2006). "FAQ: 6.12.2: 'Someone has claimed that OpenNTPD is 'harmful'!'". The OpenBSD Project. Retrieved 16 September 2006.
  13. "#436995 - Incorrect values for root delay and dispersion". Debian Bug report logs. 10 Aug 2007. Retrieved 7 June 2014.

External links

This article is issued from Wikipedia - version of the Sunday, January 17, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.