r22 - 2015-05-23 - 19:44:09 - NathanStrattonTreadwayYou are here: NTP >  Dev Web > OtherDocumentation > RefidFormat > UpdatingTheRefidFormat
NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in distributed denial-of-service (DDoS) attacks. Please also take this opportunity to defeat denial-of-service attacks by implementing Ingress and Egress filtering through BCP38.

ntp-4.2.8p15 was released on 23 June 2020. It addresses 1 medium-severity security issue in ntpd, and provides 13 non-security bugfixes over 4.2.8p13.

Please see the NTP Security Notice for vulnerability and mitigation details.

Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.

Updating the REFID format

See RefidFormat, bug_small.png Bug #278, and bug_small.png Bug #505 for more information.

The current format for the Refid is either:

  • .ABCD. for a reference clock
  • Something that looks like an IPv4 address

There are a few problems with this:

  • The IPv4 format takes up a lot of room
  • We now support IPv6 and that address is lots longer
  • There is no real reason to use the refid for address information

It has been proposed that we change the non-refclock format to something "more compressed", like hex or base64.

I'm leaning toward Dan Mahoney's suggestion in comment #9 of bug_small.png Bug #278, which is an IPv4 format consisting of 255 followed by 3 bytes from the hash.

Some other issues that have been brought up by Danny, in regard to recent events:

  • Also needs to deal with the endian problem (not all platforms represent their bits and bytes in the same order).
  • The internal binary representation of the refid is 4 bytes, but 16 byte IPv6 addresses won't fit.
    • The spec calls for using the top 32 bits of the MD5 hash
      • If we do this, we might need to use the 4to6 representation of the IPv4 address, effectively converting that into an IPv6 address, which then gets treated the same way.
  • I would also like to voice my support for the use of base64 for the presentation of the refid to the user, since this is more compact
    • 4 bytes = 8 nibbles = 8 hex characters
    • 4 bytes = 32 bits = 5.33333 base64 characters
      • Either is more compact than our current IPv4 presentation, but IMO the more space we can save, the better.
  • I'm not sure what to do about representations for refclocks. ;(

-- BradKnowles - 12 Jul 2004

We may not be able to use 4to6 if the target is a platform where somebody said "--disable-ipv6" (or whatever).

It might be useful to ID the "source" for the refid:

is a refclock
is a Unicast client
is a Broadcast client
is a manycast/multicast client (is it OK to lump these?)

-- HarlanStenn - 13 Jul 2004

With regards to the 4to6 translation, I think we can do that regardless of whether or not the machine supports IPv6 or not. I think it boils down to just tacking on a certain string to the front of the IPv4 address, which might even be all zeros. We might need our own routine to calculate that, so that we're not dependant on the routines in the IP stack, but I think that should be do-able.

Otherwise, I think Harlan has some excellent suggestions here for the characters which might be displayed in front and/or behind the refid, to help identify refclocks and client types.

-- BradKnowles - 13 Jul 2004

Based on some discussions that we've had on both hackers as well as chat it looks like the best initial cut would be to create a different option at least for now, that I have tentatively called xpeers (-x on the command line) which will put the address where the refid currently is when it's not one of the standard items like .GPS. MCAST, or other clocks.

Because of the limited space on a line that would allow for the longer IPv6 addresses this means making the line longer than 80 characters (hence the -x). However, at least a full IPv6 address will appear. The refid field will not show up in this display. This will be experimental for now (hence the -x).

A second issue has been raised here that the refid is not enough for loop prevention since you could be contact the same host over different IP addresses. It is not clear how we will solve that issue.

-- DannyMayer - 16 Jul 2004

Speaking only for myself, I think we need a refid that is guaranteed unique for a given executing ntpd image, regardless of which interface you're coming in over or what hostnames that machine may be known by.

You could potentially have multiple copies of ntpd running on a single machine, each listening to different interfaces. I think each of these processes should have a unique refid to distinguish it from the others.

How we achieve these things, is a question I do not know. But I think that this is the only way we're going to be able to solve the loop prevention issue.

-- BradKnowles - 19 Jul 2004

You cannot have more than one ntpd server running on any system as this would cause the clock to be changed by multiple processes and cause clock instability. You cannot run ntpd and some other server that might change the clock.

-- DannyMayer - 21 Jul 2004

(Should we be discussing this in a ...Dev topic instead?)

The REFID is used by stratum 1 servers to identify their source of time, and at lower strata to prevent loops.

