[ntp:questions] basic questions about the leapsecond

David L. Mills mills at udel.edu
Tue Dec 16 16:19:35 UTC 2008


Martin,

Correct. The ntpd (development version) does all that. However, there 
are concerns about protocol spoofing and other vulneabilities. First, 
the only upstream candidates considered are the survivors of the 
mitigation algorithms, generally three candidates. If a reference clock 
is among them, only its leap bits are used. If not, a vote is taken 
amoung the survivors and the majority is used. If two out of the three 
show leap, the result is leap. It two out of the three show no leap, the 
result is no leap.

The older code is very vulnerable to a terrorist showing leap or failing 
to pass on leap warnings received from upstream servers. The Autokey 
design was initended to reduce this vulnerability. I suspect the actual 
behavior with most servers using only the older code will not support 
leap warming due to driver or radio shortcomings. If this is the case, 
the voting scheme will fail to show the warning. There;s not much that 
can be done about that other than to upgrade to the development version 
and use either the leapseconds file or Autokey.

It gets worse. What happens if the leapseconds file is present along 
with Autokey and upstream leap warnings. Most of the time the file takes 
precedence and the other warnings are ignored. However, if Autokey shows 
leapsecond values newer than the file, then those values take 
precedence. If either the file or Autokey is present, upstream wabrings 
are ignored. On the other hand, if upstream warnings are in play, the 
leap bit vote can change with the server warning as the result. Finally, 
and with this you should understand the complexity of the scheme, what 
happens if the host time is changed significantly by the NTP protocol 
itself? Thus, the priorities are redetermined each time the clock is 
updated.

Dave

Martin Burnicki wrote:

>David,
>
>David J Taylor wrote:
>  
>
>>David L. Mills wrote:
>>    
>>
>>>David,
>>>
>>>In the NTPv3 spec the leap bits are to be set on the day of the leap.
>>>This is compliant with the new NTPv4 spec; that spec is more liberal
>>>in order to support and prioritize leap warnings when multiple means
>>>are available. In cases where the radio delivers a timecode via
>>>serial port, some radios include provisions for leap warning; some do
>>>not. I don't know if an NMEA sentence has provisions for that. There
>>>are no provisions for leap warning in IRIG devices I have.
>>>
>>>I  don't know if the Meinberg GPS or EndRun CDMA receiver include
>>>provisions for leap warning. If so, it should appear in the NTP header
>>>on the day of the leap. Both receivers use an embedded Linux system
>>>which in principle has the same provisions as the public
>>>distribution..
>>>      
>>>
>
>Dave,
>
>please see my other reply or 
>http://www.meinberg.de/english/info/ntp.htm
>to see how Meinberg devices work.
>
>  
>
>>Thanks, Dave.  I don't know about the NMEA sentence either, but I don't
>>recall seeing that possibility.  On my GPS-based server, it does also have
>>Internet sources, but even though one of those sources is showing the leap
>>bit, my server is not.
>>    
>>
>
>I'm not sure about this, but maybe it depends on the classification of an
>upstream server (whether it is in the surving group of ppeers after the
>selection algorithm) whether the leap second announcement is accepted, or
>not.
>
>  
>
>>I'll have to check on December 31st.  It will be 
>>disappinting if I have similar problems to last time!
>>
>>  http://www.satsignal.eu/ntp/ntp-events.htm#leapsecond
>>
>>In view of the popularity of the GPS18-LVC it's a pity that the driver
>>support for the leap second isn't better, but I appreciate that being able
>>to test once every few years doesn't make things any easier!
>>    
>>
>
>There is a complete chain which needs to be able to propagate the
>announcement of a leap second.
>
>- From the GPS satellites to the receiver
>
>- The receiver must output a time string format which supports
>  leap second announcements, and must set the announcement correctly
>
>- NTP's driver for that device must evaluate the announcement in the
>  string correctly and pass it on to the NTP kernel
>
>If you are not sure whether the whole chain you're using supports leap
>second announcements correctly you should install and use the NIST leap
>second file on your server(s).
>
>If you discuss ways to announce leap seconds you also have to distinguis the
>*way* leap seconds are announced.
>
>E.g. both the GPS satellites and the NIST leap second file do not only
>announce an upcoming leap second, they also contain information *when* the
>leap second will occur, so unless there is a software bug which does the
>evaluation wrong you could start to announce the leap second as soon as the
>IERS has published this.
>
>If there's just an announcement flag (like the leap bit in the NTP packet)
>that bit should should not be set until the moment of leap second insertion
>is unambiguous.
>
>Martin
>  
>




More information about the questions mailing list