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