Minutes interim-2019-ntp-03: Tue 15:30
minutes-interim-2019-ntp-03-201909101530-00

===============================
NTP Virtual Interim
September 10th, 2019
15:30 UTC
Meeting Minutes
===============================

Participants:
=============
Karen O'Donoghue
Dieter Sibold
Daniel Franke
Tal Mizrahi
Marcus Dansarie
Steve Sullivan
Watson Ladd
Denis Reilly
Kristof Teichel
Marcus Dansarie
Danny Mayer
Miroslav Lichvar
Rich Salz

Chairs: Karen O'Donoghue, Dieter Sibold
Minutes: Tal Mizrahi

Chair Slides
============
Presenter: Karen O'Donoghue

- Note well was presented.
- The agenda for the current session was presented.
- Discussion about call for adoptions will take most of the time.
- Some discussion about NTPv5 is expected.

WG Document Status:
===================
- Guidelines for timestamps and NTS drafts are ready to be submitted to the
IESG, and will be submitted to the IESG in the next 24 hours. - The YANG model
is ready for WG LC. - Data Minimization has been through WG LC, and there are
some comments. Will be moving this draft to WG consensus, and then send it to
the IESG.

Interleave Mode Draft
=====================
  - Miroslav: it passed last call.
  - Daniel: I was the only one who objected.
  - Karen: Daniel's objection is noted, and we are moving on.

Port randomization Draft
========================
  - Karen: There was quite a bit of discussion. Does anyone have anything to
  comment? - Danny: the draft does not do anything for the protocol itself in
  terms of securing it. If we want this document we should actually improve
  security, and not just write a BCP. - Daniel: Watson had the most notable
  comments here. Even when we use NTS the port randomization is an issue. -
  Watson: right, annoying from a DoS perspective. - Danny: can you explain? -
  Watson: you cannot have a firewall that limits the number of responses. It is
  difficult at the network layer. - Danny: that needs to be laid out as an
  issue. - Watson: can NTS clients randomize the port? - Daniel: yes, NTS
  clients can randomize. - Danny: in NTPd, the source port is used for
  filtering and reconciliation. - Daniel: there is nothing in the draft that
  says you need a random port for every request you generate. - Danny: we need
  to clarify that in the draft, and make sure we know what we can and cannot
  do. - Karen: two question here - what do we think about the latest draft, and
  whether we want it to be adopted. Danny - do you think it should be adopted?
  - Danny: my opinion is it should not be about port randomization, but rather
  more generally about security. - Karen: so what are the other pieces? -
  Danny: Miroslav brought this up - the timestamp should be a local thing, and
  when you get a response you should match it to the timestamp. - Daniel: not
  in the minimization draft. - Danny: but it should be there. - Karen: we are
  wrapping up a few loose ends with NTPv4, and getting NTS published. Maybe
  this should be just a loose end to tie before we move on to NTPv5. Do you
  think this should wait for NTPv5? - Danny: not sure. We need to look closely
  at what we are doing. I have not looked at the latest draft. - Karen: we just
  published the NTPv4 BCP. The combination of the BCP and port randomization
  could work. What do people think about this? - Denis: I think this document
  should be adopted. Some issues can be handled in NTPv5, but it will take a
  while. As it stand, this document is important. - Karen: from a WG
  perspective, we need to work on what people are willing to make contributions
  on. In NTS for example - it does not solve all the problems, but it did serve
  a client. At this point I do not see the willingness to do all we should be
  doing in this context. - Denis: so if there are people who are willing to
  work on this document, we should take advantage of that now. - Karen: right.
  - Watson: if the goal is mitigate on-path attackers, then the port
  randomization draft does not seem like a major change in what is already
  done, so I think we should move forward with it. - Danny: let's notice that
  it is very easy to find out what the port is. You will end up with just a few
  port numbers. It is pretty easy to figure out which port is used. - Watson:
  but you bind the port to the server. Any other port will not produce a
  response. - Danny: only if you close the port. - Daniel: Watson is right. A
  port scan will not tell you what source port the client is using. - Danny:
  you can query the client to find out the port. - Daniel: the client is not
  going to get the packet. - Miroslav: it will not even reach the client if it
  is not from the right IP address. The draft should recommend using POSIX
  system. This will prevent getting responses from wrong addresses and ports. -
  Karen: the consensus on the mailing list was to adopt. From a WG perspective
  we are going to adopt it, and continue to improve it. We will move the draft
  status to accepted, and ask for more reviews and comments. - Karen: our
  recent calls for WG adoption - Dieter and I have looked at the emails.

