On Thu, Mar 24, 2016 at 06:15:46PM -0400, Sharon Goldberg wrote: > > > > The main reasoning here was, I believe, that an inherent solution would be > > easier to tailor to a time synchronization protocol's special needs, > > particularly for the additional delays caused by the cryptographic > > operations on time-sensitive packets to be small (and ideally > > symmetrical). > > > > OK, that's interesting. > Can you please elaborate on the symmetrical requirement? > And, following some comments of Miroslav I also wonder the following: > > 1) Will NTS's KE messages be piggybacked on NTP's normal packets with the > usual T1, T2, T3, T4 timestamps?
Yes (if I understand the current drafts correctly). > 2) If yes, then during the KE, will the client actually uses these > timestamps to set its clock or inform any of NTP's clock discipline > algorithms? Not unless there is some way to authenticate timestamps from the earlier packets. > 3) If yes, then I guess you will want to be very careful about the delay > introduced by the public key crypto operations in the KE. How will you deal > with that, in light of the fact that eg. RSA signing is 10x slower than RSA > verification, and RSA encryption is 10x faster than RSA decryption? > > Does this even matter? Maybe it depends on what "symmetrical" means? The speed of the RSA operations shouldn't matter as far as the accuracy of the synchronization is concerned. What matters is the delay between an NTP server or client capturing the TX timestamp and the other side capturing the RX timestamp. Asymmetries in that delay add an error to the measured offset. The delay includes the calculation of the MAC, the actual transmission and the network delay. It's a function of the packet length, so there is a tendency to keep the packets symmetric and short. The delay due to the MAC calculation can be estimated and compensated (at least one NTP implementation tries to do that), but the other parts of the delay I suspect would be very difficult or impossible to estimate. Wrapping NTP packets in some other protocol like IPsec would create an additional delay. If it was symmetric or it could be estimated reliably, perhaps it wouldn't be a problem for accuracy. However, the size of the state the server would have to keep per client would limit the maximum number of clients. -- Miroslav Lichvar _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
