[ntp:hackers] smearing the leap second

Danny Mayer mayer at ntp.org
Wed Jun 24 12:35:55 UTC 2015


On 6/23/2015 10:53 PM, Harlan Stenn wrote:
> 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?
> 

There is actually nothing you can do about this. If they don't recognize
the extension field then they won't recognize the other proposals either
so doing it right is better than confusing the receiving clients. They
won't know about the smearing but if they have correctly configured
their ntp server they will also be pointing to other servers which may
or may not be performing smearing. Then they will either reject the
smeared servers through the clock selection process as server time out
of a valid range or only see the smeared ones as valid and can in fact
oscillate back and forth between the two types of servers. And then it's
been notified about a leap second event and it will then follow the
existing protocol for handling leap seconds and will then be out of sync
with the servers it's using and will have to be brought back into line.
Sorry but there are no simple answers.

>> 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?
> 

It can only get that information if it is using the newer version of ntp
that is aware no matter what method is chosen for communication.

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

It doesn't.

>> 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?

It can't since they have no way of being aware. See my comments under 1).

> 
>> 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.
> 

Or a year.

>> 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?
> 

You misunderstood. What I'm trying to say is that there will eventually
be NTPv5 servers out there. They won't know if the servers that they are
contacting are NTPv4 or NTPv5. If the NTPv4 server gets a v5 packet what
does it do? What should it do?

Danny


More information about the hackers mailing list