Minutes interim-2021-ntp-01: Tue 11:00
|Meeting Minutes||Network Time Protocols (ntp) WG Snapshot|
|Title||Minutes interim-2021-ntp-01: Tue 11:00|
NTP Virtual Interim<pre>
June 22nd, 2021 15:00 UTC Meeting Minutes</pre>
- Agreed to move NTS4PTP discussion before
NTP/TICTOC WG Document Status Review/Update
- 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.
- Will be moved to tele chat
- Eric will try to understand all comments and then move it to telechat
- shepherd writeup will be done by Karen
- WGLC will end Friday. Please respond
The update registries draft
- Adoption call open. Please respond
- no recent discussion
- 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
- 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
- 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.
- 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
- 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
- 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
- Only small changes;
- More comments from the working group will be appreciated.
- Ask for adoption call
- Karen: a requirement document will probably be needed
Miroslav: No change since we start with the requirements
Karen presents a draft charter.
- 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
- 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.