Skip to main content

Minutes interim-2021-ntp-01: Tue 11:00
minutes-interim-2021-ntp-01-202106221100-00

Meeting Minutes Network Time Protocols (ntp) WG Snapshot
Title Minutes interim-2021-ntp-01: Tue 11:00
State Active
Other versions markdown
Last updated 2021-07-24

minutes-interim-2021-ntp-01-202106221100-00

NTP Virtual Interim

<pre>June 22nd, 2021 15:00 UTC Meeting Minutes </pre>

Agenda bashing:

  • Agreed to move NTS4PTP discussion before

NTP/TICTOC WG Document Status Review/Update

  • Interleaved modes:

    • IETF LC there was an discussion. Unsure if there is wg discussion. Will be moved to telechat
    • Mirsolav is ok with the document. There have been comments from Daniel.
  • YANG

    • Will be moved to tele chat
  • CMDS

    • Eric will try to understand all comments and then move it to telechat
  • Enterprise TICTOC

    • shepherd writeup will be done by Karen
  • Alternative port:

    • WGLC will end Friday. Please respond
  • The update registries draft

    • Adoption call open. Please respond
  • Cronos:

    • no recent discussion

Roughtime

Presenter: Marcus

  • Watson and Marcus consider the draft with the protocol specification to be ready for last call
  • Marcus: The draft specifying the ecosystem is not ready yet
  • Karen: will do WGLC before next IETF
  • Eric: Are there implementations?
  • Marcus: There are different implementation up to -4 from Watson and Marcus. Apparently some others also
  • Karen: there have been some implementations efforts at the hackathon
  • Karen: maybe efforts during next Hackathon

Discussion on NTS for PTP

NTS for PTP - is this worth doing? Should the NTP WG do it?

Presenter: Doug, Slides

Discussion:

  • Danny Mayer: If GDOI should be considered for PTP should it also be considered for NTS/NTP?
  • Doug: GDOI will be used in power grid certainly.
  • Danny: who is working on GDOI?
  • Doug: IETF; IEC has documents how to use it
  • Karen: GDOI to protect PTP was done in IEEE 1580 WG
  • Danny: asking for a holistic view for NTP and PTP
  • Karen: interesting question: Original NTS documents did consider this. But proved to be difficult to realize.
  • Doug: Manufactor of Grandmaster and NTP appliance want to implement not to much protocols
  • Heiko: Our proposal tries to follow the steps of NTS for NTP; therefore it currently considers Unicast PTP only. Later, it may be expanded to more complicated cases also. The current 1588 specification only defines security mechanisms no key exchange.
  • Denis: Agree NTS for PTP is worth doing. Considers the IETF the more appropriate group. Both proposals (Heiko and Langer) should be promoted. The final document maybe a combination of these documents.
  • Eric: Are there changes to or extensions for PTP that would be needed to support NTS? If so, is IEEE 1588 willing to write such a document? Or should/can ntpwg write such a document?
  • Miroslav: What are customers asking for? PTP already has a security mode. No key exchange. What is better with and easier in contrast to symmetric keys.
  • Doug: PTP are stateful. Makes things easier. No need for sending cookies.
  • Doug: PTP is vulnerable to GM impersonation; weakness of BGMA

NTS4UPTP

Presenter: Heiko

  • Meinberg and customer believe that it is easier to have one security approach for both PTP and NTP. Many customers use PTP and NTP. Those would appreciate a single approach.
  • This draft start only with unicast PTP because its closer to NTP. A defined relationship between server and client as in NTP, also the message exchange is quite different.
  • Hoping to find a solution for the multicast as well later.
  • PTP operates often in networks which are not in full control - that’s in contrast to multicast PTP. Security is therefore necessary. For example amplification attacks which are easily possible for unicast PTP.

