Re: [Ntp] SNTP, Old crufty software

What (dis)incentives are there for the people and companies writing, reusing, deploying code still using these protocols to work on them? I'm not sure there is many given "it still just works". A well defined carrot (e.g. a simpler/secure/etc protocol) or stick (popular public time services ceasing support for legacy protocols) are the only dimensions I can think of here.

I'm not sure the effort of trying to -bis SNTP is as beneficial as advancing newer work like Roughtime and its implementations, combined with BCPs or other such guidance that dissuade future use of these older protocols.

- J

> On 12 Aug 2022, at 00:25, Hal Murray <halmurray@sonic.net> 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.
> 
> 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.
> 
> ------------
> 
> 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.
> 
> -----
> 
> 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.
> 
> -----
> 
> Is anybody using SNTP interested in security?
> 
> -----
> 
> Is there any BCP for firmware writers/deployers?  Things like don't hardwire 
> in any DNS names (that you don't own).  Or a WG that covers that area?
> 
> -----
> 
> stenn@nwtime.org said:
>> Are they real v1 requests, from software that is about 40 years' old, or is
>> it a v3/v4 header where the implementor chose to identify it as v1? 
> 
> I have no insight into how the programmers were thinking.
> 
> I assume much of it is old code that works so nobody pays attention to it.
> 
> Roughly half of the NTPv1 requests have a 0 in what is now the mode field.  
> Roughly half have a 3/Client in there.  There is also a small bump on the tail 
> with symm-active.
> 
> There is also NTPv2 traffic.  It is essentially all Client/request.
> 
> Roughly 90% of the NTPv1 requests have 47 bytes of 0 after the 
> leap/version/mode byte.
> Another 10% have stuff in the last 8 bytes, the transmit timestamp field.  A 
> 1/2% has other stuff I haven't investigated.
> 
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp