NTP, possible solutions, and best implementation

Mailman List Mirror (Read Only)
1

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

2

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

3

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

4

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

5

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. :slight_smile:

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/&gt;\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-

6

"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. :slight_smile:

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. :slight_smile: 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/

                                        ---rob