NTP Ephemeral Peer Associations

This article tries to shed some light on how ntpd handles ephemeral peer associations, how these can be controlled by the 'noepeer' keyword, and the versions of ntpd that support this keyword.

Please note the word peer is sometimes used ambiguously in some NTP-related context. It is often used in an unspecific way when basically referring to remote nodes, time sources or something.

On the other hand, the word peer is used in very specific way when talking about two nodes that are basically equivalent, and may exchange the time with each other, in contrast to nodes with client/server roles, where only the client gets the time from the server.

In the example output of the ntpq commands below, the GENERIC association refers to a GPS refclock with PPS output that is connected to the local machine.

By default, if two machines are to work as equivalent peers that exchange time with each other, their configuration files should explicitly specify each other as peer in ntp.conf, and a proper authentication should have been set up on both peers.

Since the remote peer is explicitly specified on the local computer, a static association is always created and displayed. In the output of ntpq -c as the conf column shows yes since the remote peer has been explicitly configured, and the auth column reads ok to indicate that the received packets were properly authenticated:

~ # ntpq -c as
ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 37428  971a   yes   yes  none  pps.peer    sys_peer  1
  2 37429  f414   yes   yes   ok  candidate   reachable  1

Also, in the output of ntpq -p a peer that has explicitly been specified is listed with a lower case s in column t:

~ # ntpq -p
     remote      refid      st t when poll reach   delay   offset  jitter
=========================================================================
oGENERIC(0)      .GPS.       0 l    1    8  377    0.000   -0.002   0.004
+192.168.101.16  .GPS.       1 s   34   32  377    0.434    0.003   0.011

If the configured remote peer is not reachable, the static remote association is displayed anyway, but of course the reach value sticks at 0 to indicate that the remote peer is not reachable.

Normally, the peers send authenticated symmetric active packets to each other.

Of course, the local machine can only create a static association for a remote machine that was explicitly specified as a peer.

However, also authenticated symmetric active packets received from a remote machine that was not explicitly specified as peer are also normally considered valid peering requests. The remote machine knows and uses a valid secret key, so by default, the local machine accepts such requests and creates a dynamic peer association for the remote machine.

Because the remote peer was not explicitly specified, this type of dynamic association is referred to as an ephemeral peer association.

In the the output of ntpq -c as an ephemeral peer appears only after some authenticated symmetric active packets from a remote machine have been received and accepted, and thus the dynamic association was created.

An ephemeral peer is marked by a no in the conf column to indicate that this peer was not explicitly configured. However, the auth column still reads ok to indicate that the received packets were properly authenticated:

~ # ntpq -c as
ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 49249  971a   yes   yes  none  pps.peer    sys_peer  1
  2 49250  7014    no   yes   ok     reject   reachable  1

Also, in the output of ntpq -p an ephemeral peer is marked by an upper case S in column t:

~ # ntpq -p
     remote      refid      st t when poll reach   delay   offset  jitter
=========================================================================
oGENERIC(0)      .GPS.       0 l    5    8  377    0.000   -0.004   0.007
 192.168.101.18  .GPS.       1 S    1   32  377    0.505   -0.043   0.004

Remote peers may affect the time on the local computer. Often this only acceptable from peers that have explicitly been specified, but not from random ephemeral peers.

If the local machine should not accept ephemeral peering requests, the noepeer restriction keyword should be specified in the configuration file. See noepeer on this web page:

• Access Control Commands and Options
  https://www.meinbergglobal.com/download/ntp/docs/html/accopt.html#restrict

Please note: The noepeer keyword was introduced in ntp-4.2.8p11, but only works as expected in ntp-4.2.8p12 and later.

If a remote machine sends symmetric active packets with a cryptographic signature that can't be verified by the local machine, the local machine does not accept the remote one as an ephemeral peer, and does not create a dynamic association for it.

It doesn't even matter if the noepeer restriction has been specified, or not.

If the local machine receives a symmetric active packet with no cryptographic signature appended at all, then ntpd simply sends a symmetric passive packet without signature as reply.

This behavior is a hack that has already been introduced in 2002, just to let ntpd be responsive to dumb w32time clients that were sending symmetric active requests all the time when in fact they should have been sending normal client requests.

For details, see:

• Configuring w32time As NTP Client

and, specifically, the references at the bottom of that page.

Beside the scenarios explained above, ntpd v4 supports some automatic server discovery schemes that also depend on using ephemeral associations.

If the local machine is configured as broadcast, multicast or manycast client, or if servers of the NTP pool are to be used as time sources, the IP address of a remote node is only available after the remote machine has been discovered, so it is not possible to create a static association in the configuration file.

In broadcast/multicast/manycast mode, clients need to be explicitly configured to listen for multicast/broadcast packets, and servers have to be explicitly configured to send such packets. Only if both ends support this, the client can get the time from the server and synchronize to it. The usual advice is to use authentication with servers detected via broadcast/multicast/manycast to avoid intentional time spoofing by evil NTP nodes on the network. In most cases, using authentication is not a problem because the broadcast/multicast/manycast servers are usually on a managed network, not on the public internet.

In case of the pool server(s) the local machine also has to be explicitly configured to use those servers. However, it's the DNS system that provides IP addresses of publicly available servers, so the local ntpd just has to do some DNS name resolution, and use the IP addresses returned by the DNS server. Once ntpd has determined the IP address of a server, it sends normal client mode UDP packets to the server, and receives normal server mode UDP packets back from the server, in the same way as with explicitly configured clients. There is no need for the NTP daemon to send or receive NTP broadcast or multicast packets.

“Pool servers” are usually on the internet, and it would be hard to use the kind of authentication that is currently supported by ntpd with such servers. However, the NTP pool infrastructure monitors the servers, and if a client uses several servers in parallel there is a certain level of protection against time spoofing.

In all of the cases above, the client needs some kind of specific configuration to accept remote servers and create ephemeral associations for the servers that have been discovered. See:

• Automatic Server Discovery Schemes
  https://www.meinbergglobal.com/download/ntp/docs/html/discover.html

Please note that unlike the ephemeral peers discussed above, the ephemeral associations created by these server discovery schemes create associations where the local machine acts as client of the discovered server(s).

It should be possible to prevent creation of these ephemeral associations using the nopeer restriction, see nopeer on this web page:

• Access Control Commands and Options
  https://www.meinbergglobal.com/download/ntp/docs/html/accopt.html#restrict

Specifically, the pool directive in ntp.conf does not work as expected it the default restrictions include the nopeer keyword.

— Martin Burnicki martin.burnicki@meinberg.de, last updated 2023-01-25