On Thu, Mar 24, 2016 at 4:49 AM, Miroslav Lichvar <[email protected]> wrote:
> On Wed, Mar 23, 2016 at 06:17:33PM -0400, Sharon Goldberg wrote: > > Before I say how to get around it, I was wondering why this bothers us so > > much? The current ntpd already has the server saves per-client state, > for > > poll interval, rate limiting, and symmetric keys. > > And especially if this state only lives for the duration of the KE? > > There is no limit on the duration. The client may be polling the > server just couple times a day. Sorry, I'm confused. The NTS key exchange is a 6-message exchange that should happen "atomically" (ie. the server gets the clients KE msg, processes it, and immediately sends its own message. & vice versa: the client gets the servers KE msg, processes it, and immediately sends its own message. ) If we are discussing state that only lives for the *duration of the KE* why does it matter how often the client polls the server? Let's not forget the key exchange will > happen not only when the client is started, but also when the server > refreshes its seed. We certainly don't want clients to drop to their > minimum polling intervals or start a burst when that happens. > > That's interesting point, but could you clarify why that would happen? Why would clients react in this way? > > Not sure, not an expert on NTP's timing algos. But we have seen that upon > > initalization, ntpd requires about 4 timing samples before it updates its > > clock. So it could collect these timing samples while the NTS KE is > running. > > I'm not sure if it's intentional, but recent versions of ntpd now > update the clock with the first (authenticated) sample. Older versions > and other implementations may require more. > > I think Danny Mayer told me that was a bug. But I don't know. ntpd 4.2.6 needs several samples. > > There is also a question whether the client would really want to use > > > any samples from the non-timing NTS exchanges as the packets are > > > longer and asymmetric, creating an extra error in the measurements. > > > > > > > > So, in my mind, the timing messages would be sent in separate packets > from > > the NTS KE messages. They would be sent in parallel. That way, the > crypto > > done in NTS does not mess up the accuracy of the timing exchanges. > > If there were two associations per client, I think it would be even > more complex. There would have to be some mechanism for the server to > identify and link the two client associations, so it can hash the > right timestamps (and not timestamps for some other client behind NAT > for instance).The client would have to make sure requests from the two associations are not too close to each other to not violate the > minimum request interval on the server. Yes, that's true. This whole thing adds additional complexity. So we should be sure it is needed before adding it! > If the client is > allowed to increase its polling rate, I think it would be more useful > to do that with the NTS association rather than adding an extra > association, so the client would get the first authenticated sample > sooner. > I'm sorry I don't understand this last point, can you clarify? Sharon -- Sharon Goldberg Computer Science, Boston University http://www.cs.bu.edu/~goldbe
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
