Last Modified: 2004-10-28
|
Network Time Protocol BOF Thursday, November 11, 2004, 1300-1500
Chairs: Brian Haberman, brian@innovationslab.net Karen O'Donoghue, karen.odonoghue@navy.mil Minutes taken by Tim Plunkett Intro/Agenda bashing and Goals/Purpose/Charter Intro Karen O'Donoghue started the meeting by going over the planned agenda for the meeting. Karen then described the reason for creating this effort and introduced a draft charter. The intent is to create a new NTP standard that incorporates changes that have been made to NTP since RFC 1305. The plan is to divide NTP into three documents: the NTP protocol, the NTP algorithm, and the NTP MIB. Status of STIME WG, Pat Cain, STIME chair Pat Cain explained how the STIME effort tried to define a security model to be used by NTP and how that effort has not made it out of the IESG. Pat was asked why the STIME standard was being held up by the IESG. He did not know why, but he is hoping that security work will be included in this effort and finally get approved. Someone stated that the IETF web site shows the STIME RFC still in the ID tracker system. Pat suggested that this security part could be placed in an appendix in the new NTP standard until it is known why the STIME RFC never made it out of the IESG. NTP Standardization Issues, Dave Plonka, University of Wisconsin Dave Plonka presented four areas of concern when writing a new NTP standard. The four areas are operations, client implementation, server implementation, and creating the standard. Under operations he mentioned the practice of embedding of IP addresses instead of names and the need of NTP server access control to prevent server abuse. Under Client implementation he discussed the implementation of SNTP in home network equipment. Under server implementation he mentioned the fact that the current NTP standard, RFC 1305, is half research paper and half standard. Under creating a standard he talked about RFC 2030 (Simple NTP version 4) as being a good document structure to use when writing a new NTP standard. The SNTP standard helps to show how the protocol and algorithm parts of NTP can be split into separate documents. NTP Changes Since RFC 1305, David Mills, University of Deleware David Mills gave an update to the status of NTP since it was standardized in RFC 1305. He first gave some current NTP statistics. The NTP servers at USNO and at UDEL typically see 3000 NTP packets per second. NIST estimates that there are 25 million NTP servers available on the Internet. However there is not a known implementation on an IBM mainframe, which is being investigated. Dr. Mills mentioned that the two current specifications are for NTP version 3 (RFC 1305) and SNTP version 4 (RFC 2030). He mentioned that one of the main differences in packet format between NTPv3 and NTPv4 is the use of a MD5 hash so that IPv6 addresses can be used in the ref id field. There have also been one or more optional security fields added as well. As far as the NTP algorithm is concerned, NTPv4 has been modified to allow for faster initialization. NTPv3 was intentionally made to initialize slowly because it was felt that NTP servers on the Internet could not be trusted. However there is a need in more controlled networking environments where faster initialization is needed. The ability to have NTP clients send bursts of up to 8 packets to the NTP servers has been added. These packet bursts are useful when operating over noisy links or in cases where fast initialization is necessary. All computations, except for those involving raw timestamp differences, are performed using double precision math. Ambiguities in the NTPv3 filter algorithm and timestamp calculations have been fixed. The concept of virtual time has been removed from NTPv4. More reference clock drivers have been added. A kiss of death packet has been added that provides useful diagnostic information and a call gap mechanism has been added to detect and suppress NTP packet flooding. Other related changes that have went into effect since RFC 1305 include a nanokernel modification that gives OS kernels nanosecond clock resolution, which replaces the microkernel modification. Linux and FreeBSD both implement the nanokernel modification. An autokey system has been implemented for NTP security. Autokey version 2 is available on the NTP projects web page and will hopefully be added to the new NTP standard. Autokey allows for zero knowledge proofs of identify (computers do not have to know each others keys in order to set up a secure communication). An autoconfigure mode has been added where NTP can use manycast (not anycast) to get a list of potential NTP servers and narrow the list down to the best three. An NTP client would make a DNS query for pool.ntp.org, and the DNS server would return a list of NTP servers that could serve time to that NTP client. Someone involved with DNS security work stated that someone should look at how NTP would operate in a secure DNS environment. Dr. Mills discussed the NTP simulator that can be used to test NTP convergence times in a matter of minutes instead of taking days using real NTP servers working over a network. He mentioned that a set of slides describing NTP can be found at http://www.eec13.udel.edu/~mills/ntp.html. RFC 2030 is still a draft standard because it has not been released by the RFC editors. Dr. Mills said that RFC 2030 is close to what is needed for an NTPv4 protocol standard. Only a few changes are needed. Dr. Mills stated that SNMP is not the complete solution for monitoring NTP performance. He said that SNMP is OK for detecting if NTP is up and running, but is not appropriate for continuous monitoring of NTP performance. Draft Charter Discussion, Brian Haberman, NTP BOF co- chair Brian Haberman started the discussion with the group concerning what should be in the charter for the group. Someone asked if there is other work to be performed beside writing standards for existing implementations. It was mentioned that some work for NTP security may need to be done. Peter Lothberg stated that the group needs to create a future needs document that could be used as a list of ideas for things to be included in NTP later (maybe NTPv5). Someone asked about requirements that needed to be in the new standard, such as restricting SNTP polls to the NTP server to no more often than every 64 seconds. David Mills asked for public feedback on RFC 2030. There was a suggestion that there be a well known unicast address to be used by NTP that cannot be forwarded past routers. Thomas Narten asked that the group come up with a list of what to do and not to do for the new NTP standard. He suggested that the group should be careful about adding new things to the standard that are not already there. Brian Haberman agreed that the first priority should be to document NTP version 4. New things can be added later after the initial standards are done. Dr. Mills mentioned that there are other efforts in the area of time synchronization like IEEE 1588. IEEE 1588 is a time synchronization method developed by the instrumentation community to work in conjunction with specific link technologies including Ethernet. Karen O'Donoghue stated that IEEE 1588 is meeting in December 2004 in order to revise that standard. Karen stated that this group should try to coordinate with IEEE 1588 so that the two methods will work together. A poll was taken and there was consensus that this work needs to proceed as an IETF working group. Work to amend the charter will continue offline on the mailing list. |