[ntpwg] Issues with the NTP draft -06

[David L. Mills]

Heiko,

Yes, the loop test is rigorously implemented and it really does work. 
Note that the Bellman Ford metric is already biased in order to avoid 
loops in the first place, but loops can still form in manycast and 
multiple broadcast configurations. If you look very carefully, you will 
note that not only does the test avoid loops, but it avoids cases where 
your neighbor is synchronized to the same server as you.

I say again, the scheme is not perfect, but it --is backward compatible 
with previous versions--.

Dave

Heiko Gerstung wrote:

> 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
>
>
>
> _______________________________________________
> ntpwg mailing list
> ntpwg at support.ntp.org
> https://support.ntp.org/mailman/listinfo/ntpwg


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://support.ntp.org/pipermail/ntpwg/attachments/20070625/021b0895/attachment-0001.html