Future directions

[Hal Murray]

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.