I'm close to finishing cleaning up all the FIXMEs I had left behind.
What's next? There are 2 major items on my list: More and/or alternate certificate checking. There are lots of possibilities in this area. I haven't found one that looks clean and simple. We can afford modest amounts of setup work since we know the target servers and they don't change often. (as compared to a web client where you may see a new server on each mouse click, and the user wants it right-now) We also have to consider getting started without knowing the time. Eric: Have you looked at this area? Cluster support. I carefully said "cluster" rather than "pool". I'm interested in the case where all the NTP servers are run by the same organization or at least the server operators are well known and trusted by the cluster admin. I think the current code is ready for a release and more testers. We can't do a "Supports NTS" release until the draft turns into a RFC since some numbers haven't been assigned by IANA yet. Call it pre-beta or some good weasel-word like that. The current code has one interesting quirk. The cookie key gets rotated every hour rather than every day. If your polling interval ramps up enough, your cookies become invalid and that tests the retry NTS-KE logic. We will want to remove that before a non-beta release. Maybe sooner. There is a potential item: We may need the NTP server to listen on some port in addition to 123 in order to get around various filtering rules leftover from NTP DDoS amplification attacks. Need more data which a release would help. Medium size items: I think we need a couple of scripts for monitoring certificates. Details TBD, but I'm thinking of things like when does my certificate expire and tell me ??? about the certificates on the servers I'm using. This will get more interesting when we figure out what to do about additional certificate checking. It would be half just a convenient reminder of how to do things and maybe a cron job to warn you that your certificates are timing out or some server's certs are busted. Save a couple of cookies to disk so we can restart/reboot without going through NTS-KE. They need to be refreshed occasionally. That also means saving S2C and C2S. Maybe we should go through the NTS-KE exchange occasionally to refresh S2C and C2S. We need a good writeup on getting started when the system time may not be known. That means we have to understand the issues. We need to think about statistics. This is more than a NTS issue. Currently, "ntpq -c nts" does what I want, but nothing gets logged to disk. Other log-to-disk chunks clear the counters that ntpq shows. Sometimes, I want to see the totals. Mumble. Maybe we should save the totals and have ntpq show 2 columns: totals and recent. Or maybe a mode where it divides the columns by the time. ------ How is the documentation? I thought there was work on a HOWTO level doc, but I can't find it. ------ Back burner: I want to make 2 programs, a client and server for NTS-KE. Stand alone. Simple. Partly as an example of how to use OpenSSL, what I was looking for when I was getting started, and partly for debugging NTS-KE, just lots of printout to show what the other end is doing. (Eric: This might be an interesting go exercise.) Next is a NTP client using a cookie saved from above. I want to hack this to be able to measure server performance. Shared key too. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
