Re: [TICTOC] [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp

[[e-mail]]

Miroslav, please see my comment below



-----"ntp" <[e-mail]> wrote: -----

>To: Daniel Franke <[e-mail]>
>From: Miroslav Lichvar 
>Sent by: "ntp" 
>Date: 08/31/2017 16:03
>Cc: "[e-mail]" <[e-mail]>, "[e-mail]"
><[e-mail]>, Karen O'Donoghue <[e-mail]>
>Subject: Re: [Ntp] WGLC for draft-ietf-ntp-using-nts-for-ntp
>
>On Thu, Aug 31, 2017 at 08:34:02AM -0400, Daniel Franke wrote:
>> Lots of people on this list seem to have the intuition that sending
>> time packets over DTLS can never be as accurate as sending them
>over
>> the NTP port with an authenticator attached. But as I showed in my
>> analysis the other day, that just ain't so.
>
>The problem is not with transmission. The problem as I see it is with
>transport and reception. Encryption prevents modifications of the
>packet in the network, which will be needed for delay corrections.
>A different port number will not work with existing QoS in
>switches/routers and hardware timestamping in NICs. I'm sure in some
>cases reconfiguration to handle both ports will be possible, but
>there
>is HW where the port number is hardcoded in the firmware or silicon.
>If there is a rarely used port for timing messages, will everyone
>support it? I doubt that. The symmetric mode will not get all
>benefits
>of NTP support.
>
>If DTLS records were exchanged in NTP packets in extension fields, as
>was originally considered by the design group, this wouldn't be a
>problem.

During the NTP interim meeting in Boston, Oct 2016 we had a thorough discussion of how to transport NTP's symmetric mode. At this time we had consensus to postpone the encapsulation of DTLS records within EF. Therefore, the draft represents the decisions take at that time. As Daniel pointed out. The current scheme to protect the symmetric mode has no disadvantage regarding time synchronization performance. I would guess that for the majority of mode 1/2 configuration it will work just well. It will certainly not work for the special configuration you mentioned. But an alternative approach can be specified, if future reveals that for any reason this is mandatory for the symmetric mode. But until that we should promote the current approach.

>
>> > My recommendation is to remove the specification of NTS in the
>symmetric
>> > mode from the document, at least for now. I believe the NTS-KE
>used in
>> > the client/server mode can be adopted for the symmetric mode,
>possibly
>> > with some small extensions, but it will take time. I think most
>of us
>> > here will agree it shouldn't delay the adoption of NTS in the
>> > client/server mode.
>> 
>> If specification for symmetric mode were removed, how would section
>4
>> read? Do you want to get rid of DTLS encapsulation altogether?
>> Restrict what traffic can be sent over it? Can you send a PR with
>what
>> you have in mind? (Won't promise to merge it, but I'll review it)
>
>I'm not sure. I think the whole section could be limited to the
>control (6) mode. The other modes (1, 2, 3, 4, 5, 7) can be
>allowed, but not recommended. In the broadcast mode I think it
>doesn't
>make much sense anyway.
>
>> The
>> identity in that certificate is the additional information you're
>> looking for.
>
>Ok, thanks.
>
>-- 
>Miroslav Lichvar
>
>_______________________________________________
>ntp mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ntp
>