Re: [Ntp] Antw: [EXT] Re: Robert Wilton's Discuss on draft‑ietf‑ntp‑interleaved‑modes‑05: (with DISCUSS and COMMENT)

[Miroslav Lichvar <[e-mail]>]

On Wed, Jul 21, 2021 at 12:07:47PM -0700, Erik Kline wrote:
> >
> > Of course, this doesn't change anything about compatibility with
> > existing NTPv4 implementations. There is no clean way to detect the
> > support.
> >
> 
> <random bad idea>
> For client mode, could the client make use of the LI field to indicate it
> speaks interleaved?
> </>

No, there are clients that always set it to synchronized, other
clients set it always to unsynchronized, and other clients set it to
their actual status.

If we are considering unclean solutions abusing unrelated fields, the
best one would be the reference timestamp. It is 64 bits and it is
normally ignored by the server. The NTPv5 proposal uses this field to
detect whether an NTPv4 server supports NTPv5. Not a clean solution,
but I don't see a better one. What would IESG think about that?

For the interleaved mode, clients could be required to set it to a
specific value, maybe XORed with their RX and TX timestamps, to push
the false positive rate to the 1/2**128 territory. I think this would
truly make it the hack that same people already consider it.

My opinion still is that clients that set their origin timestamp to
anything else than zero or the transmit timestamp from the received
packet don't follow the NTP specification. It's not a subset of the
protocol.

In case this argument doesn't hold, I also analyzed traffic on
multiple public servers to confirm that there were no implementations
unknowingly sending requests in interleaved mode. The only instance
was the ntpsec fork of ntp, which already supported interleaved mode,
but had the support only partially removed, and this is what I think
actually prompted the Daniel's objection to the proposal.

Now, with many public servers having the support, it would be
difficult to implement a new client with such a bug and not notice it.

-- 
Miroslav Lichvar