[Ntp] Re: [EXT] Re: various "errors" in NTPv5 specified

["Windl, Ulrich" <[e-mail]>]

I'll try to comment inline, as good as Outlook allows.

> -----Original Message-----
> From: Miroslav Lichvar <[e-mail]>
> Sent: Wednesday, March 25, 2026 3:56 PM
> To: Windl, Ulrich <[e-mail]>
> Cc: [e-mail]
> Subject: [EXT] Re: [Ntp] various "errors" in NTPv5 specified
> 
> Sicherheits-Hinweis: Diese E-Mail wurde von einer Person außerhalb des UKR
> gesendet. Seien Sie vorsichtig vor gefälschten Absendern, wenn Sie auf Links
> klicken, Anhänge öffnen oder weitere Aktionen ausführen, bevor Sie die
> Echtheit überprüft haben.
> 
> (Responding to all three recent mails)
> 
> On Wed, Mar 04, 2026 at 09:29:37AM +0000, Windl, Ulrich wrote:
> > Reading the NTPv5 draft #8, sec. 4.2, I see there are multiple “errors”
> specified, but I think the actual definitions are somewhat vague (IMHO):
> > “potential error”
> > “maximum error”
> > “maximum potential error”
> > “estimate of the maximum possible error”
> >
> > If any of those four are actually the same, a more precise wording should be
> used IMHO.
> 
> They are different due to different causes of the error (asymmetry vs
> clock/measurement stability) and estimates vs actual error (which is
> unknown to NTP).
> 
> On Wed, Mar 04, 2026 at 02:03:32PM +0000, Windl, Ulrich wrote:
> >   1.  Basically only the two data types time32 and timestamp64 are formally
> specified in the draft, while other data types are being used also. Therefore I
> wondered whether *all* low-level types should be specified formally (unless
> there is an RFC covering that already). With “low level” I mean the numeric
> interpretation, not units and semantics. What I had in mind would be
> something like “u32f28” for “time32”, saying it’s an unsigned 32 bit number
> with 28 bits fixed fractionals. Then for “time32” it would be sufficient to state
> that it’s a u32f28 describing seconds. Likewise u64f32 could be used to
> describe “timestamp64”, saying that is describes an offset in seconds from the
> epoch (era).
> >      *   For the logarithmic types one could use “s8l” (“S8L”) to describe a
> signed 8-bit logarithmic value, so “precision” would be a s8l describing
> seconds, and “poll” would be a “u8l” describing seconds
> >      *   “timescale” and “era” would be u8
> >      *   “flags” would be u16
> >      *   “server cookie” and “client cookie” would be u64
> >      *   “type” and “length” for the extension fields would be u16, …
> 
> To me that looks like an unnecessary complication. I prefer a text
> description for the simple integer types, but maybe others have a
> different opinion?

[Windl, Ulrich] 
What is difficult with some RFCs is that information is "spread all over the document", si I think specifying the data types early and precisely will help to understand and implement things correctly. Actually for previous versions I had to use the source of the reference implementation to find out some details. I think the RFC should be self-contained.

> 
> >   2.  When describing the packet formats, the description includes not only
> the types, but also processing logic (that goes beyond syntax). I think (when
> the draft does not want to specify algorithms) that the “logic” behind the
> packet fields shoul.d be handled in a separate section, like “assembling
> packets” and “parsing packets”.
> 
> Anyone else thinks that? I'd prefer to keep things together so it's
> shorter and easier to follow (fewer jumps for the reader).
[Windl, Ulrich] 
My proposal goes along with "Specifying types first", A pacjket is also a "type" (only).
OTOH a type specification is complete with all the possible operations on it being explained.
I think separating "type syntax" (the layout of the fields) and "type semantics" may be beneficial, especially when the RFC claims not to specify algorithms.
Even when not specifying an algorithm (like for virtual base classes), basic semantics must be specified (e.g. what Eiffel names "precondition", "potscondition" and "class invariant").
So while an algorithm is not being specified, the semantics should be, just to enable interoperability at all.

