Subject: Re: [Ntp] Antw: [EXT] Re: Public NTP servers already responds to NTPv5

From: g16 <[email-masked]>
Date: Sat, 5 Dec 2020 01:21:36 +0900

Hi Salz, Rich

> As Kurt probably knows, TLS 1.3 kept the 1.2 version number because
middleboxes got in the way. As a result, the TLS 1.3 handshake looks like a
TLS 1.2 handshake.

> NTPv5 should keep this in mind, and think of planning experiments if we
deviate too much from looking like NTPv4.

I agree with you.

My first research was inspired by TLS WG experience with the TLS 1.3
Middlebox issue. (First email in this thread)

> I know some WG suffered from anomalous behavior in tcp-fast-open and TLS
1.3 deployments.
> - https://mailarchive.ietf.org/arch/msg/tls/i9blmvG2BEPf1s1OJkenHknRw9c/
> - https://archive.nanog.org/sites/default/files/Paasch_Network_Support.pdf

In the case of TLS 1.3, the issue was investigated using reports from
browsers.

Even if we try to do a wide experiment to investigate the middlebox
problem, the NTP client has no reporting mechanism. (It may be possible
with the help of the OS platform)

To solve it, I find it useful to define an NTPv4 extension that signals a
supported version so that client fallbacks can be detected on the server
side.

Not for version negotiation, but for signaling fallback to the server.

There may be other better ways.