NTP Research Opportunities

1
NTP Research Opportunities

• David L. Mills
• University of Delaware
• http//www.eecis.udel.edu/mills
• mailtomills_at_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
  Lamports 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/sta
  tus.htm