Re: NTP, possible solutions, and best implementation

[Michael.Dillon () radianz com]

>   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