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.
Are you using Autokey in production? If so, please contact Harlan - he's got some questions for you.
Leap Smear for NTPv4
(Lightly hacked by Harlan)
It is pretty obvious that we need a way to shoehorn the current offset between a monotonic clock (probably TAI) and the reported timestamp, right?
Adding an extension field, probably in 32 (short) or 64-bit (full) ntp timestamp format which gives this offset would be very good, but we only really need 24 bits or so: 4 bits for integer seconds and 20 bits for us level fractional data, right?
Using nothing but the current NTP packet format that gives us a few options:
- The RefID field, where we've already determined the need for a way to stuff an IPv6 hash into 24+ bits, reserving one or a few leading byte values for this use. We can reserve a similar range for current TAI (or just UTC to save integer bits) offset.
- Stealing low order bits from the reference timestamp: I.e. grabbing the bottom 24 bits here leaves 8 fractional bits which is enough to locate the reference time to the nearest 8 ms or so: I have never seen any ntp code which bothers about the fractional bits in the reference timestamp!
- Steal a few bits each from the Receive and Transmit timestamps: If we grab 12 bits here the remainder is sufficient to handle us precision.
My recommendation is a combination:
- Use a special RefID token (
SMRx, with the
x containing 6 base64 encoded bits).
- Tweak the Reference timestamp, grabbing 10 low order bits, leaving 250ns resolution.
- Take the bottom 8 bits from the Receive timestamp
- Take the bottom 8 bits from the Transmit timestamp.
The total is 32 bits, sufficient for a signed fixed-point value in 8:24 format, i.e. +/- 127 seconds with 60 ns resolution.
Yes, the encoding of the fields will cause some cpu overhead, but not very significant, and the resulting packets will be indistinguishable
from the current format, with no measurable effect on the control loops:
We are currently adding random noise in those same lower bits, now we'll just make the bits non-random during the time smearing takes place.
It should be obvious that we can do this with even fewer bits, but the bits I've identified above should all be freely available!
Notes and Questions
This mechanism works great for hosts providing S1 answers. What do we do about intermediate time servers at S2+?
- Per RefidFormat we could use a high-order 255 to mean an IPv6-encoded refid, and use a high-order 011110xxx to mean "Leap Smear", which would then give us 3+24 bits for the smear encoding, with no need to mess with other parts of the packet. -- HarlanStenn - 20 Jun 2015
Who gets smeared time?
Do we provide smeared time on all responses? Only to client time requests? Only to associations of greater stratum?
Should we make sure the
reported in the packet is such that it's clear that the timestamps are only good to the point where we're stealing bits?
The intent is that clients that don't know what we're doing will be getting smeared timestamps, and will therefore follow smeared time, correct?
This means that the "believable" time bits will contain smeared time, and the bits we're stealing can be used to determine the amount of smear, correct?
Should the amount of smear be added to the packet's root dispersion?
The amount of smear in the bits we're stealing will provide an 8:24 timestamp. Under what circumstances will the integer portion of the smear be non-zero?