Re: NTP, possible solutions, and best implementation

["Robert M. Enger" <enger () seka erols net>]

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