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

[Ragnar Sundblad <[e-mail]>]

> On 26 Mar 2020, at 15:07, Hal Murray <[e-mail]> wrote:
> 
> 
> [e-mail] said:
>> 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. 
> 
> I think you are underestimating the ability of complicated systems to screw up 
> in ways that are not anticipated and/or for people to write and read 
> complicated specs.
> 
> Consider Miroslav's example of TCP working while UDP gets firewalled.  (My 
> code would not be nice in that case, and I'm a nut-case about retrying too 
> hard.  I'll have to think about how to fix that.)  When does the NTS-KE retry 
> timer get reset?

"Clients MUST NOT reset the retry interval until they have performed a
successful key establishment with the NTS-KE server, followed by a
successful use of the negotiated next protocol with the keys and data
established during that transaction.”

So, as I said to Miroslaw, there will be a KE, 8 NTP requests,
increasing retry timer, repeat.

>  How many independent retry timers do we need?

One per NTS-enabled-NTP server.

>  (Do we need 
> another for DNS?)

I don’t think so, but you probably know better than me!

> I think this area is complicated enough that we shouldn't try to over engineer 
> it.  What can we say that will be easy to understand and cover most of cases 
> we can think of today?  Being overly conservative is OK with me.

Have you checked out Section 4.2 in draft v28?
<https://tools.ietf.org/html/draft-ietf-ntp-using-nts-for-ntp-28#section-4.2>

> Can we list nasty cases?

Do we know of any yet?
But there probably will be, that is one of the at least three reasons
that the draft says:
"The exact workings of this will be dependent on the application and
operational experience gathered over time.  Until such experience
is available, this memo provides the following suggestion.”

> Can we push things like that to some other document 
> that is easier/faster to update?

That would be nice!
Is there anything similar for other protocols?

> Do we want to add something like:
>  This area lacks experience.  Code using NTS-KE MUST NOT be installed in 
> places where it can't or won't be updated.
> 
> ----------
> 
> I got mail saying
> The IESG has approved the following document:
> - 'Network Time Security for the Network Time Protocol'
>  (draft-ietf-ntp-using-nts-for-ntp-28.txt) as Proposed Standard
> 
> Is there any point in discussing things like this?

We likely can’t change the the spec at this time, but again, this
particular issue will likely develop over time.

> Do we get to see a version after the editor fixes the tbds and such yet before 
> it is officially published?

I suppose, I’ll check!

Ragnar