Time Synchronization Protocols

The synchronization protocol determines the time offset of a client clock relative to one or more server clocks. The various synchronization protocols in use today provide different means to do this, but they all follow the same general model. The client sends a request to the server, and the server responds with its current time. For the best accuracy, the client needs to measure the server-client propagation delay to determine the true time offset relative to the server. Since it is not possible to determine the one-way delays, unless the actual time offset is known, NTP measures the total round-trip delay and assumes that the propagation times are statistically equal in each direction. In general, this is a useful approximation; however, in the Internet of today, network paths and the associated delays can differ significantly, causing errors up to one-half the path delay difference.

The community served by the synchronization protocol can be large. For instance, there is an extensive network, referred to in this topic as the public NTP subnet, consisting of some hundreds of servers and millions of clients. NIST estimates 25 million clients of its dozen public servers (J. Levine, personal communication). In addition, there are numerous private NTP subnets that do not exchange time values with the public subnet for one reason or another. It is the usual practice to use multiple redundant servers and diverse network paths to protect against broken software, hardware, and network links, as well as misbehaving hackers, so there are many more synchronization paths than there are servers and clients.

The NTP protocol operates in multiple stratum levels where time values flow from servers at one stratum to clients at the next-higher stratum. Clients can also function as servers for the next-higher stratum in turn. Each NTP subnet graph is organized as a forest of trees with the primary (stratum 1) servers at the roots and dependent secondary servers at each increasing stratum from the roots. Primary servers are synchronized to UTC as disseminated via radio, satellite, or telephone modem service. Secondary (stratum 2) servers are synchronized to the primary servers and to other secondary servers at the same stratum. Individual corporations and institutions often operate private NTP servers behind firewalls and synchronized to public servers via holes bored in the firewalls. Private subnets may not require synchronization to national standards, in which case one or more servers are arbitrarily designated primary, and all other servers synchronize directly or indirectly to them.

Synchronization protocols work in one or more association modes, depending on the protocol association design. There are three kinds of associations: persistent, preemptable, and ephemeral. Persistent associations are mobilized as directed by the configuration file and are never demobilized. Preemptable associations are also mobilized by the configuration file but are demobilized if the server has not been heard for some time. Ephemeral associations are mobilized on receipt of a packet designed for that purpose, such as a broadcast mode packet, and are demobilized if the server has not been heard for some time.

Use of the term broadcast in this topic should be interpreted according to the Internet Protocol Version 4 (IPv4) and Version 6 (IPv6) address family conventions. In IPv4, broadcast is intended for multiple delivery on the same subnet, while multicast is intended for multiple delivery on the Internet at large. In IPv6, multicast is intended for multiple delivery on the Internet at large as selected by the IPv6 address prefix. Notwithstanding this distinction and for simplicity in this topic, the term broadcast applies equally to both address families and to both broadcast and multicast modes.

Client/server mode, also called master/slave mode, is supported in both DTSS and NTP. In this mode, a client synchronizes to a stateless server as in the conventional remote procedure call (RPC) model. NTP also supports symmetric modes, which allows either of two peer servers to synchronize to the other, to provide mutual backup. DTSS and NTP support broadcast mode, which allows many clients to synchronize to one or a few servers, reducing network traffic when large numbers of clients are involved.

Configuration management can be an engineering challenge in large subnets. Various schemes that index public databases and network directory services are used in DTSS and NTP to discover servers.Especially in networks with large client populations, clients can use broadcast mode to discover servers, but since listen-only clients cannot calibrate the propagation delay, accuracy can suffer. NTP clients can determine the delay at the time a server is first discovered by temporarily polling the server in client/server mode and then reverting to listen-only broadcast client mode. In addition, NTP clients can broadcast a special manycast message to solicit responses from nearby servers and continue in client/server mode with the respondents.

A reliable network time service requires provisions to prevent accidental or malicious attacks on the servers and clients in the network. NTP includes provisions for access control using a mask-and-match scheme and can shed messages that might arrive in a clogging attack. NTP clients can crypto-graphically authenticate individual servers using symmetric key or public key cryptography. Symmetric key cryptography authenticates servers using shared secret keys. In public key cryptography, industry standard X.509 certificates reliably bind the server identification credentials and associated public keys. The purpose-designed Autokey protocol, now navigating the standards process, authenticates servers using timestamped digital signatures. The protocol is specially crafted to reduce the risk of intrusion while maximizing the synchronization accuracy and to minimize the consumption of processor resources.

Next post:

Previous post: