[ntpwg] Issues with the NTP draft -06

[Brad Knowles]

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.

-- 
Brad Knowles <brad at shub-internet.org>, Consultant & Author
LinkedIn Profile: <http://tinyurl.com/y8kpxu>
Slides from Invited Talks: <http://tinyurl.com/tj6q4>

09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0