Minutes IETF104: ntp
minutes-104-ntp-00

===============================
NTP / TICTOC Joint Session
IETF 104 - Prague
Tuesday, March 26, 2019
13:50-15:50 (UTC+01:00)
Meeting Minutes
===============================

NTP WG chairs: Karen O'Donoghue, Dieter Sibold
TICTOC WG chairs: Karen O'Donoghue

Meeting minutes: Tal Mizrahi

Chair Slides
------------
Presenter: Karen O'Donoghue
Slides:
https://datatracker.ietf.org/meeting/104/materials/slides-104-ntp-ntp-wg-chair-slides-00

Summary:
- Note well was presented.
- The agenda for the current session was presented.
- The content is summarized below for each of the working groups.

==============
TICTOC Session
==============

Summary:
- YANG data model is in the editor queue.
- IEEE 1588 enterprise profile - ready for submission to the IESG.
- Suresh: we are trying to formalize the process with the IEEE regarding IETF
documents pertaining to IEEE standards that are not necessarily available. -
The plan is to close the TICTOC working group after the items above are
complete.

===========
NTP Session
===========

Summary:
- NTP BCP is currently under discussion in the IESG.
- Suresh: currently not enoug votes to approve the BCP. There is an outstanding
DISCUSS. - Denis Reilly: we have internally agreed about some changes in the
document that may be able to address the outstanding DISCUSS. - Karen: please
do that, and submit an updated document. - Suresh: we have been disucssing it
in the IESG. Denis - thank you for pushing this. Will try to get it discussed
on the next IESG telechat. - Control messages protocol draft: updating some of
the NTPv4 functionality that has been left out of the original RFC 5905. -
Guidelines for defining packet timestamps: ready for submission to the IESG. We
just need to get it processed. - NTS for NTP:
    - Dieter: there is some new content that we are working on.
    - Daniel Franke: we will have two minor clarifications in NTS following the
    hackathon.

Hackathon Report
----------------
Presenter: Christer Weinigel

Presentation:
https://datatracker.ietf.org/meeting/104/materials/slides-104-ntp-ietf-hackathon-network-time-security-nts-01

Summary:
- Four working implementations.
- Interop test was successful.
- Several bugs fixed.
- No significant problems in the NTS draft were found.

Discussion:
- NTS has already passed working group last call.
- There will be a clarification about the fact that some implementations had
some problems. - After that NTS is ready to be sent to the IESG. - Daniel
Franke: the NTS spec is clear. We just need a clarification about the fact that
some implementers did not read RFC 7822, and did not implement it correctly.

Roughtime
---------
Presenter: Aanchal Malhotra

Draft:
https://www.ietf.org/archive/id/draft-roughtime-aanchal-01.txt

Presentation:
https://datatracker.ietf.org/meeting/104/materials/slides-104-ntp-roughtime-00

Summary:
- This is the second version of the draft.
- There was some discussion in a virtual interim, and some in the mailing list.

