Subject: [Ntp] Antw: [EXT] A different NTPv5 design

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 30 Apr 2020 08:54:24 +0200

>>> Miroslav Lichvar <[email-masked]> schrieb am 29.04.2020 um 16:45 in
Nachricht
<7114_1588171569_5EA99331_7114_20_1_20200429144540.GD8457@localhost>:
> I thought I should propose a more conservative design for NTPv5 than
> what Daniel posted few weeks ago. It's an evolution of NTPv4,
> following the "If it ain't broke, don't fix it" rule. It uses some
> ideas from the Daniel's proposal and I think it addresses the same set
> of NTPv4 issues from the wiki page, but it still looks like the NTP
> everyone knows. Authentication is still optional.
> 
> A minimal support can be easily implemented in existing NTP servers
> and other software/hardware that needs to work with NTP packets.
> Responding to NTPv5 requests with NTPv4 packets works as with the
> previous versions.
> 
> The design is described here as changes to NTPv4. If people think they
> would support something like this, I can write it as a full draft. The
> draft would just specify the protocol. The algorithms would be expected
> to have a separate draft if there is a need to have (some of) them
> specified.
> 
> Changes in packet structure
> ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑
> 
> ‑ Packets cannot have a MAC field appended (it's replaced by an extension
>   field)

That would break any non-autokey auth, right?

> 
> ‑ Extension fields can be of any length, even indivisible by 4, but are
>   padded to 4 octets (NTPv4 extension fields are compatible with NTPv5)
> 
> ‑ Servers ignore unknown extension fields and pad responses to the
>   length of the request using a padding extension field (i.e. clients
>   can rely on getting a useful response even when requesting an
>   unsupported extension field)

What is the purpose of that proposal for responses?

> 
> Removed fields in header
> ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑
> 
> ‑ Reference ID is removed (replaced by an extension field)

What does "removed" mean? "Kept empty"?

> 
> ‑ Reference timestamp is removed (unused in NTPv4)

The RCS says: "Reference Timestamp: Time when the system clock was last set or
corrected, in NTP timestamp format."

It may seem useless for the protocol to operate, but it may be an important
indicator to detect a free-running clock or similar correctness assumptions.
Here's an example from one server (that seems to be OK):
reftime=e254e9ea.815f5e84  Thu, Apr 30 2020  8:08:42.505,
clock=e254ee07.58246fae  Thu, Apr 30 2020  8:26:15.344

> 
> Modified fields in header
> ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑
> 
> ‑ Mode can have only a value of 3 (client) and 4 (server)
>   ‑ broadcast mode is less accurate and difficult to secure (leave this
>     mode to PTP)
>   ‑ symmetric mode has security issues, is rarely useful and can be
>     replaced with an (authorized) extension field requesting reversed
>     synchronization using the client‑server mode
>   ‑ monitoring and management protocols should use a different port

I see this very problematic: Symmetric keys are the only variant that works up
to today,
I think before obsoleting symmetric keys a _working_ version wioth extension
fields has the be established.
Maybe NTPv6 can drop the implementation after NTPv5 has a proper replacement.
I also think the current extension fields are quite a mess (a the
specification of those). I would suggest to completely re-think/re-design
those.

> 
> ‑ Leap indicator is set up to 14 days before the leap second
>   ‑ enough time for distribution, but no risk of leap seconds
>     getting stuck between subsequent months

I think the role of LI should be changed to refer to the current packet only.
Instead add a new "leap announcement" that will include type _and_ timestamp
when the leap event will happen. That way you could detect serevrs with
outdated leap second information even before a leap second event happens.
And while we do it, why not demanding a TAI extension field? Maybe even the
spec should claim that TAI should be the preferred timestamp?

> 
> ‑ Poll value in a response is the minimum polling interval to be used
>   by the client

Call it "suggested" (SHOULD) polling interval, allowing the server to "punish"
(MAY) clients that ignore the hint.
"Punish" could be something like ignoring all packets that violate the
restriction, ignoring any packet from that client, or send some KISS-like
warning to the client to adhere to the protocol...

> 
> ‑ Root delay and dispersion are shifted to left by 12 bits
>   ‑ resolution of ~4ns and maximum value of 16 seconds

For v5 I'd suggest extension fields with the new definition instead. Like I
said before: I think there should be a "one version transition phase" before
making drastic changes.

