* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Tictoc Status Pages

Timing over IP Connection and Transfer of Clock (Active WG)
Int Area: √Čric Vyncke, Suresh Krishnan | 2008-Mar-11 —  

IETF-104 tictoc minutes

Session 2019-03-26 1350-1550: Karlin 3 - Audio stream - tictoc chatroom


minutes-104-tictoc-00 minutes

          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
          - 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
          - 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
          - The plan is to close the TICTOC working group after the items above
          are complete.
          NTP Session
          - 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
          - Four working implementations.
          - Interop test was successful.
          - Several bugs fixed.
          - No significant problems in the NTS draft were found.
          - 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.
          Presenter: Aanchal Malhotra
          - This is the second version of the draft.
          - There was some discussion in a virtual interim, and some in the mailing
          - 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
          - 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
          - Kristof Teichel: not sure delay attacks affect Roughtime. Roughtime
          can detect something is wrong. I do not think there is much more to be
          - 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
          - Aanchal: as I explained on the mailing list there is a bound on the
          - 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)
          - Brief overview of Chronos.
          - Prototype of Chronos was implemented.
          - Evaluation results presented.
          - 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.
          - Authors cannot present due to a scheduling conflict.
          - Initial YANG doctor review done.
          - We will need another revision before WG last call.
          - 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
            - 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
            - Daniel: a quick review of suggest-refid, it does not comply to RFC
            - 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
            - 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.

Generated from PyHt script /wg/tictoc/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -