Modify

Opened 10 years ago

Closed 9 years ago

#2448 closed defect (wontfix)

Please disable server functionality from openntpd

Reported by: jch@… Owned by: developers
Priority: normal Milestone: Features Paradise
Component: packages Version:
Keywords: Cc: jch@…

Description

The openntpd time keeping daemon violates the NTP protocol in a few ways. Openntpd time servers end up in public places, such as the NTP pool, where they end up breaking the NTP network for everyone.

I would like to recommend that the OpenWRT version of openntpd should disable server functionality -- i.e. it should still act as a client, but never respond to client queries.

Of course, I'd much prefer openntpd to be removed from OpenWRT altogether.

Juliusz

Attachments (0)

Change History (5)

comment:1 Changed 10 years ago by blogic

  • Cc jch@… added

how does it break ?

comment:2 in reply to: ↑ description Changed 10 years ago by Bartman007

As I understand it OpenNTPd tends to lean towards the Simple NTP (SNTP) protocol as outlined by RFC4330 instead of NTP, as outlined by RFC1305 (NTPv3) or the NTPv4 spec. It is lacking many features (like an algorithm to detect inaccurate upstream servers) to ensure that the time remains accurate in favor of simple, easily auditable code. Unfortunately the name implies that it is a full NTP daemon.

Replying to blogic:

how does it break ?

If the ISC mailing lists (follow the thread) or Brad Knowles (ISC NTP contributor) are to be believed, then 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 favor of code simplicity. They also indicate that OpenNTPd always considers itself a stratum 2 server (circa 2004 at least.) While the primary developer of the OpenNTPd-portable branch responded to Brad Knowles' article, refuting many of the claims; I can't profess much information into the inner workings of OpenNTPd either way.

Replying to jch@pps.jussieu.fr:

Openntpd time servers end up in public places, such as the NTP pool, where they end up breaking the NTP network for everyone.

I don't see how this affects OpenWrt. Anyone running a public NTP server should have a good understanding of the NTP protocol and the various daemons; someone running a NTP pool server on a router should have their head examined anyway.

Replying to jch@pps.jussieu.fr:

I would like to recommend that the OpenWRT version of openntpd should disable server functionality -- i.e. it should still act as a client, but never respond to client queries.

Of course, I'd much prefer openntpd to be removed from OpenWRT altogether.

The SNTP RFC supports your proposition of disabling server functionality
RFC4330 (SNTP)

Because an SNTP
server ordinarily does not implement the full suite of grooming and
mitigation algorithms intended to support redundant servers and
diverse network paths, it should be operated only in conjunction with
a source of external synchronization, such as a reliable radio clock

But the top of the memo notes "[it] does not specify an Internet standard of any kind."

OpenNTPd clearly states in the design goals and the FAQ that it intends to provide "reasonable accuracy." In my opinion anything accuracy below one second is acceptable for a home network. OpenNTPd is not a default package, and as with any other package, the user should research what it does before installing; if more accuracy is needed, use ISC NTPd.

comment:3 Changed 10 years ago by jch@…

how does it break ?

In addition to everything that Bartman said, OpenNTPd is simply incorrect in many places.

The most serious bug is that it will advertise 0 dispersion to all clients. In other words,
it is advertising a /smaller/ synchronisation distance than the true distance.

Now synchronisation distance is what is used by other NTP implementations to select the best
server to use. Advertising a smaller distance amounts to falsely claimining that you are more
accurate than you actually are. While this doesn't confuse the reference NTP implementation
(which uses a number of algorithms to detect liars) or OpenNTPd (which ignores such fancy
protocol parameters as synchronisation distance), it will confuse other clients.

I have also witnessed OpenNTPd suffering from serious inaccuracy (2-3 seconds) on two machines
machines (a WRT54GL and a Pentium III, so it's not hardware). I believe that the developers'
claims to being accurate within a fraction of a second are not true.

For all of these reasons, I recommend that server functionality should be removed from OpenNTPd.
If you disagree, please patch the OpenWRT version to advertise a very large dispersion rather
than 0.

Regards,

Juliusz

comment:4 Changed 10 years ago by blogic

  • Milestone set to Kamikaze Features Paradize

comment:5 Changed 9 years ago by florian

  • Resolution set to wontfix
  • Status changed from new to closed

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.