[ntp:hackers] Receiving smeared time

Miroslav Lichvar mlichvar at redhat.com
Tue Jun 30 11:21:22 UTC 2015


On Tue, Jun 30, 2015 at 10:13:54AM +0000, Harlan Stenn wrote:
> Miroslav Lichvar writes:
> > I meant to fix all 32 bits of the refid, i.e. don't encode any offset
> > there as it's not very useful. I think a chance of 1 in 4 billions is
> > acceptable.
> 
> How is it not useful?  It provides a way that a client can "undo" the
> smear if that's useful, or at least see what the current correction is.

A client that can be modified to undo the smear could as easily be
modified to apply it locally to time served by standard NTP server. I
think the whole point of smearing server time is to have a workaround
for clients that can't slew their clocks.

> And it may not be useful to you (which is perfectly fine), but I do
> believe it is useful to some folks.

What exactly they do with it? And what will happen if they use a
server with IPv6 address which generates a refid starting with 254?

> > That would be an incompatible change in NTPv4.
> 
> How?  If A switches to using 255.a.b.c and syncs with B, and B follows
> A, when A looks at B's packets to see what refid it is following it sees
> the one A is using.  Loop detected.

The problem is that B will not know when A is synchronized to it. The
packet sent from A to B will have a refid which will not match the B's
own refid by the old definition.

> > In NTPv5 the NTP packet could contain two refid values, the server's
> > own refid (a randomly generated number) and the refid of its
> > synchronization source.
> 
> If the refid is randomly generated there's a chance two machines will
> grab the same one.  Granted, a small chance, but when it happens it will
> be fatal.

You would need tens of thousands of servers communicating with each
other to have a reasonable chance there will be at least one conflict
in refid between them. If there is a conflict, the source will just be
ignored, it's not a fatal condition.

Anyway, that problem is already there with refids constructed from
IPv6 addresses. And you are now proposing to use only 24 bits and make
the collision even more likely. 

-- 
Miroslav Lichvar


More information about the hackers mailing list