[Ntp] Minutes from the NTP/TICTOC WG session at IETF 103

[[e-mail]]

Hi all

the address of the minutes from the NTP/TICTOC WG session in Montreal:
https://datatracker.ietf.org/doc/minutes-102-ntp/

Please find the minutes also below:


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 is not 
      affected by 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