> 
> ‑ Client requests follow the data minimization draft (with some
>   modifications for the new fields)
> 
> New fields in header
> ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑

Before replacing any header field, I'd suggest to add extensions fields
instead, at least for one version to allow transition.

> 
> ‑ Flags (5 bits)
>   ‑ Multi‑message response
>     ‑ client indicates it's willing to deal with follow‑up messages
>       (valid cookie is required)
>     ‑ server indicates that a follow‑up message may follow this message
>       (i.e. the client should wait for more messages before processing
>       the response)
>   ‑ Follow‑up message
>     ‑ server indicates this is a follow‑up message, which has a more
>       accurate transmit timestamp. Multiple follow‑up messages are
>       allowed. All messages in the response are in the server mode and
>       have the same length.
>     ‑ if the client gets a response with the multi‑message or
>       follow‑up bit set, it waits for a message with the multi‑message
>       bit unset (e.g. for up to 10 milliseconds). It uses the latest
>       transmit timestamp from the messages it received. As the receive
>       timestamp of the response it can use the receive timestamp of the
>       message which didn't have the follow‑up bit set, or the timestamp
>       of the first message it received (which had the shortest delay).
>   ‑ (Interleaved mode, which has the opposite memory/bandwidth tradeoff
>      to the multi‑message response, could be requested with a separate
>      flag, or it could use the origin timestamp as before)
> 
> ‑ Timescale (3 bits)
>   ‑ client selects the timescale (UTC, TAI, UT1, leap‑smeared UTC,...)
>     for timestamps in the response
>   ‑ server responds in the requested timescale, or a different timescale
>     if the requested one is not supported

Aren't thos just "more flags"?

> 
> ‑ Era (8 bits)
>   ‑ server provides the NTP era of the receive timestamp, which
>     extends the unambiguous interval from ~136 years to ~35000 years
>   ‑ (clients can still have a hardcoded pivot date and ignore the
>     era number to simplify the operations with the timestamps)
> 
> ‑ Timescale‑specific field (16 bits)
>   ‑ with the UTC and TAI timescales server provides the TAI‑UTC
>     offset of the receive timestamp as a signed integer
>     (0x8000 if unknown)
>   ‑ with a leap‑smeared timescale it can be an identifier of the
>     smearing function to enable a reconstruction of UTC/TAI
> 
> ‑ Cookie (64 bits)
>   ‑ server provides clients with a cookie tied to their address
>   ‑ client returns the latest cookie it received to enable a
>     multi‑message response
>   ‑ server key is rotated frequently (unlike in NTS) to shorten the
>     interval when a leaked cookie can be exploited for amplification
>     attacks
> 
> Extension fields
> ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑
> 
> ‑ Padding
>   ‑ used for padding requests and responses
> 
> ‑ MAC
>   ‑ replacement for NTPv3/NTPv4 MACs
> 
> ‑ Reference IDs
>   ‑ requested by clients that operate as servers to get a set of
>     reference IDs in order to avoid a synchronization loop
>   ‑ uses a bloom filter similarly to the Daniel's proposal

Would we want to state that the reference ID is a UUID-like byte sequence?
Also: Fixed per server host, set when server process starts, or changed from
time to time?

> 
> ‑ Correction field
>   ‑ modified by routers/switches to compensate for their processing and
>     queuing delays
>   ‑ same or similar to the correction field proposed for NTPv4
> 
> ‑ Monotonic timestamp
>   ‑ an extra receive timestamp (with a step counter) from a clock
>     which has an unsynchronized phase and can be used for a frequency
>     transfer in the selected timescale
>   ‑ similar to the recv field in the Daniel's proposal
>   ‑ not expected to be supported by all servers and clients

Wenn, I think there should be a "NTPv5 core protocol" and several "NTPv5
extensions". The last item above seems very much like an extension to me.
Extensions should be queried before being used; if absent, they can't be
used.

What I miss (I said before): To avoid another  change in the traditional NTP
packet format, require an extension field that describes the NTP version (any
maybe implementation as well), claiming that future versions of the NTP
protocol may only change the corresponding extension field. When having that in
NTPv6 , there is a transition phase and still one version left before VN wraps
to zero.

