hmurray at megapathdsl.net
Mon Sep 16 06:33:20 UTC 2019
Two areas to consider:
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
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
These are my opinions. I hate spam.
More information about the devel