I don't think we want a *requirement* that we "advance" the NTS handshake process in strict lockstep with the NTP packet exchange.
This could be the choice of an implementation but it should not be a requirement. As I recall (and I could be wrong), the 3rd NTS packet, which is the start of the 2nd NTS exchange, contains information that is computationally expensive for the "other side" to process. While the extra processing in between T2 and T3 delay is not an issue for the protocol itself, it could well be more expensive than is desired for a blocking operation. For a multitasking server, it could well be that one "thread" does the ordinary NTP handling while another does the NTS work. The first thread might say "I'm willing to wait N milliseconds before I reply to this request", and if the NTS processing gets done in time then the client_assoc info is ready in that response. If not, a "plain" response goes back, the client sends a plain NTP packet as its next query, and the server replies with NTP+NTS-client_assoc. I think it's a Bad Idea to make assumptions and "proactive restrictions" about how to do these exchanges. H _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
