[ntp:hackers] On orphans, provenance and local clocks

David Mills mills at udel.edu
Tue Dec 22 18:12:10 UTC 2009


Guys,

The default you suggest will surely violate the Principle of Least 
Astonishment for those folks who now operate isolated networks.A 
possible refinement is to set the default to whether a reference clock 
othe than the local clock driver is configured. This gets tricky for 
broadcast or manycast modes.

Dave

Todd Glassey wrote:

> Rob Neal wrote:
>
>> First option, don't violate the security model.
>>   
>
>
> Thanks Rob for bringing this up in exactly these terms. The fact that 
> there is a security model means we need a BCP for its use and for 
> auditing it.
>
> Todd
>
>> On Mon, 21 Dec 2009, David Mills wrote:
>>
>>  
>>
>>> Folks,
>>>
>>> Dave Hart has concocted a semaphore designed so that other processes 
>>> can
>>> know when the clock is first synchronized to a proventic source. Doing
>>> so raises an issue with the local clock driver and orphan mode when the
>>> only sources are orphan parents or the local clock driver. The security
>>> model requires the clock to be set only when there is at least one
>>> proventic source confirmed upon receipt of packet with valid message
>>> digest or, in the case of Autokey, upon verification of the group
>>> credentials with valid signature and message digest. Alternatively 
>>> or in
>>> addition, an update received from a reference clock is by definition
>>> proventic.
>>>
>>> There are a couple of problems when the local clock driver or orphan
>>> mode are configured along with remote servers. In the current design it
>>> can happen that the local clock driver synchronizes the clock before a
>>> remote server, at least until the remote server dispersion settles 
>>> down.
>>> If the client is in fact a secondary server, it would appear legitimate
>>> to dependent client while in fact not synchronized to a proventic
>>> source. As orphan mode is designed to look like a local clock 
>>> driver, it
>>> has the same problem.
>>>
>>> The eclectic epoch of initial synchronization is declared only once in
>>> the lifetime of the association, that is when the leap indicator is
>>> changed from 3 to zero. That is done in the clock_update() routine and
>>> in the timer routine in orphan mode.
>>>
>>> There are a three of ways to approach the issue, but they raise some
>>> compatibility issues sure to make folks upset. The first is to disable
>>> the local clock driver and orphan mode until the clock is set by a
>>> proventic source. That could mean isolated networks with intentionally
>>> no outside sources would never synchronize. But, once synchronized to a
>>> proventic source, the local clock driver and/or orphan mode would be in
>>> play. The second is to ignore the problem and consider the local clock
>>> driver and orphan mode insecure. The third is to provide an
>>> enable/disable switch between the first two ways and set the default by
>>> majority vote of list members.
>>>
>>> Your call.
>>>
>>> Dave
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> hackers mailing list
>>> hackers at lists.ntp.org
>>> https://lists.ntp.org/mailman/listinfo/hackers
>>>
>>>     
>>
>> _______________________________________________
>> hackers mailing list
>> hackers at lists.ntp.org
>> https://lists.ntp.org/mailman/listinfo/hackers
>> ------------------------------------------------------------------------
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com Version: 8.5.430 / Virus Database: 
>> 270.14.116/2580 - Release Date: 12/21/09 19:13:00
>>
>>   
>
>



More information about the hackers mailing list