[ntp:questions] ntpdate.c unsafe buffer write

David L. Mills mills at udel.edu
Sat Feb 9 04:58:03 UTC 2008


You make some good points. However, if folks want SNTP from here I think 
they would prefer it in its own distribution rather than bundle it with 
the huge NTP distribution. You can make a strong argument to host here 
if the claim that both NTP and SNTP are strictly specification 
conformant. That's why I rewrote the SNTP documentation to take out all 
mention that it could be used as a server.

The three of us that wrote rfc 2030 had just come down from a massive 
clogging situation at UWisc and NIST and were frantic to get across the 
need for polite client behavior. This has to do with DNS lookups, poll 
intervals and behavior when no response is received. Even so, there 
remains at least three violators of those principles right now on two of 
our public servers. Therefore, if an SNTP product leaves here, it really 
and surely should compley with the on-wire protocol in the NTPv4 spec 
and these best practices.

A aside, I should reveal my biases. At the moment, to configure the 
current software on an Sun Ultra 5 takse 12 minutes, 6 minutes for NTP 
and 6 minutes for SNTP. But, it takes only 8 minutes to compile and link 
all programs, including both NTP and SNTP. It is not now possible to 
build either separately.

As I have said privately before, the NTP daemon can be operated in SNTP 
mode which does everything NTP does, but terminates just after the clock 
has been set for the first time. Yes, it has a rather large footprint, 
but it lasts only about 11 seconds. The downside is that it requires a 
configuration file containing a list of servers. If this were done on 
the command line, NTP in SNTP mode would be indistinguishable from SNTP 
other than a command line option.

So, the ideal solution would seem to include a list of links on the NTP 
home page to external sites and in addition internal links to the NTP 
and SNTP distributions along with a statement that both are strictly 
specification conformant. That might inspire other wannabees to make and 
enforce similar claims.


Harlan Stenn wrote:
>>>>In article <foi07v$grj$1 at scrotar.nss.udel.edu>, "David L. Mills" <mills at udel.edu> writes:
> David> Harlan, My position on ntpdate and sntp has always been clear. Remove
> David> them both from the distribution and let other folks contribute sntp
> David> products.
> Yes, your position has been clear and your opinion has been noted.
> David> The standards labs in various contries do not recommend the
> David> NTP reference implementation, they recommend other shrinkwrap
> David> products.
> I'd appreciate references on this point.  And how it is germane to this
> discussion?
> David> There is no need for folks to download the reference
> David> implementatino only to bring up an sntp product.
> Yes, which is why the sntp code can be trivially bundled separately.
> The feedback I have received is that the majority of folks want the
> distribution to contain both ntp and sntp.
> David> The matter of concern is an sntp product that strictly conforms to
> David> the NTPv4 specification as it applies to sntp. There is at least one
> David> contributor testing the kiss-o'-death rate limit and has apparently
> David> actually read rfc 2030. On the other hand, there are numerous
> David> examples of clients that casually violate the rate rules both at
> David> servers we operate here and at the national labs.
> Yup.
> David> What we should be
> David> doing is supporting those products that play by the rules and that
> David> are maintained by other players.
> This depends first on the definition of "we", and then on the definition of
> "supporting".
> The people who talk to me want an SNTP implementation from the NTP Project.
> Nobody is expecting you to ride herd over any SNTP code that may or may not
> be part of the same tarball that includes NTP.  I am mulling over different
> ideas in this regard.
> Two obvious ways to go on NTP/SNTP are to have shared code, or completely
> separate codebases.  There is some middle ground regarding "support"
> libraries.
> I see difficult tradeoffs with either approach.

More information about the questions mailing list