Miroslav Lichvar writes: > On Thu, Mar 24, 2016 at 06:15:46PM -0400, Sharon Goldberg wrote: > > 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.
It's a local policy choice. If a client chooses to only believe authenticated time, then if no alternative MAC is available until NTS has completed KE timestamps will not be used. If another method (like symmetric key) is available and enabled, that authentication can cover these initial timestamps. There are other choices as well, but I think we're talking about implementation choices and local policy choices. Let's go the right distance here, neither too restrictive nor too permissive. > > 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. Sure. But this goes beyond the case of "this packet and this association". See my previous message. We must not *require* that we do the full crypto operations between T2 and T3 in a busy server that is not multi-threaded. That will very likely mess up capture timestamps that are pending receipt while we're doing the crypto operations on the current packet. > 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. Is there empirical data to support the need for symmetric packet lengths? If so, is this a universal condition? Is there empirical data to show behavioral differences between various packet lengths? If so, are these results universally consistent? > 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. How do you do IPsec without correct time? H _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
