[ntp:hackers] Receiving smeared time

Danny Mayer mayer at pdmconsulting.net
Tue Jun 30 04:17:20 UTC 2015


On 6/29/2015 2:36 PM, Harlan Stenn wrote:
> Miroslav Lichvar writes:
>> On Sat, Jun 27, 2015 at 09:18:53PM +0000, Harlan Stenn wrote:
>>> Since there is no way in NTPv4 or earlier to note that the timestamps in
>>> a packet contain a smear adjustment, one if the things I just added was
>>> a change to the REFID for these packets.  If an NTP timestamp packet
>>> contains a refid of the form 254.a.b.c then the 24 bits provided by
>>> a.b.c are a 2:22 integer:fraction that contains the amount of the smear.
>>
>> I don't think this is a good idea. As I said in the other thread, this
>> will often conflict with IPv6 addresses. I see several public servers
>> from pool.ntp.org that have an address for which the refid starts with
>> 254 and would appear as constantly leap smearing. For instance
>>
>> http://www.pool.ntp.org/scores/2a02:2b88:2:1::12db:1
>>
>> has a refid of 254.229.55.5.
>>
>>> If ntpd gets a timestamp with one of these refids, what should it do?
>>
>> I think that should have been answered before the offset encoding in
>> refid was implemented.
>>
>> It's still not clear where this would be useful. If an NTP
>> server/client that doesn't understand the leap smear is allowed to be
>> in the network, it will not pass the leap-smearing refid to its
>> clients and they will not know they are getting a leap smeared time.
>> If all servers/clients in the network understood the refid, they could
>> apply the offset locally and there would be no need to adjust the
>> timestamps exchanged in NTP packets. It could be an opt-in extension.
>> Now it's opt-out, but unreliable.
>>
>> To me it makes more sense to use a fixed refid (e.g. 127.127.?.?), so
>> a leap smearing server can still be detected and false positives are
>> unlikely.
> 
> An IPv6 hash can start with 127. just as easily.  127.127 is better, but
> we need more than 16 bits for the data.
> 
> We're not doing anything with the refid right now.
> 
> I've got code ready to go to change the IPv6 refid hash to 255.<3 bytes
> of the MD5 hash of the IPv6 address) and an update to the RFC to go
> along with it.
> 
> Will that change be sufficient?
> 
> I know we can't fix old software.  There will be old software even if we
> find better ways to fix things in NTPv5.
> 
> What would be better solutions to these things?

The real problem here is that the Refid is NOT an IP address. From the
RFC it is meant to be formed from an IP address but any 32-bit number
will do. Furthermore the reference implementation makes the mistake of
setting the Refid based on the IP address from which it is sent instead
of setting up and using the same Refid for ALL interfaces and addresses.
The loop detection is even wrong. If the Refid had been displayed in
ntpq as say hex characters we wouldn't be having this discussion in the
first place.

If you are intending to update the RFC, let's specify it correctly and
state that the same Refid should be used on ALL ip addresses regardless
of the type of address and that it does not need to be formed from an IP
address.

Danny




More information about the hackers mailing list