[ntp:hackers] smearing the leap second

Harlan Stenn stenn at ntp.org
Wed Jun 24 02:53:07 UTC 2015


Danny Mayer writes:
> I've been following this thread with interest and I have the following
> comments.
> 
> 1) Stealing bits is wrong. That not a moral judgement but an
> architectural one. Whether you get them from the RefID or the fuzz bits
> of the timestamps you are not going to get what you want. If you take it
> from the RefID then the reference information will be incorrect and
> you've lost loop detection. Moreover it won't be usable unless it's a
> stratum 1 server and then you lose the information about the RefClock.
> If you take it from the fuzz bits you lose the purpose of those bits.
> There's actually a specific purpose to them. I don't remember all the
> details but they are important.

It is possible to convey the smear  offset value in an extension field.

The only instances of NTP that will know what to do with this are "new"
instances of NTP.

What happens with the tens of millions (could be 100M, not sure) that
don't know about this?

> 2) If you are following a smeared server then you should ignore the
> leapsecond notification since the smeared server is doing the work for
> you. If you are following one smeared server then all servers being
> followed have to be smeared. Furthermore you cannot perform smearing
> yourself.

How do you communicate that a server is smearing?

How does older software know it is following a smeared server?

> 3) If this is for NTPv4 then an extension field is they way to go, not
> only for the notification of the smear campaign but the algorithm being
> used to perform the smear. The extension field would not be needed for
> normal operation.

How does this help older, installed systems?

> 4) If we go to NTPv5 the information in the packet can be different but
> most of the above requirements would still be needed.

Sure.  And this won't happen in under a week.

> 5) If an NTPv4 system receives an NTPv5 packet what does it do with the
> packet? Is is supposed to drop it, or respond with an NTPv4 packet but
> how will it interpret the contents of the NTPv5 packet? Will it think it
> has an unknown extension field?

Why would an NTPv4 client ask for a v5 packet?

Why would a v5 server send a v5 response to a v4 request?

H


More information about the hackers mailing list