> I want to put arrows on the flow diagram. Data flows both way over most connections. You probably want the arrow to mean who initiates the connection rather than which way data flows.
The NTP-server to NTS-KE-server is complicated. Gary has proposed no connection, start with the shared key in a file and keep the keys in sync by running the same update on both ends. I think that could be made to work, but I'd prefer a connection. A connection handles the case of multiple NTP servers for a single NTS-KE server and sets things up for the case of multiple NTS-KE servers for the same name. With a connection, we could avoid storing the master keys on disk. Clients would have to rekey if the system rebooted. We could restart NTP-server or NTS-KE-server as long as the other end stayed up and we arranged to send the keys in both directions. There is another problem area: who makes the initial certificates. If the NTS-KE server makes them, then the admin has to keep the NTS-KE server and NTP server in sync. If the NTS-KE server gets them from the NTP-server, then we need a working connection from NTS-KE server to NTP-server in order for a NTP-client to get started. I think the common case of both on the same system should be OK. If the NTS-KE-server can't connect to the NTP-server the NTP-client probably can't either. I haven't thought much about more complicated configurations. > Delta will need an IANA public port assignment. The NTP port is assigned and unused for TCP. I've been assuming that we will use that until somebody says otherwise. > I'm leaning towards an organization in which the NTS client code lives inside > ntpd; this would reduce deployment friction slightly. Is there any scenario > in which we'd want to run these pieces on different hosts? Seems reasonable. It might be nice to have them as separate programs until we get things going. For example, we could write hack debugging programs to act as fake NTP or NTS-KE clients to figure out what the other end is doing and/or poke particular cases. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
