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

Rob Neal hundoj at comcast.net
Tue Dec 22 21:58:40 UTC 2009


With all due respect to the followers of POLA, my heart bleeds.

I would be astonished if the security model were violated by a
default configuration.

My sympathy for folk who insist on eliding the 'network' part
of NTP is equally great.

Keep the security model robust, please.

On Tue, 22 Dec 2009, David Mills wrote:

> 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