[ntpwg] Issues with the NTP draft -06

[Heiko Gerstung]

Brad Knowles schrieb:
> 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.
>>     
>
>   
I think that the stratum level does a much better job in avoiding timing 
loops, we probably should abandon the idea that the refid is anything 
more than an informational value. Is the refid really checked in the 
code? If it is (probably in the peer handling stuff) then I would 
suspect that it only covers direct connections to the next upstream 
server and does not perform a full loop check (server A -> server B-> 
server C -> server A).
> 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.
>   
I would say that the refid is no security related data object. I agree 
that the MAC address and IP can change, but I do not see any bad 
implications here, at least not for the operational status.

> 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.
>   
Using a public host key of the server would work as well. But I do not 
see that this helps in preventing loops, the only benefit I could see is 
if a server would carry all those unique IDs of all servers between the 
stratum 0 source and itself around and pass that list on to its 
downstream servers/clients. That would enable us to provide a "time 
trail" or a solution to the "traceable" time" stuff.

Regards,
Heiko


>>  I'd like to see recipients of KISS codes take actions dependent on the
>>  receipt of some of the codes.
>>     
>
> Excellent idea