> 
> >   3.  Maybe “protocol” (UDP) and ports (123) should be a subsection also
> 
> A section that says NTP uses UDP port 123?
[Windl, Ulrich]
Yes, we all know that NTP works on port 123/UDP, but the RFC should point it out clearly, or refer to the names IANA registration.

> 
> >   4.  For 0xf5ff: If the client string is shorter then the server string, the server
> cannot respond (as per rules). It’s unclear how the string should look like
> exactly, and whether it would be allowable for the server to use client’s field
> padding to return a longer field content (which would make sense IMHO)
> 
> My understanding is that the server is not allowed to respond with a
> longer string, even if the response wouldn't be longer (e.g. missing
> some EF or shorter padding). As this is only for draft
> implementations, now following the WG-adopted document, I don't think
> it really matters much.
> 
> >   5.  “7.3” “(…)The extension field MUST be the last(…)”: I think it should read
> “This extension field (…)”
> 
> Ok, it's fixed in the git repository.
> 
> >   6.  “7.3”: Th text should also point out that the cryptographic algorithm is
> implicitly encoded with the Key ID, too (it’s pre-shared together with the
> actual key).
> 
> Good point, done.
> 
> > Also: Isn’t Key ID zero being reserved meaning “no MAC”?
> 
> In NTPv4 that is a crypto NAK. In the NTPv5 draft we have a flag for
> that, and unlike in NTPv4 it cannot be interpreted as the header of an
> extension field (the MAC is in its own extension field), so a Key ID
> of 0 could be used for MACs in NTPv5, as it was possible in NTPv3.
> 
> Should 0 not be allowed to avoid having keys that cannot be used in
> NTPv4?
> 
> >   7.  “7.4” “Recommended to increase the random delay(…)”: Shouldn’t it
> read “(…)random intervals”?
> 
> I don't see a difference in that, but ok, it's now changed.
[Windl, Ulrich] 
IMHO a "delay" is a one-time thing, but an "interval" is repeating, but I may be wrong.

> 
> >   8.  “7,6”: The format of the “origin correction” is not specified when
> describing the field (see my proposal for types earlier). Likewise for “origin path
> DI”.
> 
> They are described as copies of the Delay Correction and Path ID
> fields, so they have to have the same format.
> 
> > “Delay correction” would be “s64f16”, and some description with an
> example would be really helpful IMHO for those that do not know PTP.
> 
> It's already described as "A signed fixed-point number of nanoseconds
> with 48 integer bits and 16 binary fractional bits", i.e. your s64f16.
> We don't provide examples for the other types, so that would feel
> inconsistent to me.
> 
> > Again, the description of logic should be a separate sub-section IMHO.
> Possible I would add “after the MAC” in “It MUST be the last extension field in
> the NTP message.” That would be strictly redundant, but it would add to
> clarity IMHO.
> 
> The relation with MAC and other authenticator fields is explained in
> a separate paragraph later in that section.
[Windl, Ulrich] I think in general it's advisable to expain everything ONVCE and in ONE location. Spreading a specification for one item over the whole document just makes it easy to miss some detail. MHO.

> 
> > When describing the logic, “validate the correctness” should be specified
> IMHO.
> 
> In that sentence there is a reference to the Measurement Modes
> section, which specifies that.
> 
> >   9.  “7.8” I think an implementation note would be helpful here (How a
> server could implement that).
> 
> There is an item in my todo list to better describe how is this thing
> supposed to work.
> 
> > Also I think “(…)a random number which is changed(…) should be replaced
> with “(…)a random number which MUST change(…)”
> 
> Ok, fixed.
> 
> >   10. “7.9” I think it’s important to specify that all values returned MUST
> correspond to the Receive Timestamp in the header. It seems obvious, but
> isn’t specified.
> 
> Isn't that already covered by "The Timescale, Era, and Secondary
> Receive Timestamp fields in a response have the same meaning as the
> Timescale, Era, and Receive Timestamp fields in the header
> respectively."?
> 
> > Also: “(…)each timescale MUST be requested(…)”: Shouldn’t that be
> “(…)each timescale MAY be requested(…)”? Similarly: Why doesn’t a server
> MUST include the requested timescale in the response when it supports it
> (and it’s being requested)? Doesn’t the specification make the query
> practically useless?
> 
> Ok, the paragraph is now changed to:
> 
>   A request MAY contain multiple instances of this extension field,
>   but they all MUST request different timescales. The server MUST
>   include in its response timestamps in all requested timescales it
>   supports.
> 
[Windl, Ulrich] 
Much better!

