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. > > 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 _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
