Two areas to consider:
Port randomization: https://tools.ietf.org/html/draft-gont-ntp-port-randomization-04 The basic idea is for the client side to use a random port number when sending packets so bad guys have a harder time attacking with junk packets if they can't monitor the traffic to see the port number. (Without this feature, they know the port number is 123.) There are two ways to implement it: random per-packet, or random per-target. Some routers include the source port when hashing to select among alternate routes. They suggest per-target which will hide the timing changes due to different paths. I would have picked per-packet in order to get some good data at the cost of discarding a higher percentage of samples. This area seems ripe for some experimentation and data collection. I'd guess somewhere between a day and a week to implement this. --------------- Better transmit timing... We get good time stamps on the receive path. The transmit path is messy. We grab the time before the call to send the packet so it is early. This gets worse with NTS or shared key MACs. There is a draft in the works: NTP Interleaved Modes https://tools.ietf.org/html/draft-ietf-ntp-interleaved-modes-02 It requires per-client state at the server. That's ugly in principle, but not a major problem if you believe that modern systems have lots of memory. I've skimmed it, but not studied it. I've been thinking of measuring the timing and bumping the time stamp to correct for the delay. Again, this seems appropriate for some experimentation and data collection. I'd guess a week or two. Maybe more if the data gets interesting. ---------- We should check RFC 8633 - NTP Best Current Practices https://www.rfc-editor.org/rfc/rfc8633.html -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
