NTP, possible solutions, and best implementation
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@post.tau.ac.il PGP(6.5.8) public key http://www.tau.ac.il/~ariel/pgp.html
Really good back-end clocks, particularly when you're implementing a redundant system with a cesium clock or two, are a lot more expensive than the front-end servers that clients need to see. Do you have particular technical reasons you want to put the "actual device" on the net? Most of the time, the "actual device" in these cases is merely a linux box or something similar wrapped around a stratum-zero time source. A much easier way to do this, which gives you control over what faces the network, is to run your own front-ends of stratum 1 servers that all talk to the same network of back-end time sources: FE-1 FE-2 FE-3 | | | \--Time Distribution/ \ | / GPS Cesium Clock3 Put cards in the front ends that let them receive PPS or IRIG, and then let them all get a time signal from the back end clocks. The clocks on the FEs will be good to a handfull of microseconds. since the FEs will be synched directly to a stratum zero time source (the PPS signal from the GPS and cesium clocks, for instance), they'll be running at stratum 1. As a nice example of how you can structure this, see the udel NTP page. The added expense here will be purchasing an IRIG board for the front-ends, or you can decode it via the sound input, but if you go with a real irig board, you'll get a high-quality onboard oscillator that'll do a much better job of running free if it loses the backends. This way, you can have as many front ends as you need for (redundancy, scalability, ...) and they'll run a real OS that you control. No need to put an application level forwarder in the middle, since they _are_ your application level gateways to the PPS/IRIG signal. btw, comp.protocols.time.ntp is a good source of information about this kind of thing.. probably better than nanog. -Dave -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ I do not accept unsolicited commercial email. Do not spam me.
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@post.tau.ac.il PGP(6.5.8) public key http://www.tau.ac.il/~ariel/pgp.html
Hi, I wish to thank all who answered, indeed, it was helpful. But, as it was mentioned here, any further dwelling into this particular topic would be more appropriate in the NTP forums available, be it mailing lists or newsgroups. So, I would like to request that further replies on this topic are sent to me in private, and wish to thank again all that answered. --Ariel -- Ariel Biener e-mail: ariel@post.tau.ac.il PGP(6.5.8) public key http://www.tau.ac.il/~ariel/pgp.html
In the immortal words of Scott McGrath (mcgrath@fas.harvard.edu):
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.
They only cost that much new-in-box. :) http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=2560947055&category=25399 -n ------------------------------------------------------------<memory@blank.org> "`For Shame' isn't history; it's a rant -- another in a seemingly endless parade of dumb books lamenting `the dumbing of America.'" (--David Futrelle) <http://blank.org/memory/>----------------------------------------------------
"Nathan J. Mehl" <memory-nanog@blank.org> writes:
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.
They only cost that much new-in-box. :)
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=2560947055&category=25399
The device Nathan references above is a bunch of isolation amplifiers in a box, used to distribute a standard timing signal to a number of users without mutual interference to the pulse shape from the end-user equipment. It does not contain a primary frequency standard, but has connections for up to three external references (which are hopefully running in lockstep :). While it's true that HP 5061B and 5071 Cs beam frequency standards are available for far less than the list prices quoted above, they're not available in working condition on eBay for $350. :) I think last time I checked refurbished tubes for the 5061B were a $5-7k proposition. As others have noted, CDMA-disciplined NTP clocks such as those from EndRun are indirectly disciplined by GPS in the vast majority of cases. It would probably be more honest to configure them to claim to be stratum 2 NTP servers, but don't tell the marketing folks that; they'll pitch a fit. With GPS based NTP appliances, one must pay attention not only to the manufacturer of the box, but to the actual manufacturer of the GPS module inside the box. In years past the Motorola VX and UT OEM modules have been included by more than one player as the "guts" of the machine. Other likely sources are WWV/WWVH (2.5, 5, 10, 15, 20 mhz; medium term jitter can be problematic due to propagation changes), WWVB (60 khz, less jitter than WWV, but can be hard to receive ih a high-rfi commercial environment), CHU (3330, 7335, 14670 khz if you prefer a Canadian shortwave time/frequency service), DCF77 (for Europe, not too useful in North America), Loran-C is of limited life expectancy, and NIST is planning to cease involvement with time code signals on the GOES satellites after 1 January 2005 (although the birds will continue to provide the timecode, NIST will no longer be controlling and checking the signal). Therefore, it's probably not a good idea to make future plans based on either of these services (although equipment to implement them short-term may be available at bargain prices!) The following links may be of interest: http://tycho.usno.navy.mil/ http://www.boulder.nist.gov/timefreq/ http://www.ntp.org/ ---rob
participants (5)
-
Ariel Biener -
David G. Andersen -
Nathan J. Mehl -
Robert E. Seastrom -
Scott McGrath