Minutes IETF108: ntp
minutes-108-ntp-00

===============================
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.