NTS: What next?

[Hal Murray]

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.