Re: [Ntp] NTPv5 draft

[Doug Arnold <[e-mail]>]

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.

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. 

Doug

On 11/30/20, 2:12 PM, "ntp on behalf of Dieter Sibold" <[e-mail] on behalf of [e-mail]> 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
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/ntp

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