Network Time Protocol Not You REFID

NTP has been widely used through several revisions, with the latest being RFC 5905. A core component of the protocol and the algoritms is the Reference ID, or REFID, which is used to identify the source of time used for synchronization. Traditionally, when the source of time was another system, the REFID was the IPv4 address of that other system. If the source of time was using IPv6 for its connection, then a 4 octet digest value of the IPv6 address was used as the REFID. The purpose of the REFID is to prevent a one-degree timing loop, where if A has several timing sources that include B, if B decides to get its time from A, then A should not then decide to get its time from B. Recently it was observed in that a remote attacker can query a target system to learn its time source from the REFID included in target's response packet. The remote attacker can then use this information to send spoofed packets to the target or its time source, in an attempt to disrupt time service. The REFID thus unnecessarily leaks information about a target's time server to remote attackers. The best way to mitigate this vulnerability is to decouple the IP address of the time source from the REFID. To do this, a system can use an otherwise-impossible value for its REFID, called the "not-you" value, when it believes that a querying system is not its time source.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

The interpretation of a REFID is based on the stratum, as documented in RFC 5905, section 7.3, "Packet Header Variables". The core reason for the REFID in the NTP Protocol is to prevent a degree-one timing loop, where server B decides to follow A as its time source, and A then decides to follow B as its time source. At Stratum 2+, which will be the case if two servers A and B are exchanging timing information, then if server B follows A as its time source, A's address will be B's REFID. When A uses IPv4, the default REFID is A's IPv4 address. When A uses IPv6, the default REFID is a four-octet digest of A's IPv6 address. Now, if A queries B for its time, then A will learn that B is using A as its time source by observing A's address in the REFID field of the response packet sent by B. Thus, A will not select B as a potential time source, since this would cause a timing loop. However, this mechanism also allows a third-party C to learn that A is the time source that is being used by B. When A is using IPv4, C can learn this by querying B for its time, and observing that the REFID in B's response is the IPv4 address of A. Meanwhile, when A is using IPv6, then C can again query B for its time, and then can use an offline dictionary attack to determine the IPv6 address that corresponds to the digest value in the response sent by B. C could construct the necessary dictionary by compiling a list of publically accessible IPv6 servers. Remote attackers can use this technique to identify the time sources used by a target, and then send spoofed packets to the target or its time source in order to disrupt time service as was done e.g., in or .

This proposal allows the one-degree loop detection to work while keeping potentially abusable information from being disclosed to uninterested parties. It does this by returning the normal REFID to queries that come from an address that the current system believes is its time source (aka its "system peer"), and otherwise returning a special IP address that is interpreted to mean "not you". The "not you" IP address is 127.127.127.127 when the query is made from an IPv4 address, or when the query is made from an IPv6 address whose four-octect hash does not equal 127.127.127.127. The "not you" IP address is 127.127.127.128 when the query is made from an address whose four-octect hash equals to 127.127.127.127. Note that this mechanism is transparent to the party that sends timing queries. A querying system that uses IPv4 continues to check that its IPv4 address does not appear in the REFID before deciding whether to take time from the current system. A querying system that uses IPv6 continues to check that the four-octet hash of its IPv6 address does not appear in the REFID before deciding whether to take time from the current system. This proposal will hide the current system's system peer from querying systems that the current system believes are not the current system's system peer. Note well, however, that the current system will return the "not you" value to a query from its system peer if the system peer sends its query from an unexpected IP address.

Many systems running NTP are configured to return responses to timing queries by default. These responses contain a REFID field, which generally reveals the address of the system's time source. This behavior can be exploited by remote attackers who wish to first learn the address of a target's time source, and then attack the target and/or its time source. As such, this proposal is designed to harden NTP against these attacks by limiting the amount of information leaked in the REFID field.

The authors wish to acknowledge useful discussions with Aanchal Malhotra and Matthew Van Gundy.