[ntp:hackers] Re: sntp

todd glassey tglassey at earthlink.net
Mon Aug 28 22:41:47 UTC 2006

Harlan - can I answer this - Its not about Engineering per se - (actually I
will get it to engineering before I am done with it).

----- Original Message ----- 
From: "David L. Mills" <mills at udel.edu>
To: <hackers at ntp.org>
Sent: Monday, August 28, 2006 2:10 PM
Subject: [ntp:hackers] Re: sntp

> Harlan,
> I'm copying this to the hackers list, as others might want to comment.
> Let me take your points seriously. I use bold here for emphasis as do
> the rfcs.
> You assume ntpd is not auditable, from which I gather sntp is supposedly
> auditable. I conclude that sntp should not use components from the ntp
> distribution unless those components are auditable. Has someone (Todd?)
> made that professional judgement? To be auditable a serious claim would
> be necessary that the implementation conform to rfc4330. The
> implementers should verify that with the rfc4330 text, especially the
> best practices section. To preserve audibility, the sntp distribution
> should be separate and at arms length from ntpd.
> To conform to the spec, an sntp client MUST NOT function as a server.
> The only thing it MUST do is send a compliant packet to a legitimate
> server, receive a compliant packet and set the system clock. As the spec
> says, it would be NICE to use the ntp on-wire protocol and delay/offset
> calculations in order to avoid problems with timestamps in different
> eras. The spec says nothing about timeout/retry other than consecutive
> calls should be spaced at least 15 seconds with exponential backoff. The
> spec gives strong advice on the timeout between successive sntp runs,
> usually expected to be several days. The spec writers were very serious
> about these things, having been assaulted by the Netgear incident.
> The sntp client MUST cease operation with a server if a KoD is received
> and MAY switch to another server as backup. It would be NICE if sntp
> aborted in response to a ICMP error message. It would be USEFUL if it
> used something like the ntpd panic and step thresholds (which could be
> set much higher than ntpd). These are not specified in the rfc.
> Putting in anything beyond the strict specification is a slippery slope.
> >From a specification and normalization point of view, it MUST NOT
> perform additional functions other than specifically allowed in the
> specification. If it did, the auditors could suspect the additional
> features could be misused. See where I am going with this? It would
> certainly be possible that there will be j-random implementations of
> sntp including additional features, but those implementations cannot
> claim to be strictly compliant with the sntp specification. If an sntp
> product leaves these shores, it should be strictly compliant and should
> so state with emphasis.
> Some features are certainly possible and maybe even desirable in
> connection with the operating system, such as those you suggest. They
> have nothing to do with the protocol specification. It may even be
> possible to implement additional protocol capabilities, like operate as
> a server, but they MUST NOT be enabled in the default build and their
> configuration controls should be banished to a separate page in the
> documentation. Only if these features are disabled will the auditors be
> satisfied. Something like, if you break the seal the warranty is voided.
> Upon review of the spec, I see something broke in the security section
> markup. It references only a very old Autokey document, long since
> superseded. The spec says security features are optional, but if they
> are included, they must conform to that document. The writers intended
> to say that, if included, they must conform to the MD5 scheme documented
> in rfc1305 with OPTIONAL extensions in the Autokey document. The spec
> writers have no shame in this, since it took three years to survive the
> IETF process.
> My umbrella is deployed and I expect the rain.
> Dave
> Harlan Stenn wrote:
> > Dave,
> >
> >> In view of the time to build/test/maintain the software involved, I
> >> don't see the need to build anything fancy in sntp.
> >
> >
> > OK, what is "fancy"?
> >
> >> Is there a compelling reason not to promote ntp for anything but
> >> absolute bare bones service? Is there something compelling folks not
> >> to use ntp in sntp mode?
> >
> >
> > There are number of folks who believe ntpd is "too big" for leaf client
> > services, or even for intermediate services. They also think it is
> > overall too complicated and they are concerned about possible security
> > exploits and the difficulty of doing a code audit.
> >
> > This drives them to look for something else and/or spread FUD and/or
> > become nuisances.
> >
> >> With Sachin's new code, sntp configuration
> >> will be transparent to ntp. I would rather put people cycles in doing
> >> that than spinning tires with sntp afterthoughts.
> >
> >
> > That will help and I'd like to get this installed ASAP. I suspect that
> > it will not make the 4.2.4 release in the next month or so, but I expect
> > it will go in to ntp-dev as soon as it is ready after the 4.2.4 release.
> >
> > H
> > --
> >
> >>> Dave,
> >>>
> >>> I understand your desire to have a lean and mean sntp implementation.
> >>>
> >>> There are a couple of issues that come up, however, and I wonder if we
> >>> might be better served by either an sntp implemenation that has
> >>> configurable features, or offering 2 implementations (one lean and
> >>> the other more robust).
> >>>
> >>> Here are 2 examples:
> >>>
> >>> - Some people like to use some form of crypto keys for all their ntp
> >>> servers. Ignoring public key for the moment, this would require MAC
> >>> security and /etc/ntp.keys support for sntp.
> >>>
> >>> - many folks have a requirement that if the time is set (stepped) that
> >>> a UTMP/WTMP entry is made.
> >>>
> >>> If we can get sufficient consensus on what neds to be there we can do
> >>> this with a single program. Otherwise, I think we're gonne end up with
> >>> either a configurable program or "sntp" and "sntp-lite".
> >>>
> >>> What do you think?
> >>>
> >>> H
> >>
> _______________________________________________
> hackers mailing list
> hackers at support.ntp.org
> https://support.ntp.org/mailman/listinfo/hackers

More information about the hackers mailing list