Chronons Draft
==============
    - Karen: we have WG consensus to adopt it as an experimental draft. Any
    comments about that? - No comments.

Roughtime Draft
===============
    - Karen: we have WG consensus to adopt. There are some comments on the list.
    - Daniel: I am in favor of adopting. People have a misconception about what
    the draft does. It does not even set the local clock. I originally thought
    it was not in our charter. It needs to be adopted. - Karen: we need to
    re-charter. - Daniel: it is not just a formal issue of what is in our
    charter. I believe the NTP scope and the Roughtime scope are distinct. -
    Karen: we will adopt it and move forward.

Extension Field Drafts
======================
- Karen: at this point there is no WG concensus to adopt these drafts. Harlan
is not on the call. The documents are not adopted.

NTPv5 Discussion:
=================
- Karen: Miroslav created a page with a list of issues for NTPv5. A link to the
page was sent to the mailing list. - Daniel: I added a few issues to the Wiki.
- Karen: you may want to add your name to the issues as you add them. NTPv5 is
not a clean slate protocol. Somewhere between minor tweaks and clean slate. -
Daniel: I think we have a clean slate, other than considerations given existing
implementations. - Karen: more contribution would be welcome. - Tal: what is
the scope here? Resolving open issues / adding new features? - Karen: the scope
is what we are looking to discuss in the Wiki. - Danny: one of the biggest
problem is the MAC, which does not have a length field. - Watson: one could
imagine adding an extension with a length. - Danny: right, that was proposed,
along with the Last-EF. - Daniel: right, but we are looking for the least
clumsy thing we can think of. - Danny: right. With an extension field you can
have multiple MACs. There are other things that Miroslave listed. - Karen: we
started the Wiki, and between now and the next meeting people can review and
suggest items, and then we can discuss them. We seem to be gaining momentum for
NTPv5. First we need to think what we want to do here. Another way to go is
that someone who is interesteed can start to actually work on it. We also want
to move NTP to a full standard. - Daniel: I do not agree. If we move forward
with a new protocol, it is an argument against moving to a full standard. -
Karen: right. When we get to a point where we understand whether it is a
significant change we can reconsider this question. - Watson: RFC5905 discusses
one synchronization algorithm. It is useful to have an example of a
synchronization algorithm. - Miroslav: some implementations use a completely
different algorithm. It would be better to specify general requirements. -
Karen: I originally wanted to separate the protocol from the algorithm. The
algorithm can be informational. We can use different algorithms. Actually it
was the case at one point. - Danny: the protocol and algorithm are intertwined.
It is not trivial to pull them apart. - Karen: it will not be easy, but it is
done for example in IEEE 1588. - Danny: it is not that simple. - Karen: but
needs to be done. - Daniel: I would like to see an example of two algorithms
that work well, but blow up when both operate in the same network. I can see it
in TCP, but not in NTP. - Watson: if estimate the first derivative, that work
well, but if you do that twice in a row it becomes very unstable. - Danny: I
agree, but we will not be able to resolve it here. It is a very complicated
discussion. - Karen: we need a few people who are interested to work on the
text. The spec says a few things that nobody implements and still
implementation work well. - Karen: thanks Miroslav for the Wiki.

AOB
===
- Kristof: when we changed the scope of NTS, we suggested to document the
design guidelines. People who implement basically deal with the same problems.
I wonder whether this should be compiled into an internet draft. - Karen: any
document that pulls together some of the issues we had would potentially be
useful. - Miroslav: could this be used for symmetric mode? - Kristof: no. More
along the lines of broadcast, and also using NTS a bit similar to NTP MD5. -
Danny: I would recommend an informational document. - Kristof: so I will write
something up. - Karen: send it to the list and see what feedback you get. -
Karen: any other AOB?

Next Meeting
============
The week of October 14th.

Adjourned at 16:30 UTC.