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

>>> Miroslav Lichvar <mlichvar@redhat.com> 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
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp 