Re: [Ntp] SNTP, Old crufty software

[Martin Burnicki <[e-mail]>]

Hal Murray wrote:
> 
> There is a lot of NTPv1 traffic out there.  It's ballpark of 1% of the traffic
> to pool servers
> 
> I have credible reports that some of the NTPv1 traffic is from reasonably
> modern gear.

That's exactly what I'm assuming, as I've mentioned earlier.

The question is how a good server should deal with such requests. From 
our customers I know that they would really like it if they bought an 
NTP server from us, and even the devices on the customer's network that 
come with dumb client software can at least get the time from the server.

That won't work if the server rejected or discarded requests only 
because they have "v1" as version code.

I remember some years ago when Windows XP/Server 2003 was current, the 
dumb SNTP client (w32time) shipped with that Windows versions sent 
"peer" requests to the NTP server by default,

Of course the NTP server could just discard such requests, but that 
would users ask if you had a workaround for the problem. As a result a 
hack made it into ntpd which let the server send appropriate responses 
to such clients anyway, which made the life of Windows admins much 
easier and didn't cause any harm even though the intended behavior was 
not met.

So for cases like this I agree with Harlan when he said that the server 
should be tolerant to requests.

> Has anybody looked at RFC 4330 (SNTP) lately?  It's 27 pages.  Much of it is
> not useful if you are only intereted in the S part of SNTP.  It's a lot less
> simple than it could be.

Since SNTP basically uses the same packet format as NTP, in my opinion 
the real S(imple) attribute refers to the way the packet exchange is 
evaluated at the client side.

I've seen implementations where the client didn't even try to compensate 
the network delay, and just used the server's transmission time stamp to 
adjust the client time. Probably because the programmers though that the 
resulting accuracy id "good enough".

And of course, such an implementation is not suitable to act as server 
for full-featured clients.

> ------------
> 
> I think it's time for another pass at the greater SNTP area.
> 
> I'm focused on code that will go into firmware and won't get updated with
> typical distro updates, if ever.
> 
> I see three parts.
> 
> The first is that we have to agree on what will be supported for a long time.
> I assume that is a simple NTPv4 Client/Server exchange with no MACs or EFs.
> 
> The second is the protocol level.  I think we need a simple description of
> what you get from a protocol exchange, how local clocks operate, and the
> choices/benefits between ultra simple and not quite so simple.
> 
> I assume we should have sample code.  Can we maintain that off to the side
> rather than frozen in a RFC?
> 
> The third is operational. We need a BCP for people writing/distributing
> firmware and those who will be using/supporting that firmware.
> 
> We should get some of the firmware writers/users in the review process.

Of course, all of the above would be nice to have. However, I doubt that 
developers who don't even RTFM how to correctly set up a basic request 
packet will read this.

> -----
> 
> I propose that SNTP requests (Client mode) should (ab)use an otherwise unused
> timestamp field to hold a text string for vendor info.  That will allow
> operational people to identify which gear is causing problems.

Once more, I doubt that programmers that don't get a basic request 
packet set up properly will put anything useful.

IMO the problem is the same as with the kiss-of-death feature: "Good" 
clients that behave well will probably never receive such a packet from 
a server, and clients that are misbehaving won't care anyway and won't 
reduce their polling rate.

> -----
> 
> Is anybody using SNTP interested in security?

I don't think so for the reasons mentioned above.


Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [e-mail]
Phone: [phone]
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, 
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com