Re: NTP, possible solutions, and best implementation
As Mr. Dillon observed, regional service seems prudent, if only to minimize timing problems at the IP layer, much less for reliability purposes. An alternate time source could be the GLONASS system. Receivers do exist, but I have never used one. Sanity checking sources could include WWVB in the US, and many others: http://www.cl.cam.ac.uk/~mgk25/lf-clocks.html The US FAA is transmitting WAAS correction signals. Depending on the algorithms in the GPS receiver, this may result a reduction in PPS jitter. (although any such jitter is probably swamped by the jitter at the IP layer) There is at least one GPS receiver that will deliver 20PPS output, if needed. It is often possible to directly interrogate the GPS receiver to find out how many satellites it can see, and what the signal strengh conditions are. This will allow you to verify the adequacy of the outside antenna installation. If this is serious business, then it might be prudent to make a permanent connection that allows this interrogation (terminal server interface), and to check the constellation visibility and signal conditions on a periodic basis, not just at installation time. (Someone might put something else up on the roof that blocks your antenna's view of a portion of the sky...) Best wishes, Bob Enger ----- Original Message ----- From: "Ariel Biener" <ariel@fireball.tau.ac.il> To: <nanog@merit.edu> Sent: Thursday, October 02, 2003 10:54 AM Subject: 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
In message <003501c38940$34098fe0$eea28c45@wifey>, "Robert M. Enger" <enger@seka.erols.net> wrote:
An alternate time source could be the GLONASS system. Receivers do exist, but I have never used one.
Note that GLONASS satellites are failing frequently, and unlike GPS satellites, are not always being replaced. Currently only eight are operational out of a desired constellation of 24. http://www.glonass-center.ru/nagu.txt GLONASS is also subject to many of the same failure modes as GPS -- antenna failure, jamming, &c. A very robust design would fall back to a local frequency standard rather than to another transmitted one. You need to decide how good that standard needs to be based on your requirements (or maybe you just want to install cesium or rubidium so your marketing department can say you have atomic clocks).
The US FAA is transmitting WAAS correction signals. Depending on the algorithms in the GPS receiver, this may result a reduction in PPS jitter. (although any such jitter is probably swamped by the jitter at the IP layer)
http://216.239.51.104/search?q=cache:AZ97VsY3w10J:www.cmcelectronics.ca/products-services/custom-elect/Enhancing_GPS_Timing_Engines_using_WAAS_signals.pdf+waas+timing&hl=en&ie=UTF-8 suggests that WAAS can reduce your PPS jitter from about 50 ns to about 20 ns, which sounds plausible to me. This is beyond the level of accuracy that is needed or useful for NTP. Might I suggest that comp.protocols.time.ntp would have better advice on this than NANOG. Even 10 ms accuracy is usually enough for network operations. Beyond that we're talking about operating a service, not a network. -- Shields.
participants (2)
-
Michael Shields -
Robert M. Enger