Minutes IETF108: ntp
|Meeting Minutes||Network Time Protocols (ntp) WG|
|Title||Minutes IETF108: ntp|
|Other versions||plain text|
=============================== NTP Session - IETF 108 July 31, 2020 11:00 UTC Meeting Minutes =============================== Chairs: Karen O'Donoghue, Dieter Sibold Minutes: Tal Mizrahi Meeting material: https://datatracker.ietf.org/meeting/108/proceedings#ntp Participants: ============= [This list is for informative purposes, and some people may be missing. Bluesheets will be published separately.] Karen O'Donoghue Dieter Sibold Tal Mizrahi Neta Schiff Miroslav Lichvar Martin Langer Mark Baushke Marco Davids Erik Kline Xiaolan Wan Denis Reilly Leif Johansson Warren Kumari Rich Salz Jose Alvarez-Hamelin Dhruv Dhody Harlan Stenn Eric Orth Kristof Teichel Kimura Yamato Yali Wang Doug Arnold Kenneth Murchison Ragnar Sundblad Robert Story Simon Vera-Schockner Hiroyuki Goto Introduction ============ Slides: https://www.ietf.org/proceedings/108/slides/slides-108-ntp-ntp-chair-slides-00 Presenter: Karen O'Donoghue Summary: - Karen presented the note well. - Karen presented a brief introduction to using Meetecho. - The agenda for this session was presented. Document status: - Two documents in the RFC editor's queue: the timestamp format draft, and the NTS draft. There is currently a delay in the editor queue. - Mode 6 draft: Karen will take it offline with Erik to proceed with the shepherd writeup and the AD review. - YANG data model draft: the shepherd writeup is in progress. - Port randomization document: has been updated, and the issues have hopefully been adressed. It seems to be ready for working group last call, since there was no further discussion. Karen and Dieter will proceed with WG last call. - Alternative NTP port draft: it is still an individual draft. - Miroslav: I believe we said in the last meeting that the draft is ready for an adoption call. No changes since then. - Roughtime: we discussed it in the last interim, and it has not been updated since then. - Chronos update - to be presented by Tal. Chronos ======= Slides: https://www.ietf.org/proceedings/108/slides/slides-108-ntp-a-secure-selection-and-filtering-mechanism-for-the-network-time-protocol-version-4-00 Presenter: Tal Mizrahi Summary: - The draft has recently been revised so that Chronos is a Watchdog. - Most of the time you use the NTPv4 algorithm, but if Chronos detects a suspected attack, then the client starts using the Chronos algorithm. This allows enjoing the precision of NTPv4 most of the time, and enjoying the security of Chronos when under attack. Discussion: - Karen: who is working on an implementation? - Tal: Neta and the people at the Hebrew university. - Neta: we are working on an implementation, but we would love if other people who are interested in implementing would contact us and we could work together. - Dieter: is the Chronos filtering algorithm identical to NTPv4? - Tal: it is not identical, but a bit similar. It is based on well-established agreement algorithms from the literature, where you ignore the highest third and lowest third of the samples, and then take an average or a median of the remaining samples. - Karen: this version has been around since March. Let's have some feedback from the working group. Tal / Neta - please ask the working group for some feedback on the mailing list. We also need to discuss informational vs. experimental. NTPv5 Modular Architecture ========================== Slides: https://www.ietf.org/proceedings/108/slides/slides-108-ntp-ntpv5-modular-architecture-02 Presenter: Doug Arnold Summary: - This is a proposal to divide NTP into a timing engine and a protocol engine. - This enables cases where there needs to be a dedicated or application-specific timing engine. Discussion: - Miroslav: if we define a timing engine - it seems like this is a recommended design of a server and client, but not mandatory to implement. Is it going to be in a separate document? - Doug: if there is going to be more than one timing engine it would make sense to have it in a separate document. There would be an architecture document that describes the concept and interfaces, and the timing engine would be in a different document. - Karen: chair hat off, there is no specific plan which documents will be, as we are just in a discussion phase. We have not updated the charter yet, and do not have consensus yet. - Doug: the motivation for all of this is that it is already being done in NTPv4, even though it does not comply to the standard NTP. Different implementations use different algorithms than RFC 5905. It seems like this is needed. - Karen: some individual drafts along these lines would be helpful. - Dieter: would it make sense to separate the clock control from the timing engine? - Doug: you mean that clock control is a separate entity, and the timing engine just analyzes the NTP messages. - Dieter: right, and sometimes people have different requirements about how often the clock needs to be adjusted. - Doug: it is possible. Note that we do not want too many subsystems, in order to avoid to many combinations, but it can be discussed. - Dieter: the packet structure still contains the timestamps, right? - Doug: right, that is done by the protocol engine. The timestamps come from either the operating system, or from a hardware engine, and can be used by the protocol engine for timestamping. - Mark Baushke: the IEEE 1588 has a better resolution than the NTP timestamp resolution. Do we need a better resolution? - Doug: that is a good point. In IEEE 1588 we did this in order to avoid updates for a long time. However, people like to use NTP in some scenarios or applications, and we may need better resolution than nanoseconds. - Mark: IEEE 1588 typically is implemented in hardware, but still NTP may need a better resolution. - Doug: in PTP (1588) we could not change the timestamp field, so we added the extra precision to the correction field. NTP servers have hardware timestamping, and many of the clients have the hardware that enables hardware-based timestamps. - Jose: if you want to synchronize over the Internet, it would be difficult to reach a sub-microsecond accuracy. If the network is symmetric a microsecond accuracy is possible. I have a proposal on the TICTOC working group for an accurate synchronization protocol. - Doug: right, a high resolution timestamp does not mean you can achieve high accuracy. In small networks with a small number of hops (such as financial networks), you can achieve a high accuracy. - Miroslav: we have a document on the Wiki about NTPv5 requirements. One of the issues is the precision of the timestamps. You are welcome to add comments to the Wiki or mailing list. White rabbit is reaching the resolution that NTP provides, so maybe a better resolution will not be required in the near future. - Doug: it is difficult to reach an accuracy/precision below 1 nanoseocnd. The finance industry are used to NTP, and prefer it over PTP, and at the same time are looking into White Rabbit. It turns out that for trades a nanosecond resolution matters. There may be some applications that will require fine resolution. Hackathon Update ================ Slides: https://www.ietf.org/proceedings/108/slides/slides-108-ntp-ietf-108-hackathon-network-time-security-01 Presenter: Martin Langer Summary: - There was an NTP hackathon last week. - Interop testing of NTS implementations. - All implementations talk to each other. - Some issues with operator filtering (of large NTP packets). Discussion: - Miroslav: about the failures reported about the testing tool - it is not an issue for the current clients, but could be a real problem in the future when NTPv5. Some implementations of servers just assume that it is an NTPv4 client, but servers need to check whether it is NTPv4 or not. - Karen: thanks to Martin Langer, Miroslav Lichvar and Christer Weinigel for being the backbone of the team and pushing this through. NTPv5 Discussion ================ - Karen: we are looking for charter updates, and we would like to start having implementations and drafts. There is a Wiki page that you can update with your suggestions. - Erik Kline: the charter is currently a bit out of date. Suggestions would be welcome for scoping the work, including motivation and suggestions for NTPv5. Karen and I will take a stab at rewriting the charter. - Karen: it looks like people are interested, and there is a question of the scope. AOB === - Karen: we have been trying to hold regular interims. The next one will be at the beginning of September. - Harlan: is there a reference implementations of the YANG data model? - Karen: the authors are not present. We may have an answer in the next few days as part of the shepherd writeup. Adjourned at 12:22 UTC.