Future directions

Eric S. Raymond esr at thyrsus.com
Mon Sep 16 10:00:37 UTC 2019

Hal Murray <hmurray at megapathdsl.net>:
> 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

Both good proposals.  I had been thinking about doing the
transmit-timing one myself
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

More information about the devel mailing list