In the "old days" the lower strata servers used their IP address. This is no longer sufficient or appropriate, as:

  • machines often have multiple addresses
  • the increasing use of IPv6 means we don't have a convenient 4-byte number; the draft SNTP spec says the top 4 bytes of the MD5 hash of the IPv6 address should be used.

-- HarlanStenn - 01 Nov 2004

This has just come up again in a question from Microsoft. We need to revisit this again, particularly in light of the discussions on auditability. If we don't have a unique refid per system (as opposed to interface) we can't ensure that we are preventing looping. This should be discussed in the IETF WG now that we have one.

-- DannyMayer - 16 Jun 2005

For the base64 representation we could use A-Za-z0-9+/ (and I'm not attached to + and /). The current representation takes up 15 characters, and with base64 we should be able to get that down to 6 characters (if I did the math correctly), 7 if we prepend a character to tell us how we are talking to that system (which would save us another character as we would not be needing the t column anymore.

I'm pretty sure we use network byte order to move these things around.

-- HarlanStenn - 17 Jun 2005 --- To summarize (based on recent email and conversation with Dave), there are 2 issues with reference ids: their purpose and their interpretation.

A primary purpose of the refid is loop-detection/avoidance. Given two machines, A and B, the refid is used so that if A tries to get time from B it can tell if B is already sync'd to A.

As for the interpretation of the refid, there are 3 cases, all based on the stratum.

  • S0: the refid contains a KOD code
  • S1: the refid contains the refclock type
  • S2+: the refid contains a "token" that IDs the server we are syncing with

In the past, the S2+ refid was the IPv4 address of the server. This is sometimes useful, as it makes it easy to see who a remote server is talking to.

It is arguably Bad to display the md5 hash remnant of an IPv6 address as a network address.

The problem as I see it is that the receiving side does not know if the S2+ refid is IPv4 or not, and without this knowledge cannot properly decode the refid.

Additionally, a refclock can now advertise itself at S2+.

-- HarlanStenn - 17 Jun 2005

This issue is really bigger than the mere format of the Ref-ID because IPv4 has led to a situation where people use the refid column in the ntpq peer billboard as a "next stratum up" display. Although some of you make take the position that "the Ref-ID was never intended to be used that way so tough luck", the fact is we should not capriciously break existing functionality as it has evolved.

As for the Ref-ID itsself:

  • A Ref-ID which is a hash / number / token / whatever which is opaque to the user will lead to complaints because it will make quick diagnosis more difficult. An additional ntpq command which displays the talley code, remote host, hostname of that remote hosts sys_peer, and a few more columns (such as stratum, when, poll, reach), would do much to offset the use of an opaque Ref-ID.

  • Each ntpd should have a GUID (*G*lobally *U*nique *ID*entifier), so that it is uniquely identifyable regardless of how many IP-addresses it is bound to, that serves as its Ref-ID. These GUIDs should be cryptographically strong enough to reasonably reduce the chance of GUID collision.

-- SteveKostecke -- 12 May 2008

Looking at the IANA IPv4 Special-Purpose Address Registry, it seems like all of (0xF0.0.0.0) is reserved "for future use". So if there is a move to give special meaning to the bytes of the existing four-byte Refid field (and we're not worried about that range someday getting used for some incompatible purpose), it might be possible to keep 28 bits of the md5 hash (if the extra seemed useful to avoid clashes), or to use the second nibble of the first byte to announce some other information (e.g. S2+ refclocks). (Note that that page doesn't list as reserved separately from the reservation; only has a separate mention.)

(For completeness, two other network ranges listed on that page that could conceivably be used for special-case Refid values are and . There are a handful of other ranges that look like they would never be used as the IP number of an actual server, but those ranges are small enough that it doesn't seem like they'd be useful for the special cases we're talking about here.)

Certainly it would also be nice to figure out some (backward-compatible) way to send a longer Refid (or a new field with the upstream information, separate from the Refid) to avoid these problems in future versions of NTP.

-- NathanStrattonTreadway - 2015-05-22

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r26 | r24 < r23 < r22 < r21 | More topic actions...
Dev.UpdatingTheRefidFormat moved from Support.RefidFormatDev on 2004-10-29 - 14:31 by SteveKostecke - put it back
SSL security by CAcert
Get the CAcert Root Certificate
This site is powered by the TWiki collaboration platform
IPv6 Ready
Copyright & 1999-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. Ideas, requests, problems regarding the site? Send feedback