> 
> On Thu, Mar 05, 2026 at 11:10:29AM +0000, Windl, Ulrich wrote:
> >   1.  On figures 12 and 13 the meaning of “SC, CC, Rx, and Tx is not explained
> (one has to guess), and the description does not actually refer to those
> abbreviations.
> 
> Fixed.
> 
> >   2.  Defining offset_c and delay_c it’s not clear that those should replace
> offset and delay, respectively.
> 
> The paragraph now says:
> 
>   The client SHOULD use the corrected values for synchronization of
>   its clock in order to improve the accuracy and stability. The
>   corrected values MUST NOT be accepted if any of delay_c, Co and Cr
>   is negative to limit the error in case the corrections are provided
>   by faulty devices or on-path attackers. The root delay MUST always
>   be calculated from the uncorrected delay to avoid making the
>   estimated maximum error (root distance) dependent on accurate
>   network corrections.
> 
> > Also an additional validity check in presented later in security considerations
> only, while refering to section 8 for actual checks,
> 
> Which additional check in security considerations? There is just a
> note that the correction is not applied if it's larger than the
> measured delay, which follows from the MUSTs in section 8 (delay_c,
> Co and Cr all being non-negative).
[Windl, Ulrich] 
I think it was about “7.8”.

> 
> >   3.  I think the actual advantage of interleaved mode should be pointed out
> more clearly (which issue does it fix?).
> 
> The section now includes:
> 
>  The interleaved mode enables the server to provide the client with a
>  more accurate transmit timestamp that is available only after the
>  response was formed or sent (e.g. a hardware timestamp captured at
>  the data link layer or physical layer), which improves the accuracy
>  and stability of the synchronization.
> 
> >   4.  In section 9 “association” should be defined more clearly before using
> the phrase IMHO. Likewise “filter”, “compare”, “select” “combin” and
> “minimize offset” could be explained a bit more in depth, even when no
> algorithms are being presented.
> 
> I'm open to more specific suggestions.
> 
> >   5.  The concept of the server suggesting a polling interval to the client seems
> somewhat odd to me; the client could as well suggest the pooling interval it
> intends t use to the server, and the server could accept or deny it (by not
> responding)
> 
> How would the client know it's the poll value that the server doesn't
> like when it gets no response? That would be the same as rate limiting,
> the last resort that the server has.
> 
> >   6.  An explanation of the magic numbers for polling interval (2^6) and
> “iburst” (8 requests spaced two seconds) should be presented (IMHO), or
> make it more generic like “short polling intervals should not be used, except for
> a limited amount of initial measurements”
> 
> Considering the abuse we see on public servers, I think we should have
> some concrete numbers there. Poll of 2^6s and up-to-8-packet burst
> corresponds to the widely used default configuration on many systems.
> Any suggestions how can this be explained in the text?
[Windl, Ulrich] 
My point was WHY exactly nose numbers were selected; e.g. why not 3 seconds spacing, why not 1 second spacing?

