NTP, possible solutions, and best implementation

Fri Oct 3 15:02:49 UTC 2003

The recommendations of others to place the Stratum 1 source behind another 
box is indeed good operational practice.  However if you _really_ want to 
provide Stratum 1 services there are a couple of options

1 - Purchase a Cesium clock this is a Primary Time/Frequency standard 
    which does not require access to a reference standard to maintain 
    accuracy.

    This is a Stratum 0 source so once placed behind a Unix/Cisco/Juniper
    box you have a stratum 1 source.   This will cost you 30,000 -> 
    100,000 US per unit.   The beam tube will require replacement
    approx every 5 years for about 20,000 US.

2 - Set up a stratum 1 source but use MD5 authentication to prevent 
    unauthorized users from accessing the service.

                            Scott C. McGrath

On Thu, 2 Oct 2003, Ariel Biener wrote:

> 
> 
> 
>   Hi,
> 
> 
>    Assuming one wanted to provide a high profile (say, at the TLD level) NTP 
> service, how would you go about it ?
> 
>    The possibilities I encountered are diverse, the problem is not the 
> back-end device (be it a GPS based NTP source + atomic clock backup, based on 
> cesium or similar), but the front end to the network. Such a time service is 
> something that is considered a trusted stratum 1 server, and assuring that no 
> tampering with the time is possible is of very high priority, if not top 
> priority.
> 
>     There are a few NTP servers solutions, I like the following comparison 
> between one company's products (Datum, merged into Symmetricom):
> 
> http://www.ntp-systems.com/product_comparison.asp
> 
>     However, when you put such a device on a network, you want to have some 
> kind of clue about the investment made in that product when security comes to 
> mind, and also the turnaround time for bug fixes should such security bug 
> become public. Here is the problem, or actually, my problem with these 
> devices. I know that if I use a Unix machine or a Cisco router as front end 
> to the network for this back-end device, then if a bug in NTP occurs, Cisco 
> or the Unix vendor will fix it quickly. BUT!, if I want to put the device 
> itself on the network, as this is what a NTP device was built for, I feel 
> that I have no real sense of how secure the device really is, and how long it 
> would take for the vendor to actually fix the bug, should such be discovered. 
> It's a black box, and I am supposed to provide a secure time source based on 
> ... "what ?"
> 
>    This is my dillema. While I don't want to put a NTP front end, which 
> becomes a stratum 2 in this case, but to provide direct stratum 1 service to 
> stratum 2 servers in the TLD in question, I do not know how can I safely 
> trust a device that I have no experience with how the vendor deals with bugs, 
> and also, I have no idea what is the underlying software (although it's safe 
> to assume that it is an implementation of xntpd, in one form or the other).
> 
>    Did any of you have to create/run/maintain such a service, and does any of 
> you have experience with vendors/products that can be trusted when security 
> is concerned (including the vendor and the products I specified above).
> 
> thanks for your time,
> 
> --Ariel 
> 
> 
> --
> Ariel Biener
> e-mail: ariel at post.tau.ac.il
> PGP(6.5.8) public key http://www.tau.ac.il/~ariel/pgp.html
> 