> 
> NTPv5 packet format
> ‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑
> 
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+
>       |LI | VN  |Mode |    Stratum    |     Poll      |  Precision    |
>       +‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+
>       |                         Root Delay                            |
>       +‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+
>       |                         Root Dispersion                       |
>       +‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+
>       |  Flags  |Scale|     Era       |       Timescale‑specific      |
>       +‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+
>       |                                                               |
>       +                            Cookie (64)                        +
>       |                                                               |
>       +‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+
>       |                                                               |
>       +                      Origin Timestamp (64)                    +
>       |                                                               |
>       +‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+
>       |                                                               |
>       +                      Receive Timestamp (64)                   +
>       |                                                               |
>       +‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+
>       |                                                               |
>       +                      Transmit Timestamp (64)                  +
>       |                                                               |
>       +‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+
>       |                                                               |
>       .                                                               .
>       .                    Extension Field 1 (variable)               .
>       .                                                               .
>       |                                                               |
>       +‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+
>       .                                                               .
>       .                                                               .
>       .                                                               .
>       +‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+
>       |                                                               |
>       .                                                               .
>       .                    Extension Field N (variable)               .
>       .                                                               .
>       |                                                               |
>       +‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+‑+
> 

As said before, I'd keep the existing structure, trying to fill in compatible
values if possible while adding new stuff in extension fields. Maybe after a
transition phase most of the traditional packet may be redesigned in NTPv6 or
later.

Regards,
Ulrich

> 
> ‑‑ 
> Miroslav Lichvar
> 
> _______________________________________________
> ntp mailing list
> [email-masked] 
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 30 Apr 2020 12:16:44 +0200

> That would break any non-autokey auth, right?

No, authentication with symmetric keys (and autokey) still works. The
MAC (and crypto NAK) just needs placed in an extension field. NTS has
its own authenticator field, which is already in an extension field.

> What is the purpose of that proposal for responses?

It takes more time to transmit (and receive) a longer packet. Unlike
in PTP, we don't rely on the hardware to compensate for the
transmission delays. A response needs to be padded to the length of
the request to avoid an asymmetry in network delay. Otherwise, there
would be an error in the measured offset. 

> What does "removed" mean? "Kept empty"?

No, it doesn't exist anymore. Its place in the header is used by the
new fields.

> indicator to detect a free-running clock or similar correctness assumptions.

Yes, for monitoring/debugging purposes it can be useful. Most (S)NTPv4
clients completely ignore this field, so I don't think it should stay
in the header. It can be replaced by an extension field.

> I see this very problematic: Symmetric keys are the only variant that works up

This part is about the symmetric NTP mode (aka peers), not symmetric
keys. Symmetric keys still work in NTPv5.

> specification of those). I would suggest to completely re-think/re-design

What exactly do you propose?

I don't see a problem with the current extension fields, except the
length restrictions, which would be addressed in NTPv5.

> I think the role of LI should be changed to refer to the current packet only.

Was "packet" supposed to be "day" here, i.e. what we currently have?

> outdated leap second information even before a leap second event happens.

Is 14 days not enough in advance? The timestamp could be in an
extension field if it needs to be provided.

> spec should claim that TAI should be the preferred timestamp?

The proposal allows clients to request timestamps in TAI using the
timescale field in the header. As most operating systems keep time in
UTC and don't always have access to an up-to-date leap second data, I
don't expect TAI to become more popular than UTC in NTP.

> said before: I think there should be a "one version transition phase" before

I don't follow. How would a transition phase help? Clients either
support NTPv5 and can process an NTPv5 response with the modified
fields, or not. Existing servers already have all information needed
to support NTPv5 and can easily do so.

> Aren't thos just "more flags"?

No, it's an enumeration with 8 possible values. It wouldn't make sense
for a client to request two or more timescales at once.

> Would we want to state that the reference ID is a UUID-like byte sequence?

It would have all bits randomly generated. It doesn't need to have a
version field or anything like that, if that's what you mean by
UUID-like. If the value doesn't need to be exchanged in the protocol,
internally it could be saved just as the hash to avoid repeated hashing
when checking the received bloom filter.

> Also: Fixed per server host, set when server process starts, or changed from

Generating a new ID on each start would probably make most sense to me.

> Extensions should be queried before being used; if absent, they can't be

Yes, each extension field should be marked either as required for
NTPv5 or optional. For most optional fields, I think there won't be a
need to ask for their support before use. As servers are required to
ignore unknown extension fields, client can simply request the field
and see if the response has it. Some fields could be special, e.g.
conflict with other fields. Their support could be discovered using an
I-Do extension field as was proposed for NTPv4, but I'd like to wait
for a good example first.

