Minutes IETF104: tictoc
minutes-104-tictoc-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.