[ntpwg] Issues with the NTP draft -06

[David L. Mills]

Guys,

The refid issue has always been a tug between backward compatibility and 
word size. The method chosen is not perfect, but is a good compromise.

Dave

Brad Knowles wrote:

> On 6/22/07, Danny Mayer wrote:
>
>> The problem here is that the refid is to be used to detect timing loops
>> but it can be any value that can do the job and should be unique for
>> each server and not interface address. Thus a server should have one and
>> only one refid irrespective of whether it is using IPv4 or IPv6
>> addresses. Tying it to an IP address is not really a good idea. Tying it
>> to a MAC address might be a better idea.
>
>
> You've got a MAC address per interface, so if you want to avoid doing
> anything on a per-interface basis, then using the MAC address is just
> as bad as an IP address. Moreover, with many high availability
> services, you can "steal" IP and MAC addresses from one machine to
> another, and you really don't want to base anything for NTP on
> something that could be moved from one machine to another on a
> moments notice.
>
> You need to choose something else that is relatively guaranteed to be
> unique on a per-server basis, is guaranteed to stay on that server
> and not move anywhere else, and is guaranteed to be unique regardless
> of how many interfaces, IP addresses, MAC addresses, etc... that may
> be on the server. For Suns, this might be hostid, but for other
> platforms I suspect you're going to need something else.
>
>
> Note that this unique id could change between reboots of the server,
> or stop-and-restart operations of the NTP daemon, etc....
>
> So, one potential solution would be for the NTP daemon to take all
> known MAC addresses, IP addresses, and other suitable information
> that is available at the time of the start of the NTP program and
> combine that with a suitably large pseudo-random number, and then
> generate an MD-5 or SHA-1 or SHA-2 hash of that number, extract the
> leftmost or rightmost four octets, and have that calculated value
> become the "refid".
>
> I'm not saying that this is the only solution, or even that it is
> necessarily the best solution. But it does seem to be a pretty good
> solution, and assuming you choose a "good enough" hash function, it
> should be sufficiently unique for the purpose of loop detection.
>
>> I'd like to see recipients of KISS codes take actions dependent on the
>> receipt of some of the codes.
>
>
> Excellent idea.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://support.ntp.org/pipermail/ntpwg/attachments/20070623/8b9633dc/attachment.html