[Ntp] IETF 104, Minutes of NTP/TICTOC WG session

[Dieter Sibold <[e-mail]>]

Dear all,

I've just uploaded the minutes from the NTP/TICTOC WG session during IETF 104. Thanks to Tal who provided the minutes.

https://datatracker.ietf.org/meeting/104/materials/minutes-104-ntp-00.txt


Dieter


----------------------------

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