[Ntp] Antw: [EXT] Re: SNTP, Old crufty software

[Ulrich Windl <[e-mail]>]

>>> Doug Arnold <doug.arnold=[e-mail]> schrieb am
12.08.2022 um 16:46 in Nachricht
<[e-mail]>

> A lot of (understaffed) IT teams are consumed by solving the current biggest

> problem.  So they are not deciding to leave old ntp versions because they
are 
> working, but rather they don’t know that they are there at all.  They were 
> installed before years ago by someone else and haven’t caused a problem that

> resulting in an upgrade to a newer version of ntp.  .
> 
> I think that the best way to handle old versions of NTP is for servers to 
> respond to NTP requests in the same version that they received.  People 

Well, I think no software can fix management or operating mistakes:
A company should know what servers and clients it runs.
And I think there is kind of agreement that NTP servers may respond to older
protocol requests as long as they support those.
But that will mean eventually that some requests won't be answered forever.

> implementing NTP servers can select which versions of NTP they will support,

> with the ability of a network admin to turn the versions on or off by 
> configuration.  NTP clients could start with the most recent version of NTP

> they support and work down.

I think the obvious "must requirement" for a new NTP version is that the
previous "official" version must be supported as well.
Still, implementers have the choice to support even older versions.
But as Intel dropped 16 bit support in their latest CPUs, some of the ancient
NTP versions have to be dropped some day.

Regards,
Ulrich

> 
> Doug
> 
> From: ntp <ntp‑[e-mail]> on behalf of James Browning 
> <[e-mail]>
> Date: Friday, August 12, 2022 at 7:34 AM
> To: NTP WG <[e-mail]>
> Subject: Re: [Ntp] SNTP, Old crufty software
> On Fri, Aug 12, 2022, 04:06 James 
> <[e-mail]<mailto:[e-mail]>> wrote:
> 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.
> 
> We had simpler protocols that turned out to be amplifiers, I tried killing 
> off the broken crap in NTPsec before having the 'stick' taken away and being

> beaten with it.