Re: [Ntp] How many clients does a busy PTP server support?

[Doug Arnold <[e-mail]>]

Good question, Hal.

For multicast, or mixed multicast/unicast profiles, a group key approach makes the most sense.  This is what is proposed in draft-langer-ntp-nts-for-ptp-01<https://datatracker.ietf.org/doc/draft-langer-ntp-nts-for-ptp/>.  However, even in this case much of the terminology and structure is barrowed from NTS for NTP.

In the case of unicast PTP, which in practice is always negotiated.  A PTP server can have thousands of clients, so it makes sense to use the ticket mechanism of draft-langer-ntp-nts-for-ptp-01<https://datatracker.ietf.org/doc/draft-langer-ntp-nts-for-ptp/> or the approach of
draft-gerstung-nts4uptp-02<https://datatracker.ietf.org/doc/draft-gerstung-nts4uptp/>.  Both of which are similar to NTS for NTP.
Lastly, from a development cost perspective, it is desirable to make NTS for PTP as mush like NTS for PTP as possible.  This will also be helpful to network operators who have to maintain secure versions of NTP and PTP
Doug




From: ntp <[e-mail]> on behalf of Hal Murray <[e-mail]>
Date: Tuesday, June 1, 2021 at 6:54 PM
To: [e-mail] <[e-mail]>
Cc: Hal Murray <[e-mail]>
Subject: [Ntp] How many clients does a busy PTP server support?

Most of NTS4NTP is dancing around the lack of per-client state on the server.

If PTP servers only support a "small" number of clients and PTP already has a
mechanism using shared keys, it might be simpler to just use TLS/whatever to
setup keys.

If it takes 100 bytes for a server to store a key, that's 10K clients per
megabyte.  Raspberry Pi-s come with gigabytes so the numbers seem worth
further investigation.

Does the PTP shared key stuff cover all the problems?  (or enough of them to
be interesting)


--
These are my opinions.  I hate spam.



_______________________________________________
ntp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ntp