> 
> >   7.  Randomization of the polling interval: Why is the length of the interval
> randomized and not the start of the interval?
> 
> To not delay the first update of the clock. If the clients had to wait
> for a random interval up to the maxpoll (usually 1024 seconds) or even
> minpoll, I think users would wouldn't like that much. It's done like
> that in PTP, but that uses much shorter intervals than NTP over
> Internet.
[Windl, Ulrich] 
OK, so maybe explain WHICH problem to fix, and WHY this specific fix was specified or preferred (especially when you don't want to specify algorithms 😉)

> 
> > Also: Is the randomization applied for the next interval always or just when
> the interval length changes? And why is it “up to 2%”; why not 5% or 10%
> 
> It should change with every poll. It's now clarified in the text. The
> "e.g. 2%" is just an example matching one of the existing
> implementations.
[Windl, Ulrich] 
So indicate that the value is just a suggested one (and not a "specified" one)

> 
> >   8.  “accept at most one valid response”: Meaning “drop duplicates” or drop
> all packets using the same CC before an new request is being sent?
> 
> Multiple valid responses would have to have the same duplicated CC,
> but other values could be different. The text now has "accept only the
> first valid response if more than one were received (e.g. the
> request or response was duplicated in the network)".
> 
> >   9.  For clarity item #5 in “client operation” might use sub-items defining the
> conditions for a “usable response”, or define it separately
> 
> Ok. It's now a list and the same was done for the response validation
> to make it more consistent.
> 
> >   10. Refreshing hostname resolution: It should be explained why pool DNS
> entries’ TTL is that short, why two weeks is being suggested. In general I thing
> ignoring the DNS TTL is against the intention of the DNS provider, so it should
> be well-explained if demanding such.
> 
> Two weeks is just an example. It says a short TTL is needed for
> "better load balancing". At least, that's the current practice with
> pool.ntp.org.
> 
> >   11. “server operation”: (LI) I think there should be a comma in from of
> “respectively”
> 
> Ok, fixed.
> 
> >   12. I think there should be an explanation why “root delay” must be the
> double of the maximum error
> 
> The text now has: "The doubling corresponds to the maximum asymmetry
> in a round-trip delay causing an offset error of half of the delay.".
> 
> >   13. “(…)clock from other causes than(…)”: “(…)clock from causes other
> than(…)”?
> 
> Ok.
> 
> >   14. “root dispersion”: What does “include” mean mathematically?
> 
> Addition. What else it could be?
[Windl, Ulrich] 
Adding it with a factor could also mean "included" 😉

> 
> >   15. Items #5 and #6: If #5 demands that response length must match
> request length, why does #6 demand to drop the response otherwise?
> 
> #5 is mostly about padding the response to have the same length as the
> request. #6 is supposed to catch bugs in formatting of the response.
> I've already seen some of those. The text should be now more clear.
> 
> >   16. Section 12: “(…)and be ignored by the client”: Shouldn’t it be more
> clearly “(…)and be ignored by such older client”?
> 
> The client is NTPv5, the server is buggy NTPv4. It should be more
> clear now in git.
> 
> >   17. “(…)Instead, the negotiation reuses the reference timestamp field.”:
> Shouldn’t the sentence end with a colon as it’s being explained subsequently?
> 
> Ok.
> 
> >   18. On the negotiation: If a NTPv4 response is received with an unchanged
> reference timestamp, should a crosscheck be done using a version 5 query to
> check that the reference timestamp is actually changed then?
> 
> That seems like an unnecessary complication to me. But you raise a
> good point that the server might be blindly copying the client's
> reference timestamp. Maybe the response should have a different magic
> value specified?
> 
> > In general the specification seems to forbid any extensions to the protocol,
> like additional modes (say one really wants to implement broadcast mode) or
> some in-band monitoring or configuration. Isn’t that overly strict? (Some time
> ago I wrote a syslog daemon that allows authenticated in-band configuration
> queries and configuration changes).
> 
> The idea is to make it clear that NTPv5 will not cause traffic
> amplification and it's safe to allow it in the network.
> 
> The current text of the document can be seen here:
> https://raw.githubusercontent.com/ietf-wg-ntp/draft-ietf-ntp-
> ntpv5/refs/heads/main/ntp-ntpv5.xml
> 
> Thanks,
> 
> --
> Miroslav Lichvar