[ntpwg] Issues with the NTP draft -06

[TS Glassey]

----- Original Message ----- 
From: "Brad Knowles" <brad at shub-internet.org>
To: <mayer at gis.net>; "NTP Working Group" <ntpwg at support.ntp.org>
Sent: Saturday, June 23, 2007 12:29 AM
Subject: Re: [ntpwg] Issues with the NTP draft -06


> 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.

OK - lets jump up to 200000 feet and quantify this model - and the 
requirement... So then you are looking for a way to anchor the trust and 
integrity model for the NTP Server to a physical source or site.

>
> 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.

A system specific PKI Token is the way to go. And NTP can lead the way into 
this 'brave new world' of 'computing images with integrated integrity' - 
i.e. the identity that is unique and mechancially verifiable.

>
>
> Note that this unique id could change between reboots of the server,
> or stop-and-restart operations of the NTP daemon, etc....

Not if the ID is registered in the DNS services as part of the 'Well Known 
Service'

>
> 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".

Yes, this has been proposed before as well. But it doesnt tie the NTP Server 
to the legal jurisdiction its operated in and that is the key from a 
commercial use standpoint from the NTP Audit Model...

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