NTP Research Opportunities

1. NTP Research Opportunities David L. Mills University of Delaware http://www.eecis.udel.edu/~mills mailto:mills@udel.edu

2. NTP specification project • The first step in the project is to develop flow charts, state variables and algorithm descriptions for the current NTPv4. This has been largely completed. • The next step is to make a formal outline for the specification, including a glossary, state variable descriptions and notation. A lot of this work has already been done in the briefings, but variable name conflicts remain to be resolved. • The next step is to collect the figures, diagrams and other artwork. This is harder than it looks, since the artwork has to be rendered in forms that may later have to be converted to Postel ASCII. • The next step is to fill out the text in the outline and integrate the artwork. • The final step is to rationalize the final document with the actual behavior of the reference implementation. From experience, this is the most tedious, time consuming task.

3. Fully distributed mode • Fully distributed mode is intended for highly survivable networks where portions of the NTP subnet may be attacked and become unstable. • In this mode each peer runs NTP with every other peers and then broadcasts the time values to all other peers.. • Each peer can then assess the quality of all other peers independently. • Consistency checks can detect when a peer drifts or is pulled out of tolerance. • Selection algorithm survivors can be compared between peers to confirm a falseticker has been correctly identified. • This architecture could serve as the basis of a truly Byzantine selection algorithm as in Lamport’s model.

4. Autokey project • Autokey is the security model and protocol developed specifically for NTPv4. • It uses public-key cryptography and zero-knowledge identity proofs in a protocol specially designed to resist replay flood attack. • It has been implemented and tested at Udel, ISC and USNO and now in regular operation. • A formal specification has been submitted to the IETF, but not in the format required by the RFC Editor. It is not feasible to conform to the required format, as the specification has numerous equations, figures and special mathematical symbols. • It may be possible to convince the IETF to change policy, but that may take a larger hammer than I can carry.

5. Autoconfigure project • Autoconfigure is a collection of evolved algorithms to automatically find NTP servers and build the necessary configuration infrastructure. • It is based on expanding-ring discovery designed to find plural servers and then prune the survivors using the NTP selection and clustering algorithms. • A working prototype has been implemented and tested and now in regular operation. However, the project is not complete: • By default, the algorithms build a flat tree, which is in general undesirable. • There is no way to balance the load among a clique of servers. • What is needed is a whisper campaign where the set of nearby servers can use another group address to run a load balancing protocol. • In addition, the current multicast/anycast paradigm should be extended to the pool concept, which uses a crafted DNS hierarchy to discover servers and load balance.

6. Driver timestamps project • The present timestamp accuracies are limited by variaus latencies in the operating system and driver. • One way to improve the accuracies is to strike the timestamps in the network driver. • At one time (SunOS) Van Jacobsen modified the input driver to strike the timestamp in the interrupt routine. This feature might not have survived the versions since then. • The output driver is not so easily modified, since the daemon ordinarily does not see the buffer once its contents have been sent. • The network itself can degrade the accuracies, especially if asymmetric, as in a token ring. • This may require provisions at the hardware level, as well as changes in the NTP protocol. • The new IEEE standard which addresses local network synchronization may be a useful departure point.

7. Das Buch project • The book Computer Network Time Synchronization is largely complete. • Some of the mathematical material is appropriate for the specification project. • A proposal was submitted via our local Prentice Hall representative who was to submit it to the editorial board, but nothing has been heard after several months and several repeated requests for status. • Plans are in progress to submit to Wiley, which accepts proposals directly, rather than via a representative.

8. Further information • Network Time Protocol (NTP): http://www.ntp.org/ • Current NTP Version 3 and 4 software and documentation • FAQ and links to other sources and interesting places • David L. Mills: http://www.eecis.udel.edu/~mills • Papers, reports and memoranda in PostScript and PDF formats • Briefings in HTML, PostScript, PowerPoint and PDF formats • Collaboration resources hardware, software and documentation • Songs, photo galleries and after-dinner speech scripts • FTP server ftp.udel.edu (pub/ntp directory) • Current NTP Version 3 and 4 software and documentation repository • Collaboration resources repository • Related project descriptions and briefings • See “Current Research Project Descriptions and Briefings” at http://www.eecis.udel.edu/~mills/status.htm