[Ntp] Antw: [EXT] Re: An NTPv5 design sketch

>>> Daniel Franke <dfoxfranke@gmail.com> schrieb am 16.04.2020 um 19:34 in
Nachricht
<17898_1587058469_5E989725_17898_95_1_CAJm83bBBAwA9Da7aasneHV+JfVDOaT2j-Ymyem40-
FmjTQ8Jg@mail.gmail.com>:
> On Thu, Apr 16, 2020 at 4:26 AM Miroslav Lichvar <mlichvar@redhat.com>
wrote:
>> The device may be very simple. It may not have an OS and NTP may be
>> the only networking it does. It could be measuring intervals in a
>> physics experiment, or controlling a robot in a factory. Consider
>> where and why PTP originated and that NTPv5 with its correction field
>> might be usable there too.
> 
> I remain skeptical that systems actually exist, even in these domains,
> where unprotected NTPv5 would be a good solution but NTPv5 with NTS
> would not be. I've forwarded this thread to a friend who has done a
> great deal of work with systems of this nature so that she weigh in
> further. At any rate, I second Doug Arnold that if a use case is
> already well‑served by PTP, then complicating NTPv5 on their behalf is
> not solving anyone's problem.

Yes, beware of "feature-ism" (adding more and more non-essential features)

> 
>> Protected responses need to be handled in the same way as unprotected
>> responses. You never know if the server isn't compromised and trying
>> to attack you.
> 
> I think you've misunderstood me here. I'm not talking about cases like
> "don't do an out‑of‑bounds read if the length field is longer than the
> actual packet length" which yes, need to be handled regardless. I'm
> referring to handling NTS stripping attacks and making sure you don't
> accept an unprotected packet from a source that should only be sending
> protected ones.
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp