Re: [Ntp] ntpv5 requirements

Hey all,

at this point, I would be really interested to see NIST's actual scaling 
and performance requirements for their use case.
It seems like a shaky foregone conclusion by them (and/or by Harlan, see 
in-line below) that 
  a) NTS would not fulfill their requirements, and 
  b) anything else (existing or to-be-made) would fulfill them any better.

But if I'm wrong, or if the foregone conclusion happens to be accurate, 
then we should look into whether and how we can help.

Best regards!

> > 
> >> 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.
> 
> Whatever.

Noted.

> The point remains that there are clearly environments out there where 
> NTS does not currently sufficiently scale.

Is there more than one claim about one such environment?

> > 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.
> 
> Maybe, but I don't see how this is significant. 

Noted. 

> The bottom line is that NTS does not currently appear to be usable at 
high traffic volumes.

How did you get to this bottom line?
Again, I also find it unduly vague; are you just talking about NIST's 
prediction, or any more (harder?) data points?
Also again, note that PTB *is using* NTS at a volume currently sufficient 
for the interested parties on a nation-wide level.

> > 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.
> 
> I was merely responding to something you said on the thread.
> 
> > But this is so far beside the point, let's either open up a separate 
> > thread for it or drop it.
> 
> I have no preference.
>
> H
> --
> >> 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>
> >> > <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/><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>
> >> > <https://www.ietf.org/mailman/listinfo/ntp 
> > <https://www.ietf.org/mailman/listinfo/ntp>>
> >> > 
> >> > 
> >> 
> >> -- 
> >> 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!