Discussion:
- Tal Mizrahi: important to include threat analysis in the draft. Which threats
roughtime deals with and which ones are not dealt with. Current draft is not
detailed enough in terms of threats. Second major problem in the draft is delay
attacks. The current version of the draft does not deal with delay attacks, and
the scope of the damage that a delay attacker can do. - Aanchal: some of these
comments were on the mailing list and answered. We need to add a threat model.
- Tal: and regarding delay attacks? It is not only a threat model. It is a
matter of adding something to the mechanism. We saw examples on the mailing
list of how a delay attacker can completely compromise Roughtime. - Aanchal: we
may not be on the same page. - Tal: plese reply on the mailing list, as I have
not seen a response from you to the delay attack issue. - Aanchal: I did
respond on the mailing list to delay attacks. - Daniel Franke: regarding policy
- need mechanism for getting trusted lists. We do not want layer 8 policy.
Second comment: I hope to see a call for adoption. - Aanchal: regarding first
comment - I just mentioned it since it was discussed on the interim, but this
is not too important for the draft. - Thomas Peterson: I would like to
contribute, but Github is not updated. Please use Github issues, and update
Github. - Watson Ladd: I am a coauthor. Regarding policy, it is not a question
of policy, but we want one place where reports of malfeasance discussed. - Leif
Johansson: I also think we need a threat analysis. There are already other
mechanisms for securing time: multiple servers. We need to talk about the uses
of secure time, and based on that to define mechanisms. - Kristof Teichel: not
sure delay attacks affect Roughtime. Roughtime can detect something is wrong. I
do not think there is much more to be done. - Marcus Dansarie: I like the
draft. Timescale: the draft suggests TAI. It is generally recommended to use
UTC. A protocol that synchronizes needs to tell the user the time of day. Trust
anchoring is something we need to talk about. Aanchal: the draft says the
servers should use a common source of time such as GPS. - Jose: what is the
precision? - Thomas: microseconds. - Daniel: Kristof's comment about delay
attacks are not correct. The impact of a delay attack is that the longer the
adversay delays the message, the more the timestamp is off. There is no way for
the client to distinguish between a slow server and an adversary that delays
the packet. - Aanchal: as I explained on the mailing list there is a bound on
the delay. - Tal: following up on the delay discussion. Simple example: we have
a server that is off by 1 second. We want Roughtime identify that by having the
causality broken. The server can delay the second for 10 seconds before
responding to the client. This would hide the fact that the server's time is
off, causing the client's retreived time to be off by roughly 5 seconds. This
would not be identified by Roughtime, since its a positive delay. Roughtime
only detects when there is a negative difference. A specific mechanism should
be added to detect delay attacks. - Aanchal: understood. - Kristof: I don't
understand the example. We are talking about a request-response scheme, so the
client can detect that the round trip took a long time, and this would raise a
flag. So there is no issue. - Tal: what you described is exactly the solution
that is currently missing in the draft. Having the client measure the round
trip time and bound it by a specific value, Roughtime could provide an accuracy
on the order of the maximal round trip time. This is currently missing in the
draft. - Kristof: that was obvious to me. If it is not in the draft it needs to
be added. - Watson: I would appreciate if Tal submitted text that describes
this. We are not producing a conventional time protocol, but we are only
guaranteeing that time is within a certain bound. We are interested in
something on the order of minutes of accuracy or seconds of accuracy. - Leif:
the threat model currently does not include the operating system clock - this
should be in the draft. Another issue is that you can actually spoof GPS, so
that is also a threat to think about. - Karen: another revision before a call
for adoption? - Stewart: we need a more conventional description of the
protocol. - Karen: we will continue discussion on the mailing list, and do a
call for adoption.

A Secure Selection and Filtering Mechanism for NTP
--------------------------------------------------
Presenter: Neta Schiff (remote)

Draft:
https://datatracker.ietf.org/doc/draft-schiff-ntp-chronos

Presentation:
https://datatracker.ietf.org/meeting/104/materials/slides-104-ntp-a-secure-selection-and-filtering-mechanism-for-the-network-time-protocol-version-4-01

Summary:
- Brief overview of Chronos.
- Prototype of Chronos was implemented.
- Evaluation results presented.

Discussion:
- Jose Igancio Alvarez-Hamelin: I would like to ask about the conditions of the
experiment, about the slow shifting experiment. - Neta: by slowly shifting the
time, conventional NTP was affected, but Chronos was not affected. Only
preliminary results. - Heiko Gerstung: how many servers did you use in your
experiment? - Neta: NTP uses 4 servers. Chronos - chose 4 out of 12 servers. -
Karen: we need more feedback on the draft.

A YANG Data Model for NTP
-------------------------
No presentation.

Draft:
https://datatracker.ietf.org/doc/html/draft-ietf-ntp-yang-data-model

Discussion:
- Authors cannot present due to a scheduling conflict.
- Initial YANG doctor review done.
- We will need another revision before WG last call.

