[Ntp] Minutes from IETF 108 NTP WG session

[Dieter Sibold <[e-mail]>]

Dear all,

Thanks to Tal the minutes from the NTP WG session at IETF 108 are 
online.

https://www.ietf.org/proceedings/108/minutes/minutes-108-ntp-00

Dieter


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