> NTPv6 , there is a transition phase and still one version left before VN wraps

I don't understand how would this work or help.

-- 
Miroslav Lichvar

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 30 Apr 2020 13:04:49 +0200

>>> Miroslav Lichvar <[email-masked]> schrieb am 30.04.2020 um 12:16 in
>> >>> Miroslav Lichvar <[email-masked]> schrieb am 29.04.2020 um 16:45
in

[...]
> What exactly do you propose?

In NTPv4 the extension field is specified as:
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|E|   Code    |  Field Type   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
while in RFC 7822 it's:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Field Type           |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

So autokey V2 uses a single "field type" (2), but several "Codes" (and R|E
variants). As the protocol changes a lot more "field types" will be consumed. I
think it was a very bad idea to pollute the field type namespace that way.

> Was "packet" supposed to be "day" here, i.e. what we currently have?

Good question! There was quite some confusion what it means and when it should
be set.

> extension field if it needs to be provided.

It sounds more like the minimum. I feel like it SHOULD be 30 days at least.

> don't expect TAI to become more popular than UTC in NTP.

(yes, that came later, I read sequentially)

> to support NTPv5 and can easily do so.

The transition phase might help some bad clients that disregard the version
field, misinterpreting data.
(Yes, NTPv3 is still active)

> for a client to request two or more timescales at once.

OK, I see they are mutually exclusice that way. Is an agreement protocol for a
common timestamp format needed?

> when checking the received bloom filter.

Actually there are differnt types of UUID, one being (almost) purely random,
others are (more or less) guaranteed to be unique only.

> Generating a new ID on each start would probably make most sense to me.

I agree it would not harm, while it should not be required. (so it MAY)

> for a good example first.

See "mess" above ;-)

>> protocol may only change the corresponding extension field. When having
that 
> in

Will there be versions > 7 ever?

Sorry for all my typos...

Regards,
Ulrich

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 30 Apr 2020 13:56:22 +0200

> think it was a very bad idea to pollute the field type namespace that way.

Ok. This is the old issue in how the field type is interpreted
differently in different contexts. For NTPv5 we can specify it any way
as long as it's consistent with the types that were already assigned.
There are not that many of them. I assume we don't want to assign new
NTPv5-specific types to the existing NTPv4 extension fields.

Of course, implementations that want to support NTPv5 will need
conform to the specification in how they interpret the field to
prevent a new extension field to be mismatched. I don't see a problem
here.

> It sounds more like the minimum. I feel like it SHOULD be 30 days at least.

There was a time (before RFC 5905) when ntpd announced it whole month
before. That lead to the leap indicator getting stuck as there was no
period where it should be unset. I'd rather not risk that happening
again.

> (Yes, NTPv3 is still active)

I still don't follow. A client won't get an NTPv5 response unless it
makes an NTPv5 request. Old clients will work exactly as before. It
was the same with the NTPv3->NTPv4 transition.

I'm not sure how much should we care about buggy clients, anyway.

> common timestamp format needed?

The timescale field is the whole protocol. If a client wants to get
timestamps in TAI, it will set the field to the value corresponding to
TAI. If the server supports it, it will respond with the same value in
the field. If it doesn't support it, it will respond with a different
value and the client can either accept the timestamps in the other
timescale or ignore the response (and switch to another server if it's
a pool for example).

> Will there be versions > 7 ever?

It could be, but it would need to be saved in a different field. 7
would mean "go look elsewhere".

-- 
Miroslav Lichvar

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 30 Apr 2020 14:34:42 +0200

>>> Miroslav Lichvar <[email-masked]> schrieb am 30.04.2020 um 13:56 in

[...]
> period where it should be unset. I'd rather not risk that happening

I was talking about an extension field that ol versions don't know of AND I
was proposing to add the time when the leap event is to occur...

[...]
> would mean "go look elsewhere".

My proposal was to introduce the feature right now, having the version in two
locations in parallel, and in the future only in the new location. I'm assuming
we do NOT want to redesign the packet completely...

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 30 Apr 2020 15:00:04 +0200

> was proposing to add the time when the leap event is to occur...

If a timestamp of the leap second is provided in an extension field,
it would better have its own leap indicator, so it can be set as soon
as the Bulletin C is published. The leap indicator in the header
should be useful without this extension field.

-- 
Miroslav Lichvar