[ntp:hackers] Minimal NTP smear hack

Harlan Stenn stenn at ntp.org
Mon Jun 22 03:47:13 UTC 2015


brian utterback writes:
> On 6/21/2015 1:34 PM, Harlan Stenn wrote:
> > Brian Utterback writes:
> >> On 6/21/2015 10:33 AM, Terje Mathisen wrote:
> >>> smear_refid[3] = base64[usmear >> 26];     // 6 bits 
> >> What are the first three bytes of smear_refid? Are they special?
> > Yes, 'SMR', in this proposal.
> 
> Okay, I see a couple of problems with this.  The first two are what I
> said before, if you usurp the refid then it will cease to function as
> a refid. Second, most servers are not peers. New issues: It is all
> well and good to encode the smear offset, but why bother since this
> patch does nothing to actually read the info from the upstream
> server. And if I recall correctly, the low order bits of the transmit
> timestamp serve a security function, which is also usurped if you
> start encoding in them.  Are we assuming that the downstream
> servers/clients never have leap second files and will only ever know
> about the leap second from the upstream servers? If so, then I guess
> there is no risk of applying the smear twice, but is that a good
> assumption?

Aside from Brian's comments, we might want to see what Swisscom
(Schweiz) AG - Bluewin thinks of this idea, as using the refid of SMRx
for anything other than the S1 case will be indistignushable from an NTP
server in their IP range.

If we're going to do something with the refid, it seems safer to me to
use my proposal, knowing that the seconds portion of the smear should
always be 0, so a refid of 240.x.y.z would mean "I'm smearing and my
offset in fractional seconds is xyz."

I imagine nobody will be using that information in time, but if we're
heading down this route it would be useful to do this.  And while I
still think we'd want to increase the root dispersion by the amount of
smear we're adding, we wouldn't need to mess with the precision or any
of the other parts of the packet (aside from our T2 and T3 stamps).

I also thought I read that somebody thought it would be bad if a client
sent a message and saw that T2 or T3 was smaller than T1 or T4 - this
doesn't make sense to me, as that's the expected behavior if the
client's time is ahead of the server.

H


More information about the hackers mailing list