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

[Ragnar Sundblad <[e-mail]>]

> On 26 Mar 2020, at 15:01, Miroslav Lichvar <[e-mail]> wrote:
> 
> On Thu, Mar 26, 2020 at 02:01:16PM +0100, Ragnar Sundblad wrote:
>> Oh, so you think there is a risk that both the KE negotiation works
>> and at least one NTP requests works, and soon thereafter the
>> connection breaks, frequently?
>> I am not sure why that would happen very often, but if it did, there
>> Should at least be 8 NTP requests (until the client has exhausted its
>> cookies) until it contacts the KE server again.
> 
> Rate limiting of NTP packets in some networks is a major issue, which
> was discussed on this list. I sometimes see over 90% packet loss. The
> client would need to reuse cookies to operate reasonably well in such
> conditions. I agree the 8 polling intervals from NTP helps here
> (assuming the interval is not reset to the minimum after NTS-KE and
> it's not using a burst).
> 
>>> 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.
>> 
>> Oh really, I didn’t know. So chrony does that? (Nice!)
> 
> I think most NTP and SNTP clients do that.

Right, SNTP most likely.
But NTP? Oh well.

>>> 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%.
>> 
>> Ok - in this case too, there should be 8 NTP requests before it contacts
>> the KE server again, and it will increase the retry interval each time
>> since it has not completed a full cycle of getting cookies and succeeded
>> in using them.
> 
> You are right. Good point. Maybe a bug or incompatibility between
> different implementations would be a better example.

Yes, bugs could cause almost any behaviour, but it is a very specific
and narrow class of bugs that we would fix by changing those constants.

Ragnar