NTP, possible solutions, and best implementation
Michael.Dillon at radianz.com
Michael.Dillon at radianz.com
Thu Oct 2 15:51:57 UTC 2003
> Assuming one wanted to provide a high profile (say, at the TLD level)
NTP
>service, how would you go about it ?
First of all, NTP should be done at the geographical level, not the TLD
level. Generally, unless political reasons prevent it, you should try to
implement an NTP service that covers a region roughly as large as Europe
to avoid too much fate sharing caused by proximity.
> 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),
Beware the single point of failure. If all your clocks come from GPS, then
GPS is the SPOF. If they all come fram brand X manufacturer then that is
the SPOF. A commercial service should be robust and use a combination of
atomic clocks, GPS, radio time services, CDMA/GSM clocks combined with a
sanity checker to watch all the clocks and detect bad timekeepers.
> 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,
Indeed.
Hide this clock behind a packet filtering firewall or else use udprelay
and an application layer gateway on UNIX to block everything except NTP.
In fact, if this is a commercial service you should hack udprelay so that
it knows about the NTP protocol and can block non-customer traffic or
malformed traffic or high volumes of traffic. That way, the UNIX
server/firewall in between the NTP device and the net protects it from
abuse, but since this UNIX server is a pass-through device from the point
of view of NTP, it does not change the stratum level of the service any
more than an IP router does.
--Michael Dillon
More information about the NANOG
mailing list