Re: [chrony-dev] Frequency transfer in NTP

[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-dev Archives ]


On Thu, Jan 28, 2021 at 05:15:12PM -0600, Dan Drown wrote:
> I'm assuming the test case would be similar to the condition of "stratum 1
> was drifting but came back into sync with its upstream source".

Yes, that could make such a large offset, but in the test it was meant
for demonstration only. In normal operation, there is a small
correction, in both time and frequency, on every update of the clock.

> Does this proposed feature include a frequency error estimate like root
> dispersion's offset error estimate?

Not in the current proposal. I thought about exchanging the skew
value, but I didn't figure out what to do with it on the client.

> What are the security implications?  Does frequency transfer prefer slower
> frequency changes over fast?

Good question. This needs to be investigated. In a MITM attack
it might give the attacker (who can either freely modify any values in
the packet, or at least delay them if authentication is enabled) an
even greater control over the client's clock. Some limits on the
accepted frequency change may need to be implemented.

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/