[Ntp] Antw: [EXT] Re: NTPv5 draft

>>> Doug Arnold <doug.arnold@meinberg-usa.com> schrieb am 30.11.2020 um 23:12
in
Nachricht <49B3601E-C6A9-4B9E-BE9D-7FD69CCC54DC@meinberg-usa.com>:
> RE security: 
> I think that there is a possibility of a non safety-critical closed network

> application of ntp that does not need security.  Especially if the client
has 
> a limited processor implementation.  I don't know, a golf course watering 
> system or something.

I think an interesting point is this: Do people think they don't need
security, because

1) it costs extra CPU cycles
2) it's difficult to set up and maintain
3) it brings no benefit

As Doug pointed out there are use cases for 3), but when 1) and 2) become
practically meaningless, many people won't care about 3), I guess.

> 
> Mandatory or not, I think that security should be added to the protocol as 
> an extension field, and described in another document.  Security mechanisms

> change frequently.  I think that there is a good chance that we, or someone,

> will define a successor to NTS within 10 years.  But the over the wire ntp 
> specification might last longer.  One of the virtues of Miroslav's proposal

> is that the minimum ptp message and protocol are simple and everything else

> is an extension. 

Yes, cryptography must be flexible.  Maybe just to meet legal restrictions for
some countries.

Regards,
Ulrich

> 
> Doug
> 
> On 11/30/20, 2:12 PM, "ntp on behalf of Dieter Sibold"
<ntp-bounces@ietf.org 
> on behalf of dsibold.ietf@gmail.com> wrote:
> 
>     Hi Miroslav
> 
>     Many thanks for your NTPv5 proposal.
> 
>     With my working group chair’s hat off!
> 
>     I have following comments:
> 
> 
>     1. Security
> 
>     The protocol as proposed is missing a security approach. There are no 
>     mechanisms described to provide authentication, integrity protection and

> 
>     maybe encryption. I very much agree with Jame’s proposed draft that a 
>     new version of NTP must provide these mechanisms by default.  Sure, you

>     can add NTS to protect the NTPv5 packets. But in this case protection is

> 
>     always an optional add-on whereas it needs to be an inherent part of the

> 
>     basic protocol. To achieve this the NTS approach certainly can be 
>     transferred to the basic v5 protocol and packet format.
> 
> 
> 
> 
>     2. Interleave and 2-Step
> 
>     I agree with Doug to decide with approach to provide with NTPv5. 
>     Providing both 2-Step and Interleave may increase complexity 
>     unnecessarily. Personally, I find that the 2-step approach with the 
>     follow-up message is more concise. And since the first message only need

> 
>     to be very small (it just needs to contain the information to ensure 
>     correlation with the follow up) the waste of network bandwidth is very 
>     small.
> 
> 
> 
>     3. Traceability
> 
>     It would make sense that the v5-packets optionally provide information 
>     about the uncertainty of the timestamps taken. These formally for 
>     establishing traceability. Additionally, in order to maintain 
>     traceability during the time period in which leap smearing is applied 
>     the client needs to obtain the necessary information to calculate the 
>     offset between UTC and smeared time. This also is mandatory to maintain

>     traceability.
> 
> 
>     Dieter
> 
> 
> 
> 
> 
> 
> 
> 
> 
>     On 11 Nov 2020, at 17:19, Miroslav Lichvar wrote:
> 
>     > As promised on the previous meetings, I wrote an NTPv5 draft. It's
>     > based on the proposal I sent to this list few months ago, with few
>     > improvements like timestamp fields seperated from cookies, etc. It
>     > still needs a lot of work to be able to stand on its own, but I think
>     > it should be good enough for people here to understand how it is
>     > intended to work.
>     >
>     > It's too late to submit it for the upcoming meeting. Here is a link
to
>     > a txt version if anyone would like to read it and discuss it here:
>     >
>     > https://gist.github.com/mlichvar/2bee94a706d60da9ca88d712afef083e 
>     >
>     > -- 
>     > Miroslav Lichvar
>     >
>     > _______________________________________________
>     > ntp mailing list
>     > ntp@ietf.org 
>     > https://www.ietf.org/mailman/listinfo/ntp 
> 
>     _______________________________________________
>     ntp mailing list
>     ntp@ietf.org 
>     https://www.ietf.org/mailman/listinfo/ntp 
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp 