Re: [Ntp] ntpv5 requirements

In-line...

Besten Gruß / Kind regards,
Kristof Teichel

__________________________________________

Dr.-Ing. Kurt Kristof Teichel
Physikalisch-Technische Bundesanstalt (PTB) 
Arbeitsgruppe 4.42 "Zeitübertragung"
Bundesallee 100
38116 Braunschweig (Germany)
Tel.:        +49 (531) 592-4471
E-Mail:   kristof.teichel@ptb.de
__________________________________________

"ntp" <ntp-bounces@ietf.org> schrieb am 15.02.2023 04:10:32:

> Von: "Harlan Stenn" <stenn@nwtime.org>
> An: kristof.teichel@ptb.de, ntp@ietf.org
> Datum: 15.02.2023 04:16
> Betreff: Re: [Ntp] ntpv5 requirements
> Gesendet von: "ntp" <ntp-bounces@ietf.org>
> 
> I don't see that you are disagreeing with me regarding the "priority" of 

> performance.

Let's leave the goalpost were they were: the original question/statement 
was whether/that NTS was specifically designed to scale well with large 
number of clients.
Which it was (I can elaborate if anyone would like, but I feel like we've 
been through this).
I'm disagreeing with your implicit statement that your perceived priority 
of goals is in any way an argument against this.

You also appear to get scaling properties mixed up with performance, 
though they are clearly stated as separate goals and each explained in the 
RFC.
That said, even when confounding them I don't see the argument:
NTS was also specifically designed to affect performance "not 
significantly" (we can go there if need be), and I would argue it simply 
affects performance *as little as possible* (possible while reaching the 
stated security goals).

> And blindly following "amplification goal-stated as zero" has some 
> pretty onerous consequences.

The above is already a pretty hard detour from NTPv5 requirements 
discussions.
But this is so far beside the point, let's either open up a separate 
thread for it or drop it.

> H
> 
> On 2/14/2023 4:28 AM, kristof.teichel@ptb.de wrote:
> > The reason that scalability and performance have traditionally been 
> > listed last in NTS documents is less that they are in any way 
secondary 
> > -- and more that they follow a pattern of "...and it needs to do all 
of 
> > the above in such a way that it retains scalability and performance as 

> > far as possible".
> > (And perhaps a bit of them being quantitative goals rather than 
> > absolute/qualitative; performance is gonna get worse with crypto 
rather 
> > than without, the goal is to keep it reasonable/best possible -- 
whereas 
> > e.g. amplification can be cleanly goal-stated as zero.)
> > 
> > 
> > Besten Gruß / Kind regards,
> > Kristof Teichel
> > 
> > __________________________________________
> > 
> > Dr.-Ing. Kurt Kristof Teichel
> > Physikalisch-Technische Bundesanstalt (PTB)
> > Arbeitsgruppe 4.42 "Zeitübertragung"
> > Bundesallee 100
> > 38116 Braunschweig (Germany)
> > Tel.:    +49 (531) 592-4471
> > E-Mail: kristof.teichel@ptb.de
> > __________________________________________
> > 
> > 
> > 
> > Von: "Harlan Stenn" <stenn@nwtime.org>
> > An: ntp@ietf.org
> > Datum: 13.02.2023 23:29
> > Betreff: Re: [Ntp] ntpv5 requirements
> > Gesendet von: "ntp" <ntp-bounces@ietf.org>
> > 
------------------------------------------------------------------------
> > 
> > 
> > 
> > On 2/13/2023 8:06 AM, Miroslav Lichvar wrote:
> >> On Thu, Feb 09, 2023 at 05:18:20PM +0000, Doug Arnold wrote:
> >>> For example: Judah Levine at NIST recently told me that he 
> cannot  implement NTS with his current server resources and the number 
of 
> > clients NIST supports.  However, when I told him about TESLA he 
thought 
> > a scheme based on that would be doable, as long as the keys didn?t 
have 
> > to change too often.
> >> 
> >> That is interesting as NTS was specifically designed to scale well to
> >> very large numbers of clients.
> > 
> > I don't recall performance in NTS as being a primary goal of the 
design.
> > 
> > Sure, it was listed as *a* goal, but the primary goals were around
> > "security".
> > 
> >> Is their concern about decryption
> >> and encryption of NTS-protected NTP packets, or rather TLS in NTS-KE?
> >  >
> >> In 2016 they reported they had about 200k requests per second across
> >> all their servers [1]. Even if it was 100x more today and all clients
> >> were using NTS, that could still be handled by a dozen of servers 
with
> >> multi-core CPUs and AES acceleration. In my tests I get about 200k/s
> >> per core.
> > 
> >  From what I've heard, NTS key operations take 5-10x the amount of
> > compute power beyond what NTP needs.
> > 
> >> NTS-KE traffic is more difficult to predict as it depends on the
> >> client implementations. I would be curious to see what NTS-NTP to
> >> NTS-KE request ratio do the well-known NTS providers like Cloudflare
> >> and Netnod have.
> >> 
> >> [1] https://nvlpubs.nist.gov/nistpubs/jres/121/jres.121.003.pdf 
> > <https://nvlpubs.nist.gov/nistpubs/jres/121/jres.121.003.pdf>
> >> 
> > 
> > -- 
> > Harlan Stenn <stenn@nwtime.org>
> > http://networktimefoundation.org <http://networktimefoundation.org/>- 
be 
> > a member!
> > 
> > _______________________________________________
> > ntp mailing list
> > ntp@ietf.org
> > https://www.ietf.org/mailman/listinfo/ntp 
> > <https://www.ietf.org/mailman/listinfo/ntp>
> > 
> > 
> 
> -- 
> Harlan Stenn <stenn@nwtime.org>
> http://networktimefoundation.org - be a member!
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp