On Thu, Mar 24, 2016 at 04:05:56PM -0400, Sharon Goldberg wrote: > On Thu, Mar 24, 2016 at 4:49 AM, Miroslav Lichvar <[email protected]> > wrote: > > 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. )
As I understand it, NTS doesn't change anything in the NTP polling process. It should be similar to Autokey. Clients poll the server as they would normally without any authentication and NTS extension fields are added to the packets depending on what state the NTS association is currently in. Only when the NTS association is initialized, the received packets are used for synchronization. If the clients sent a new request immediately, that would create a rapid burst and the server might drop the packets due to rate limiting. If the server didn't respond, the client would have to use a timeout for a new request with some exponential backoff. To me it seems easier to rely the normal NTP polling process, which was designed to not overload the server. >From the server point of view, I think there should be no change in the observed packet rate (after IP defragmentation) when clients enable NTS. > 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? If I understand how NTS will be implemented correctly, the duration of the KE is proportional to the polling interval. > 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? They might want to reinitialize the NTS association as quickly as possible and this would increase the request rate observed on the server. I suspect the expensive crypto operations will be a problem on busy servers even if the request rate doesn't change and the servers will probably need to use multiple seeds for groups of clients split by their IP address and refresh the seeds sequentially in order to spread the extra CPU load. > > 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. Yes, from the commit message it does look like an unintentional change. > > 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? If we compare clients that send the same number of packets in the same interval, the client that puts all packets in the association using NTS will have the first authenticated sample sooner than a client that has a parallel association with the server. Here is an illustration: packet # client 1 client 2 1 client_access client_access 2 client_assoc non-NTS 3 client_cook client_assoc 4 time_request non-NTS 5 time_request client_cook 6 time_request non-NTS 7 time_request time_request -- Miroslav Lichvar _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
