NTP WG Meeting IETF 112

Online
Friday, November 12, 2021, 14:30 UTC

Administrative and Agenda Bashing

• Minutes: Dieter
• Session and chat are being recorded
• Agenda Bashing: No

NTP/TICTOC WG Document Status Review/Update (Chairs)

• Update of NTP charter
  • Is currently out for external review
  • the link to the charter is provided
• Interleave Mode in IESG Evaluation
  • it is been deferred
  • need some guidance from Erik
• Mode 6 commands in IESG evaluation
  • it went through IESG evaluation
  • it is waiting for a update from Brian
• YANG data model in IESG evaluation
  • waiting for an author update
  • That will be provided shortly
• Alternative Port is in WGLC
  • WGCL not closed yet, there has been some discussion on it
  • Magnus will do an early TSVART review
• Chronos
  • very limited discussion
  • feedback from author if it is ready for WGLC
  • this has been adopted as a WG document but progress on it has slowed down
  • Next step: chairs need to reach out to the authors in order to get this document ready for WGLC
• NTP update registries
  • Rich submitted a new version and suggested that it is ready for WGLC
  • No objection from the WG. Chairs will issue the WGLC.
• PTP Enterprise Profile
  • ready for IESG but waiting for writeup
  • the terminology of this document is going to be problematic. IEEE 1588 is already working on this issue.

Roughtime

Watson presents update of Roughtime

Discussion

• Karen: There are two documents. Do you have a rough time frame on what to do next with those documents?
• Watson: Ecosystem v1. This one is a bit stalled. We want to have feedback from people running servers and clients and what they want to see from the ecosystem. The wire protocol: will be revised and a new version will be released during the next few weeks. Like to note, that Erik suggested to ask for a early sec review, probably around the same time the document is considered to be ready for WGLC
• Karen: Extensive list of issues. Will the next revision be ready for WGLC. Suppose this will depend on the comments after the next revision comes out.
• Watson: I hoped that the current revision was ready. I'm not going to be as optimistic with the next revision. Although a lot of issues are editorial. When the next revision comes out we like to get comments from people who still don't agree how we handled the issues.
• Karen: Thanks Watson

NTP v5 use cases and requirements

James presents update of the NTPv5 requirements draft

Discussion

• Karen: since we have a new charter soon it will make sense to have a WG call for adoption on this document unless somebody is in opposition.
• James: I'd like to release a new revision prior to adoption call
• Doug: One of the main topics people are debating is the requirement that security should be mandatory. This statement should be elaborated. E.g., which mechanisms have to be used; more detail on what to implement.
• James: There is more than just "security is mandatory" in the draft. I think we have to distinguish between confidentiality and authenticity. Authentication should be mandatory whereas confidentiality should be optional. How this is achieved is a question about solution and not the scope of this document. Probably, using NTS should be appropriate. Not sure what else need to be elaborated on that topic aside from the thread model which I started to work on and which lists the risks and the potential mitigation and thus requirements. Any specific example of what you mean by more detail?
• Doug: E.g., minimum security requirements for lightweight devices
• James: That would be part of the actual protocol specification. If certain performance requirements of embedded or constrained devices should be part of the requirements document, it would good to know what those are.
• Doug: I don't have specific requirements in mind. I just think it would be good to have a little more details on that. Will send thoughts on the mailing list.
• Karen: Do you have a rough time frame for the next revision?
• James: Definitely before next IETF meeting.
• Rich: What kind of things you planning to do? Why not adopt it yet and then doing these things with the WG afterwards?
• James: The biggest concern is the structure of the document. I've started to restructuring it during the last couple of weeks. Maybe what I can do is just publish the restructured document with one or two small changes as version 3. Then I can carry on the the rest of other changes after the adoption of the document.
• Rich: I would encourage not to wait until next March.
• James: I can publish next week.
• Karen: I would prefer this as well. Would also like to see adoption pretty quickly. Some stuff are queued behind it.

NTP v5 (Miroslav)

• Just one small change suggested by Doug. No real changes in the protocol
• Dependencies on the requirement draft. I'll like to have those requirements clear, especially about the security part. Would be nice to see if the draft fits into those requirements.
• I observe two groups which are pulling in opposite direction of the rope. The first that extend the use cases of NTPv4 the other is trying to restrict them, make one proper way to use NTP - either secured or not secured.
• Suppose we will not get consensus on one set of requirements. Maybe we need to define requirements for NTPv5 and a set of requirements to fix NTPv4 - which will not be called v5.

Discussion

• Karen: Agree that there is currently no consensus on what NTPv5 should do. Unsure about how to solve this. Therefore, I'd like to see the requirements draft will finish sooner than later.
• Doug: I really like how leap smearing is made transparent in this proposal. Hidden leap smearing is a catastrophic data center failure that is waiting to happen as they become more and more dependent on precise timing. Lot of them want to do leap smearing like Google does. Making it visible is way better than pretending it is not going to happen.
• Karen to all: Everybody please have a look on Miroslav's and James's draft.

NTP Over PTP (Miroslav)

Miroslav presents slides

Discussion

• Martin:
  1. Is this only for LAN?
  2. What is the advantage of NTP over PTP vs plain PTP?
• Miroslav:
  1. This is not limited to LAN. You can use it over Internet also. But if you use it over Internet the jitter in latency become much more dominant and the improvement obtained by the hardware time stamping becomes insignificant. The approach adds no security issue; amplification is not possible. This is already implemented in Crony.
  2. Many issues with PTP: security issues, amplification issues. I tried to list the issues of PTP in the draft.
• Doug: I dubious about this over WAN. Accuracy will suffer because of routers. If enough routers are involved PTP is not really any more accurate than NTP. I've got the input of people from the finance industry that they don't like the way PTP is working. They use PTP because they need the precision of it. In theory you can have multiply grandmaster clocks in PTP and combine them in a voting algorithm but no implementation supports that. That is a default feature in NTP and these people like this aspect of NTP. That might be a reason why people might want to do that.
• Ignacio: It basically the same comment. If you are trying to synchronizing over Internet you will get several problems. This one I addressed with the draft I presented to TicToc. My question to Mirsolav: Out of curiosity. You always found the same bias to the transmitter or the receiver, even if inverted. Will the bias be inverse if the machines of the server and client will be swapped?
• Mirsolav. The sign of the asymmetry stayed with the machine. The cards have been different, but the setup of the hardware where the identical.
• Ignacio: Ok, I used to synchronize microcontroller and I had problems even if the microcontrollers seems to be the same. There has been always some bias.
• Doug: If you get below microseconds there is a lot of well-known asymmetries.
• Karen: Thanks Miroslav. I will close the queue for this topic .

NTS for PTP

• Martin is giving a quick update on NTS for PTP. Currently we have two NTS based draft documents for securing PTP:
  1. NTS for PTP by Rainer Bermbach and me
  2. NTS for UPTP by Meinberg
• Two draft documents are not helpful
• Authors agrees to merge the approaches and design a new protocol. We probably will use the unicast approach from UPTP and the approach from NTS for PTP for multicast.
• The redesign has just started and is on-going.
• We will use NTS key establishment protocol for key distribution mechanism for PTP.
• We are not able to say when the first version of the draft will be ready. Maybe in two or three month.
• Karen: Thank you. We will look forward for the draft.

AOB

• Karen: Virtual interim mid-January? I do think we will make faster progress with interims. And we will have more control over scheduling.
• James: Sure, provided it don't conflict with other interims I have in January.
• Rich: Status of Registry draft?
• Karen: No objections to do a WGLC on it.
• Karen: Anything else?

Adjourned.