NTP Virtual Interim

June 22nd, 2021
15:00 UTC
Meeting Minutes

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.