Cost effective time servers

Forrest Christian (List Account) lists at packetflux.com
Tue Jun 25 04:08:01 UTC 2019


It's about minimizing the impact of the attack vector.     And you
shouldn't implicitly trust the second alignment either.

In a potential spoofing attack, if you trust the GPS for all of the
data exclusively, then someone who can spoof your GPS (not as
hard/expensive as one would think) can fully control what time you
think it is.    This is obviously bad.

If instead you take the time data from another source, and only take
the second from the GPS, at most you're going to be off a second.
This is less bad but still bad in some cases.

Fortunately, we can easily do better than this.

NTP itself provides the solution.

Ideally you'd get your time from multiple sources and use some sort of
algorithm to determine what the most likely correct time is.   NTP has
this functionality built in.   If you take a stratum 2 or 3 server,
and add multiple, geographically diverse stratum 1 and 2 servers to
it, the stratum 2 or 3 server will look at all of the views of time
including second alignment that it is receiving, and will determine
which servers can be trusted and which can't.   If a stratum 1 server
is being spoofed, the stratum 2 or 3 server will notice that it is out
of alignment and ignore it.   In this way, you don't trust what is
coming down the GPS of one or two stratum 1 servers.

For most people just running a stratum 2 or 3 server with a
well-curated set of stratum 1 or 2 servers scattered around the
internet will be accurate enough, and will provide robust, not easily
spoofed time.   The limitation here is that this is limited by RTT/2
in the worst case, so if you're a long ways away from your closest
stratum 1 server, your clock may be offset by up to RTT/2 plus
whatever systemic errors are inherent in the stratum 1 server (cable
delays, etc).   If you need better alignment, a local stratum 1 server
can be used, but it should just be added to your local stratum 2 or 3
server to improve the alignment of the second.   Once this is added,
the stratum 2 or 3 server will typically notice that it's really close
and will start to follow it's second alignment, but only if it is
within the window that it has determined is likely to be valid by the
'voting' of all of the other stratum 1 and 2 servers which are
scattered around.

One other note:  There are some stratum 1 servers out there which do
not generally rely on GPS for time transfer from their stratum 1
clocks.   For instance, the NIST and USNO ntp servers, along with
others around the world in various standards organizations.  It might
pay to include some of these in your mix as well.

On Mon, Jun 24, 2019 at 8:36 PM Chris Adams <cma at cmadams.net> wrote:
>
> Once upon a time, Forrest Christian (List Account) <lists at packetflux.com> said:
> > I would submit that the proper use of a GPS receiver is for alignment
> > of the start of the second to a more precise value than can be
> > distributed across an asymmetric network like the Internet.  The
> > actual 'time label' for that second doesn't necessarily need to come
> > from GPS at all.  For security reasons, it's probably a good thing to
> > make sure you validate the data received from GPS in any case.
>
> If you don't trust the GPS receiver's idea of the time, why do you trust
> its start of the second?  It seems really odd to trust one and not the
> other.
> --
> Chris Adams <cma at cmadams.net>



-- 
- Forrest



More information about the NANOG mailing list