Re: [Ntp] I-D Action: draft-ietf-ntp-using-nts-for-ntp-27.txt

[Miroslav Lichvar <[e-mail]>]

On Thu, Mar 26, 2020 at 11:49:57AM +0100, Ragnar Sundblad wrote:
> > On 26 Mar 2020, at 10:56, Miroslav Lichvar <[e-mail]> wrote:
> > But it seems we don't agree on how long actually will be the NTS
> > sessions. You seem to be saying that a short initial interval in the
> > exponential backoff is ok (in the name of simplicity), because the NTS
> > sessions will be so long that the average rate will be insignificant
> > over those long periods. Is that correct?
> 
> Hmm, I don’t think so. Also, do you mean one KE negotiation is one session,
> or from one KE negotiation to the next one, if the clients reboots runs out
> of cookies is one session?

By session I mean how long the client is using or trying to use the
server, including all NTS-KE and NTS-NTP requests.

> I did mean, that the initial 10 seconds will only be 10 seconds if the server
> is up but will not accept the TCP connection, if for example the listener
> has not started, or is so overloaded that the TCP connection queue is full
> (and this will be very cheap for the server, handled by TCP).
> If the server is not up or not reachable, TCP will retry for a while before
> giving up. (This will of course not cost the server anything.)
> If the server accepts the TCP connection but is overloaded and slow to
> respond, the client will just wait for the request to be handled (and could,
> likely should, timeout after a while). There is no extra cost for the
> server for this, really.

Yes, but I'm concerned with the cases where something breaks after the
connection is made and when much more resources are wasted per
request.

> > Computers
> > are shut down or suspended frequently.
> 
> If they are suspended, there is no need to renegotiate.

Usually, but the system may need to restart the NTP client due to a
different DHCP configuration for example.

> > Clients are switching between
> > different servers of a pool.
> 
> Only when the ntp client is restarted, right (at least with the clients
> of today).

No, clients may switch between servers when they become unreachable
(e.g. due to rate limiting). I see this often with my mini-pool of NTS
servers.

> > I think it will take only a small portion of NTS clients to be
> > consistently failing in NTS-KE or NTS-NTP after the TLS handshake
> > (e.g. due to a network issue, bug, or incompatibility) and overwhelm
> > the server with their short retry intervals.
> 
> They should not fail with a working server, why would they?
> And if they do, they will very quickly get to long retry intervals,
> and there is likely something broken with the server anyway.

Well, as I said above, there are many reasons why NTS-KE or NTS-NTP
may be consistently failing. For example, an ISP may have a firewall
that blocks large NTP packets. NTS-KE will work as expected, but
no NTS-NTP reply will be ever received, so the clients will be
constantly restarting NTS-KE. If the clients were restarted once per
day and used the 1024*2^(n - 1) retry interval I suggested, the number
of NTS-KE requests would drop to 30%.

-- 
Miroslav Lichvar