AOB
---
- Data minimization: new version submitted last night.
  - Watson: does not make sense to object to a draft because future work may
  change it. - Harlan: was that last commend directed toward me? - Watson: yes.
  - Harlan: how do you make your decisions about how to standardize something,
  or implement it first? - Watson: one single implementation should not have
  the previlige to determine how stuff works. There is no conflict between
  having the minimization draft and possibly changing it in the future. -
  Harlan: you have your knowledge and I have mine. - Aanchal: you can always
  update the draft later. - Kristof: the only feedback was to change SHOULD
  into MAY, and that would not change much. We can just skip this discussion. -
  Harlan: I have technical objections to the proposed draft. SHOULD is too
  strong here. - Karen: the way to deal with this is to summarize the emails
  into a consensus call. - Daniel: these objections are not new. There seems to
  be a clear consensus. The objection is based on potential new use cases, and
  if we want clients to implement some of these use cases in the future, it
  would be best to use an extension field. - Karen: we need to ask a clear
  question, and ask a group of people to respond to it. - Daniel: data
  minimization is a normative reference for NTS, so we need to be quick in our
  decision. - Suresh: Harlan, there is a reason for SHOULD. You do not have to
  follow it. It is not a MUST. - Harlan: my concern is that the document does
  not even mention the other cases. Zeroing these fields out blocks these use
  cases in the future. We do not want to use the argument that a standard
  should come before the implementation. - Karen: it is a normative refernce
  for NTS. - Daniel: neither the code nor the standard exist.

- NTP Interleaved Modes:
  - Mirsolav: there was one remaining issue. Whether the servers could use the
  same pair of timestamps multiple times. I sent an email, and we discussed
  this in previous meetings. It is not tolerant to errors. We just need to
  update the document and submit.

- On implementing time:
  - Aanchal: the draft has not been updated since last IETF meeting.
  - Karen: do you anticipate more work on it?
  - Aanchal: yes.

- Additional Extension Field Proposals:
  - Karen: Harlan submitted a few drafts yesterday. Harlan - please summarize.
  - Harlan: mainly language clean ups. Ref ID updates: the not-you, and the
  IPv6 REF ID. Main changes: shorter abstract, references to github, a bit of
  clean up. - Karen: draft-ietf-ntp-refid-updates: it is in working group last
  call, and there were a lot of issues. Please read and comment on the list. -
  Karen: extension field draft was declared as a dead WG document. There will
  have to be a good reason to come back to it. - Harlan: understood. I am
  significantly revising it. - Karen: do the current proposals conflict with
  RFC 7822? - Harlan: the current proposals are compatible with RFC 7822. No
  conflict. - Daniel: a quick review of suggest-refid, it does not comply to
  RFC 7822. - Harlan: it can be padded to comply to RFC 7822. - Karen: we are
  open to extension fields if they are compatible to RFC 7822. - Harlan: they
  are compatible. - Harlan: extended information should go to WG adoption call.
  Revised following some comments. - Harlan: I-DO extension field: cleaned it
  out a bit. Content is much the same. Please consider WG adoption. - Harlan:
  last-ef: should also go to WG adoption. - Karen: looks like four proposals
  for new extension field. We will do a WG adoption call for these. - Karen:
  another proposal was regarding the leap smear. - Harlan: helpful for servers
  that perform leap smearing. - Karen: any additional changes needed? - Harlan:
  no. Ready for adoption call. - Karen: during WG adoption calls, please read
  the document, and comment about the document itself. - Kristof: what if
  people decide to use TAI instead of UTC? - Harlan: the purpose is to know
  that someone is following a server that is currently using a leap smear. The
  main purpose of the REF ID is loop detection. If you use TAI, you lose loop
  detection. - Daniel: you are making a good argument against overloading
  semantics onto the REF ID. - Kristof: I agree. - Watson: with NTS, we do not
  need to worry about packet size limitations. - Daniel: agree with Watson.
  Negotiation can be done with NTS. - Harlan: if you do not want to use leap
  smear, don't. Just want to make sure that people who use leap smear can use
  it. - Karen: congrats to Aanchal on the new RFC. - Karen: we will try to
  schedule a few interims.

Adjourned at 15:20.