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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > PGP(6.5.8) public key http://www.tau.ac.il/~ariel/pgp.html > |
- Re: NTP, possible solutions, and best implem... joe mcguckin
- RE: NTP, possible solutions, and best im... David Schwartz
- RE: NTP, possible solutions, and be... Owen DeLong
- Re: NTP, possible solutions, an... Marshall Eubanks
- Re: NTP, possible solutions, and best im... Scott McGrath
- Re: NTP, possible solutions, and be... David Lesher
- Re: NTP, possible solutions, and best implementa... David Raistrick
- Re: NTP, possible solutions, and best implementa... Randy Bush
- RE: NTP, possible solutions, and best implementation Vachon, Scott
- Re: NTP, possible solutions, and best implementation Robert M. Enger
- Re: NTP, possible solutions, and best implementation Michael Shields
- Re: NTP, possible solutions, and best implementation Michael . Dillon