Re: [Ntp] [EXT] Hard NO: Re: WGLC - draft-ietf-ntp-ntpv5-requirements

Hi!

I wonder about the "defined response to a "time impulse"": Sure there should be a reference implementation (in the sense of an example), but is it really necessary for NTP to work?
Probably the original idea was that every host on the Internet would be well-behaving, but there days we know that not every host connected to the Internet is well behaving:
Shouldn't NTP be able to separate the good guys from the bad guys? I mean: If the client/server response looks plausible, then why not accept it whatever algorithm is behind, and opposite if the response looks bad, ignore it (also whatever algorithm is behind).
I mean: If NTP is actually relying on every client to use some specific algorithm to provide responses, wouldn't that actually make an attack on NTP easier (as clients must seemingly trust what the "good algorithm" returned, even if the response is hostile)?

Kind regards,
Ulrich

-----Original Message-----
From: ntp <ntp-bounces@ietf.org> On Behalf Of Harlan Stenn
Sent: Thursday, December 14, 2023 12:16 PM
To: James <james.ietf@gmail.com>; Steven Sommars <stevesommarsntp@gmail.com>
Cc: Karen ODonoghue <kodonog@pobox.com>; ntp@ietf.org
Subject: [EXT] [Ntp] Hard NO: Re: WGLC - draft-ietf-ntp-ntpv5-requirements

On 12/14/2023 12:29 AM, James wrote:
> My responses inline.
> 
>> On 14 Dec 2023, at 01:45, Steven Sommars <stevesommarsntp@gmail.com> wrote:
>>
>> My interpretation of the draft NTPv5 requirements is that there are intentionally no NTPv4 compatibility requirements.
>> E.g., the base payload length may not be 48 bytes, the messages may differ from NTPv4.
>> If this is not the intention, the draft should be updated accordingly.  If no consensus can be reached the NTPv5 requirements should state this clearly and work on the NTP protocol itself should be paused.
> 
> There is no intention for any such compatibility - Section 4.6 outlines what should be considered. Servers and clients should have defined behaviour based on the version number primarily. I'm not sure why payload length is of concern here - could you please elaborate as to why?

The protocol used by NTP was designed to be able to be compatible and at 
least useful between NTP packet versions.

This proposal seems to break this assumption, for no apparent good 
reason.  The authors have apparently explicitly chosen to advance a 
proposal that has interoperability "difficulties".

If a time sync specification is desired that owes no effective 
interoperability to previous versions:

- Don't call it NTP
- Don't run it on port 123
- Focus on whatever you choose, and stay out of everybody else's way

Next, I see nothing in this proposal about how NTP should behave.

The core "mission" of NTP is time synchronization with a (well) defined 
response to a "time impulse".  This is the reason why previous NTP 
specifications have included the algorithms.  Prof. Mills and some 
others have done a LOT of testing to ensure reliable and predictable 
behavior of time synchronization, in the "normal" and "time impulse" 
cases over a very wide range of circumstances.

Prof. Mills and others have clearly demonstrated that it is entirely 
possible (and quite easy) to violate the algorithms and boundary 
constraints.  Sometimes this causes no apparent problems.  At other 
times, time synchronization quickly breaks.

NTP RFCs are often specified as contract requirements.  The behaviors 
and benefits provided by the algorithmic and bounds specifications of 
NTPv4 (for example) exist separately and independently from anybody's 
belief or their degree of comprehensive understanding.

Without specifying fully vetted algorithms and bounds, adoption of this 
proposal shifts the burden of time synchronization and time impulse 
response behavior to every user of this proposal, and I submit the 
overwhelming majority of these users are in no position to even 
appreciate this, let alone understand and specify the behavior they 
actually need, and then codify it in a contractually useful way.

So once again, if this is what y'all want to do:

- Goferit
- Don't call it NTP
- Don't run it on port 123
- Do nothing to impede ongoing work with other similar efforts

I'm not going to focus on anything else in this "proposal".

For the past many years' time the IETF NTP WG meetings have been held at 
the worst possible time for my schedule.  I've repeatedly told this to 
the chairs and the AD.  This upcoming meeting is again at such a time, 
so I won't be attending.

-- 
Harlan Stenn <stenn@nwtime.org>
http://networktimefoundation.org - be a member!

_______________________________________________
ntp mailing list
ntp@ietf.org
https://www.ietf.org/mailman/listinfo/ntp