Future directions

[Mark Atwood]

I like both of those, port randomization and better transmit timing.   Plus it will make the IETF people happy.

..𐑥𐑸𐑒
Mark Atwood <mark.atwood at ntpsec.org>
Project Manager of the NTPsec Project
+1-206-604-2198

On Mon, Sep 16, 2019, at 03:00, Eric S. Raymond via devel wrote:
> 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>
> 
> 
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>