[ntp:hackers] smearing the leap second

Greg Dowd Greg.Dowd at microsemi.com
Tue Jun 23 22:16:56 UTC 2015


I tend to echo Danny's thoughts on this.  And the fuzz bits were exactly that, fuzz bits to add entropy to prevent HMAC attacks, and I believe they are dynamically restricted by sys_precision maybe?  The thing I keep trying to understand is that, if the client needs to be modified to understand the smear data, and the smear data is based on the availability of the leap data upstream, why can't the client just decide to do this without any additional payload modifications?  

If leap is set and 24 hours to leap window, start slewing at desired rate.  Or step, or smear, or whatever you want?  I do understand the concept of getting them all to move together as a reasonable goal for ntpd, I just don't quite understand the logic of the backwards compatible, hidden transmission scheme.



-----Original Message-----
From: hackers [mailto:hackers-bounces+greg.dowd=microsemi.com at lists.ntp.org] On Behalf Of Danny Mayer
Sent: Tuesday, June 23, 2015 2:48 PM
To: hackers at lists.ntp.org
Subject: Re: [ntp:hackers] smearing the leap second

EXTERNAL EMAIL


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.

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.

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.

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

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?


Danny
_______________________________________________
hackers mailing list
hackers at lists.ntp.org
http://lists.ntp.org/listinfo/hackers


More information about the hackers mailing list