I like both of those, port randomization and better transmit timing. Plus it will make the IETF people happy.
..π₯πΈπ Mark Atwood <mark.atw...@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 <hmur...@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@ntpsec.org > http://lists.ntpsec.org/mailman/listinfo/devel > _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
