Joint NTP/TICTOC WG Meetings IETF 102 - Montreal Fairmont The Queen Elizabeth Location: Notre Dame Date: Wednesday, July 18, 2018, 09:30 - 12:00 EDT (13:30 - 16:00 UTC) Chairs: Karen O'Donoghue, Dieter Sibold, Yaakov Stein AD: Suresh Krishnan Presentation materials: https://datatracker.ietf.org/meeting/102/session/ntp https://datatracker.ietf.org/meeting/102/session/tictoc =============================================================================== (remote participation via meetecho) Note taker: Tal Mizrahi Jabber: Karen CHAIR SLIDES ------------ Presenter: Karen O'Donoghue Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-ntp-chair-slides- agenda-and-extra-bits-00 Summary: - Karen presented the note well. - TICTOC WG Status - Publication of the 1588 YANG model is requested ============== TICTOC Agenda: ============== Enterprise Profile for the Precision Time Protocol With Mixed Multicast ----------------------------------------------------------------------- and Unicast Messages (D. Arnold, 5 min) https://tools.ietf.org/html/draft-ietf-tictoc-ptp-enterprise-profile Presenter: Doug Arnold Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-tictoc-ptp- enterprise-profile-wglc-comments-00 Summary: - There were a few comments on WG last call. Working on resolving them. Discussion: - Doug: updated document can be uploaded within a couple of weeks. - Karen: there is consensus to move forward. Synchronizing Internet Clocks (Alvarez-Hamelin, 10 min) ------------------------------------------------------- https://datatracker.ietf.org/doc/html/draft-alavarez-hamelin-tictoc-sic Presenter: Jose Ignacio Alvarex-Hamelin Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-tictoc- synchronizing-internet-clock-frequency-protocol-00 Discussion: - Karen: this was presented in the previous IETF meeting. Question to the working group: what do we want to do with this proposal given that the intention is to close the TICTOC working group soon. - No responses to the question. - Karen: currently there is no consensus to adopt this work. Suggest to build more momentum around it, and try to find collaborators. ============== NTP WG Agenda: ============== NTP WG status (Chairs, 5 min) ----------------------------- https://datatracker.ietf.org/doc/html/draft-ietf-ntp-mac https://datatracker.ietf.org/doc/html/draft-ietf-ntp-data-minimization - The draft 'draft-ietf-ntp-mac-04 ' has been sent for publication - The data minimization draft has been updated. There are some implementation experience. The plan is to submit this for WG last call. Guidelines for Defining Packet Timestamps (Tal Mizrahi, 10 min) --------------------------------------------------------------- https://datatracker.ietf.org/doc/html/draft-ietf-ntp-packet-timestamps Presenter: Tal Mizrahi Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-ntp-packet- timestamp-formats-00 Summary: - Authors feel ready for WG last call. Discussion: - Daniel Franke: the draft should include a recommended timestamp format that can unambiguously represent the time during leap seconds. The draft does not address leap seconds. - Tal: there is a subsection about leap seconds in the draft. The PTP format, which is one of the recommended formats, is not affected by leap seconds. It is a question to the working group whether we want to add another recommended timestamp format to the draft. - Karen: we will take it to the mailing list. Network Time Protocol Best Current Practices (Denis Reilly, 5 min) ------------------------------------------------------------------ https://datatracker.ietf.org/doc/html/draft-ietf-ntp-bcp Presenter: Denis Reilly Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-ntp-ntp-bcp- status-00 Summary: - The draft is currently under IESG review. One of the comments was that the draft relies heavily on NTPd. Currently working on moving implementation-specific content to an appendix. The updated draft is on GitHub. Discussion: - Karen: please submit an updated draft as soon as possible. - Denis: updated document will be submitted in the next few days. - Daniel Franke: the IESG telechats are bi-weekly. It is possible to follow the telechat. Control Messages Protocol for Use with NTPv4 (Haberman, 10 min) --------------------------------------------------------------- https://datatracker.ietf.org/doc/html/draft-ietf-ntp-mode-6-cmds Presenter: Brian Haberman. No slides presented. Summary: - Brian: submitted an updated draft. Up to the chairs what the next step is. - Karen: I believe all the issues were resolved. - Brian: there just a few clarifications. Nothing major. - Karen: is there any problem with publishing this? Discussion: - Ask Hansen: not sure it makes sense to publish this if this is implementation specific. - Karen: this is published as ‘informational’. The content was part of RFC 1305 and was not moved to RFC5905. This is a sort of a housekeeping thing. - Brian: the draft states that it is not encourage to be implemented - Daniel Franke: I believe this started as ‘historic’ and was changed to ‘informational’. Maybe ‘historic’ is more appropriate. - Harlan Stenn: mode 6 should be very straightforward for someone to implement. It is not historic. It should be included in an NTP implementation. - Brian: Okay. - Karen: please hum if you think it should be ‘informational’ vs. ‘historic’. - Humming seems balanced. - Denis Reilly: there is some content about control messages in the BCP document. In my opinion it was left out of NTPv4 as an oversight. Should control messages be included in NTPv5? - Karen: too early to answer that. - Brian: the status of the control document is not related to the BCP. - Denis: maybe it should be ‘historic’. - Brian: it depends on how people view it. - Karen: let’s take it to the mailing list. Maybe ‘informational’ makes more sense. - Brian: some implementers support it for legacy reasons, some do not support it at all. - Daniel: are there NTP servers that are not based on the reference implementation and do support it? - Harlan: the big implementations support it. - Brian: some implementations do not support it. - Harlan: they are not full NTP implementations. - Karen: Brian, please ask on the list whether this should be historic or informational, and also ask about implementations that actually use this. A YANG Data Model for NTP (Chairs, 5 min) ----------------------------------------- https://datatracker.ietf.org/doc/html/draft-ietf-ntp-yang-data-model No slides presented. Summary: - Karen: The draft is ready. The next step is to request a YANG doctor review. Target a WGLC in August prior to the next meeting. NTP Interleaved Modes (Miroslav Lichvar, 5 min) ----------------------------------------------- https://datatracker.ietf.org/doc/html/draft-ietf-ntp-interleaved-modes Presenter: Miroslav Lichvar No slides presented. Summary: - There were some updates in the draft. - No objections to the draft on the mailing list. - Please let the authors know if there are comments. Discussion: - Daniel: the proposal does not work with NATs. The solution is to use an extension field that includes a session ID, and the interleaved timestamps. - Miroslav: this has been used for quite some time in the reference implementation, and does not break anything. - Harlan: interleaved mode was designed for symmetric mode. The server is not expected to remember state. - Miroslav: this draft also defines a client server model. Report from NTS's Hackathon session (Chairs, 5 min) --------------------------------------------------- Presenter: Karen Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-tictoc-ptp- enterprise-profile-wglc-comments-00 Discussion: - Karen: considering future interim activity in terms of public testing and implementation. NTS for NTP (draft -12) (Franke, 10 min) ---------------------------------------- https://datatracker.ietf.org/doc/html/draft-ietf-ntp-using-nts-for-ntp Presenter: Daniel Franke Slides: Slides skipped - All authors of the draft agree Discussion: - Joint discussion with the suggested improvements above. NTS for NTP (suggested improvements) (10 min) ------------------------------------------------- https://datatracker.ietf.org/doc/html/draft-dansarie-nts-00 Presenter: Marcus Densarie Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-ntp-suggested- improvements-to-nts-for-ntp-00 Discussion - Daniel: I have a few comments, mostly positive. I will respond to this proposal in my presentation. - Joint discussion with the suggested improvements after Daniels contribution. NTS for NTP (draft -12) (Franke, 10 min) ---------------------------------------- https://datatracker.ietf.org/doc/html/draft-ietf-ntp-using-nts-for-ntp Presenter: Daniel Franke Slides: Slides skipped Summary - Change in requirement level of the Unique Identifier: yes - Change in the NTS Authenticator and Encrypted Extension Fields: yes - Addition of “NTS Server Negotiation” NTS record: yes, but in a somewhat different format - TLS 1.3 is a bit premature to be used by NTS Discussion: - Joint discussion with the suggested improvements above. - Doug Arnold: There is a lot of frustration in the industry about the fact that there is no standard security solution. It would be better to have a solution that solves most of the problems rather than to have no solution. - Karen: how many people have read the draft. - A few hands raised. - Daniel: I have a few comments, mostly positive. I will respond to this proposal in my presentation. - Danny Meyer: what about DTLS. - Marcus: this was removed. - Daniel: TLS 1.3 is a bit premature to be used by NTS. - Martin Levy: I disagree. There is some pretty good support for TLS 1.3. - Leif Johansson: the choice between 1.2 and 1.3 may just be a configuration issue. It is not necessarily something that should be nailed here. There may be an issue with long-lasting TLS connections, which is solved by TLS 1.3. - Daniel: Privacy was a explicit design goal for NTS. The handling of the session cookie has been copied from what TLS 1.3. - Brian Haberman: TLS 1.3 is already implemented. There is no reason for having compatibility issues here. - Jean—Philippe Ouellet: the client ist not unlinkable to the server. This should be reflected in the Privacy Considerations - Daniel: please send text. - Jean—Philippe Ouellet: question to implementers: it is possible to perform key exchanges more often. I wonder about the appropriate key exchange frequency. Open question to the WG. - Ask Hansen: it would be best to separate the key exchange from NTP server. - Daniel: it would be helpful if the suggested improvements could be sent using pull requests on GitHub. - Karen: Marcus, please submit pull requests, and work with Daniel on this. - Karen: draft 12 represents the lessons learned from the Hackathon. A Secure Selection and Filtering Mechanism for the NTPv4 (Schiff, 15 min) ------------------------------------------------------------------------- https://datatracker.ietf.org/doc/html/draft-schiff-ntp-chronos Presenter: Neta Schiff Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-ntp-preventing- network-time-travel-with-chronos-00 Discussion: - Daniel Franke: assumption that everything is authenticated, e.g., by NTS. Existing algorithms already have upper bound on offset by malicious attacker. How does Chronos improve the bound in the MITM case? - Neta: we are suggesting to add a layer to NTP that improves the level of protection. Sharon Goldberg demonstrated that big shifts in time are possible today. - Daniel: when everything is correctly implemented you have an upper bound on the clock shift. Sharon's papers addressed implementation errors. If there is a majority of honest servers than everything should work today. - Doug Arnold: implementation errors are very common. Other applications are running besides NTP. We have to make sure that we are not disrupting other protocols. NTP has a lot of redundancy to protect for such MITM attacks. - Yaakov Stein: tradeoff between security and timing accuracy – NTP has mechanisms to improve the accuracy. If we are not careful we may be losing some of these mechanisms. - Neta: That is right. We need to look into how to keep a high level of accuracy and improve the security at the same time. - Yaakov Stein: you do not estimating any particular server over a long enough time in order to get the real minimum of the delay. Did you do a experiment to measure the timing performance in the absense of attackers? - Neta: we expect the protocol to be sub-optimal regarding accuracy. We present this work and would like to combine it with the current NTP in order to preserve NTP's timing performance on the one side and increase security on the other side. - Ignacio: do you always use the same server if all works well? - Neta: this is for future work. We plan to use servers depending on weight and reputation for longer time. - Harlan: please consider the current reference implementation’s pool directive, which is just as good in terms of using multiple servers. The pool offers servers based on reputation, and the algorithm chooses servers dynamically based on their performance. - Ask Hansen: this work is a lot of fun. Happy to help. Man in the middle is not the only attack. Malfunctioning server is more common. Chronos can help there. - Doug: this work is very interesting. In terms of accuracy it may be worthwhile to average multiple servers to address asymmetry. - Yaakov: in 1588 where we need high accuracy it can take up to one hour for the algorithm to stabilize. In order to be accurate you need ‘one big PLL’. Need to discuss this further. - Jean-Philippe: do you have thoughts on bootstrapping the list of servers you are using. - Neta: we are working on it. REFIDs (Chairs, 5 min) ---------------------- https://datatracker.ietf.org/doc/html/draft-ietf-ntp-refid-updates Open discussion. Chair slides. - Karen: There are three proposed REFIDs: Not-You, IPv6, Leap Smear. - Karen: should we separate the first two from the third. - Karen: question for the WG: Should we separate the first two out from the third? - Harlan: what happened to suggested REFID? - Philip Prindeville: Regarding IPv6: I suggest to fill the REFID with all zeros, and use an extension field. The Leap Smear refid is not necessary. It tries to solve a problem which has to be solved by the hosts. NTP only has to provide accurate information about the leap second event. - Daniel: IPv6 REFID should be put into an extension field. Leap smear – need to follow along. - Ask Hansen: would like to have the leap smear information in the packet. Not sure if it should go into the REFID. - Harlan: if we put the leap smear information in an extension field it becomes invisible. - Philip: we can make this a required field. - Harlan: you cannot fix machines that are already out there. - Dieter: regarding leap smear, its purpose is to avoid time leaps. This is a workaround and not good protocol design. - Doug: it takes a long time to update equipment. When you are running a leap smear you are not synchronized to a timescale. In that case you have to identify that you are not currently synchronized. - Karen: is there anyone who is opposed to splitting into two documents? - Karen: no clear respond. Decision goes to the mailing list NTP Correction Field (Lichvar, 5 min) ------------------------------------- https://datatracker.ietf.org/doc/html/draft-mlichvar-ntp-correction-field Presenter: Miroslav Lichvar Slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-ntp-ntp- correction-field-01 Discussion: - Philip: what is the point of the checksum complement. - Tal: the checksum complement enables hardware implementations. The complement compensates for any changes in the extension field, leaving the existing UDP checksum correct. 7822bis (Chairs, 10 min) ------------------------ Network Time Protocol Version 4 Extension Fields https://datatracker.ietf.org/doc/html/draft-stenn-ntp-extension-fields Additional Extension Field Proposals (Chairs, 10 min) https://datatracker.ietf.org/doc/draft-stenn-ntp-extended-information/ https://datatracker.ietf.org/doc/draft-stenn-ntp-i-do/ https://datatracker.ietf.org/doc/draft-stenn-ntp-mac-last-ef/ https://datatracker.ietf.org/doc/draft-stenn-ntp-suggest-refid/ No slides presented. Discussion: - Philip: I believe this draft tries to address too many issues that may be addressed elsewhere. - Harlan: I beg to differ. Let’s discuss offline. - Karen: the next step will be a call for working group adoption. - Karen: Still need to find another editor for this document. - Karen: the rest of the extension field drafts – either need to be 7822 compliant, or we can delay them until we know how the 7822bis is going. - Harlan: I can change the language in a way that will avoid this problem. - Karen: make sure they are compatible with the current RFC. - Philip: what is the current consensus status on 7822bis? - Karen: there is a fair amount of opposition. Will be happy if you can take a look and help with it. - Philip: I will take a look at the document, and try to see how to move forward. AOB (5 min) ----------- - Harlan: I submitted three proposals that may allow to improve NTS. - Karen: we need more written detail. - Harlan: right. - Karen: next steps for the working group. Need interop activity for NTS – will follow up on that. We will schedule two virtual interims before the next IETF meeting. Wrap Up (10 min) ---------------- - Karen: Two interim meetings between IETF 102 and IETF 103 in Bangkok are planned