Discussion:

  • Karen: two drafts on this topic, both are individual submissions. Question: how the WG will continue with these docuements?
  • Martin: both of these documents are useful. Martin’s is more complicated than the unicast draft. It specifies two approaches; one for the unicast mode and one for the multicast mode.
  • Miroslav: first do work an unicast and later a multicast draft only
  • Martin: Good idea. Can delete the unicast mode in my proposal to have a multicast only mode.
  • Danny: Which mode is more important from the PTP point of view?
  • Heiko: in my opioniin the unicast mode because of its weaknesses, although multicast PTP is more favourably applied. Reason to start with unicast is because its easier to specify (low hanging fruit)
  • Denis: PTP is used on larger and smaller networks. The larger are more likely to apply unicast. These might need security first.
  • Doug: Finance industry is concerned on security. They can use unicast as well as multicast PTP
  • Miroslav: Suggestion for Martin. Splitting his approach into two documents.
  • Karen: That might be possible. But we should consider the charter first.
  • Danny: want to figure out what is more important for PTP
  • Waston: Security of multicast should be a clear and natural extension of the unicast security. Martins draft might be a good basis.
  • Karen. Agree

NTS for PTP

Presenter: Martin, Slides

Discussion

  • Doug: Point a couple of things: Interface between time server and NTS KE server is defined. In contrast to GDOI is is much more simpler for the multicast mode.
  • Martin: GDOI has more functions and option than this approach.
  • Heiko: There is no specification for NTP server to talk to a central NTS KE server. This would also be nice for NTP. This should be moved to a separate draft and be applicable for NTP and PTP.
  • Martin: this is not a problem. This was already been considered.
  • Watson: putting many NTS message into …
  • Watson: records contains records. It’s difficult for implementation. Maybe rethink the structure.
  • Martin: maybe there is a possibility to find a better solution. I'm open for comments and suggestions.
  • Heiko: NTS4NTP the RFC explicit states that many NTP instances can share a KE server. But the protocol between these is not specified. It is a pretty good change to specify this communication.

Inconsistencies between NTPv6 requirements and proposals

Presenter: Doug, slides

Discussion

  • James: Separating NTP wire protocol and Security into different documents will contradict mandatory security.
  • Doug: maybe in security considerations
  • Kristof: like higher accuracy … same way as follow up message
  • Doug: interleave mode is appropriate?
  • Kristof: two-step approach would solve problem with high accuracy and security
  • Denis: Kristof propose an high accuracy timestamp like in PTP
  • Miroslav: my proposal originally had both suggestions. Interleave and two step. Two-step removed in order to simply the draft. Interleave does not amplify.
  • Denis: If interleave has the same performance as two-step. Con: it requires keeping state
  • Kristof: the client defines the time the state has to be kept.
  • Watson: Amplification issue can be solved.

NTPv5 requirement updates

Presenter: James

  • James
    • Only small changes;
    • More comments from the working group will be appreciated.
    • Ask for adoption call
  • Karen: a requirement document will probably be needed

NTPv5 Proposal

Miroslav: No change since we start with the requirements

Draft charter:

Karen presents a draft charter.

Discussion

  • Denis: is the length of this charter appropriate?
  • Eric. The length is pretty good. IPv6 has two paragraphs.
  • Eric. Key points of concern: Expand the scope beyond NTP. E.g. Roughtime, last document of TICTOC. Little bit language to be able to deal with work apart of NTP.
  • Eric: Maybe some definition of milestones. Easier to change than charter text. … Focus should be on NTP
  • Danny: Remove NTPv4 just NTP; NTPv5 missing
  • Karen: NTPv5 lost during cut and paste

AOB

  • Karen: Next meeting. IETF 111
  • Karen: there is a free waiver program. Datatracker account is needed to use Meetecho.
  • Karen: Opinion on Meetecho vs Zoom for interim meetings? James: would speak in favor for Meetecho for interims also. Meetecho makes automatic blue sheets
  • Doug: I like Zoom. Use many different systems. Familiar with them. It is a little of pain just to learn different system just for this wg.
  • Miroslav: Zoom also works with a browser only.