[ntp:questions] Thoughts on KOD

Rob nomail at example.com
Tue Jul 8 11:11:28 UTC 2014


Harlan Stenn <stenn at ntp.org> wrote:
> Rob writes:
>> Harlan Stenn <stenn at ntp.org> wrote:
>> > Rob writes:
>> >> Jan Ceuleers <jan.ceuleers at computer.org> wrote:
>> >> > I recommend providing motivation for the undesired clients to stop using
>> >> > the server, by the server sending a regular response indicating that it
>> >> > is not synchronised or replying in some other way that has no
>> >> > timekeeping value to the offending client.
>> >> 
>> >> Well, that is what KOD actually is.
>> >> However, it has so many broken and inconsistent bits that some clients
>> >> believe that they have received a corrupted packet and decide to re-try
>> >> the request to see if that results in a better response.
>> >
>> > What are these "many broken and inconsistent bits" of which you speak?
>> 
>> Strange stratum, both leap bits set, etc.
>
> The definition of a KoD packet is that the Stratum field is 0, which *by
> definition* is unspecified/invalid.  Neither broken nor inconsistent.
>
> If the system sending the KoD sets both leap bits, again, *by
> definition* that means the sending system is saying "my clock is invalid
> - don't believe it."  Neither broken nor inconsistent.

What I mean is that those fields are not what the simple client expects
to get, and those stupid programmers believe that they can get a correct
reply by re-trying the request.

> If somebody chooses to implement an NTP client that blows past these
> core definitions in the NTP RFCs that's their fault.  We're talking
> about definitions that are unchanged since NTPv1.

Of course when programmers would follow definitions and specifications
the whole problem would not exist.  But in practice, programmers tweak
their code just long enough to get it working during some testing, and
they are not prepared to handle errors or replies they never see during
testing.

> I'm not buying your assertion, but I could be missing something. Also,
> you did say "etc" and there might be some other cases there that would
> change my mind.  But I doubt it, as S0 is a showstopper, as is LI=3.

I have no idea what software was running at the other end and what
failure modes it has.  I only saw the reactions to obvious things I
tried (like dropping requests and sending KOD replies).
Things were not looking good.  And when I googled for it, I quickly
discovered I was not the only one making these observations.



More information about the questions mailing list