**Session Date/Time:** 21 Jul 2026 14:30

[00:01:14] **Karen O'Donoghue**: Okay. We're gonna go ahead and get started. Welcome to the NTP working group meeting at IETF 126. Since you've been here a, well, I guess, two days now. This is the note well. This contains all of the policies and procedures that we use as an organization. You have agreed to abide by it when you registered for this meeting and, additionally, when you signed up for data tracker. If you have any questions, feel free to ask the us, Dieter, or I, or our AD. And with that, in person, this is our the first meeting under our new AD. Erik Klein had hoped to be here, but he has a conflicting meeting. And so we thank him for all of his work, and we we welcome Tommy Jensen. These are the, k. These are the, meeting mute. Tips that the secretariat, provides. Just as a reminder, this session is being recorded. And then finally, here are some resources. Remind everybody to use the support at I a t f dot org if you have any issues. It's a ticketing system that you can put in things like your networking problems and things like that. So this is our agenda for the day. We have most of these will be pretty short. They're gonna be updates and statuses on where we're going on a number of items. There is a notepad linked from the agenda that we use for taking notes. Dieter will be taking some notes. Feel free to add your own observations, and we'll put them use them along with a few other things to produce minutes at the end of this meeting. Is there any agenda bashing? No. Okay. So the first thing I wanted to mention, and I took the opportunity to to feature a new tool that we have, we have two NTP working group documents. We always go through all of the documents that we have that are not completely finished. So we have two documents that are currently sitting with the RFC editor and there is a new website if you haven't seen it for rfceditor.org and part of one of the aspects of that website is actually a queue that shows you what the status of each item is which I think is very handy. So you should check out the new website. For the first document, NTP over PTP, it's actually been there for a while as a number of you are aware. The RFC editor is trying to clear a backlog of documents so we can get them processed a little bit more, rapidly. And there's been a lot of work on processes and tooling and all of that to help make that happen. The NTP over PTP document has has been with the RFC editor for about thirty five weeks now. However, the good news is that it is in the second edit and in talking to them it's my understanding that this is the final quick pass by them, and it'll soon be coming back to back to the authors for the what used to be called the auth 48, and that's now called the final review. So that is the authors reviewing all of the edits that the RFC editor has made. So, hopefully, that document will clear pretty shortly. The second document we have in the in the RFC editor queue is the roughtime document, and it's been there for, about seventeen and a half weeks. So, it is awaiting its first editor, so it still has a few a few rounds to go. And, if at any point you are curious about the status of any document that's in the RSC editor, you can now look at the queue and check out the status of that. So the next item on the agenda is ntpv5. We don't have any slides for this. We just wanted to talk through a couple of things that have happened. There the the deck document is undergoing ongoing there's a number of open issues associated with it, and there have been there's been some progress on those. Did you David, were you gonna talk about the or Sarah, were one of you all gonna talk about the

[00:06:01] **David Venema**: I don't know what her problem was.

[00:06:07] **Karen O'Donoghue**: I'm sorry. I put you on the spot without verifying it ahead of time. My apologies.

[00:06:12] **David Venema**: Yeah. No. I don't know what the exact plan Sarah had was. The thing we were working on is mostly separate from ntpv5 anyways, or at least it's intended to be. I think for now, it's best if we skip that.

[00:06:29] **Karen O'Donoghue**: Okay. That's that's good. So we have a number of open issues and we need reviews on this document. We are hoping to go to working group last call before the end of the year. David's gonna talk a little bit about some of the work that they did at the hackathon this weekend. We also hope to have a a small meeting, amongst a few, participants to work through some of the issues possibly in August. So, with that, are there any questions on ntpv5? Okay. Nope. David, you want the pool experiment?

[00:07:18] **David Venema**: So since last time we've progressed in the pool experiment that we've been running, there's an experimental or more a less experimental NTS pool now available at sectime.org. We've been running the draft that is within the working group on that, and we've updated it now to the early allocations for that document. So it's basically running, hopefully, final final version of that spec. We've seen some reasonable uptake on that thing. There's about 20 servers in there now. There's been some users who've been testing all sorts of funny things against it, which is fun to see and interesting to see. We are still looking for people who want to try it. So if you are interested in just trying it, that would also really help. In terms of the document for the NTS pool experiment that we've been running, the draft has been updated for the early allocations, so those identifiers are now in there. And there's been added a small section on the session flow that the NTS pool experiment uses to provide additional context. We would love feedback on the document. It should it it was uploaded recently, so probably not today. But if you have some chance to look through that document, we're getting really happy with where it stands, and there seems to be less and less comments on it. So, hopefully, we can move that forward soon. Any questions?

[00:09:04] **Karen O'Donoghue**: Anybody had a chance to take a look at that document? Have folks been reading it? Alright. Did you want, with that, you wanna talk about the

[00:09:32] **Marcus Dansarie**: Yeah. So the thing that David just talked about is the first part of this whole pool experiment, but running on sectime.org is also another experiment, and that's what I wanted to talk to you about. Next slide, please. So the thing is there that that we really like the design of pool.ntp.org because it's DNS based. It uses caching from DNS to improve performance or reduce load. Serving static DNS responses is relatively cheap, so we'd like to have that same kind of thing for NCS as well, which is what this sort of experiment is trying to do. The issue is that regular a or quads a records in DNS don't work because using that, you would need to share a certificate between all servers in that pool, and any leak certificates from that pool would then immediately mean that all servers in the pool have compromised security. So not an ideal solution there. So what we can do is use SRV records. I've put an example on the slides at the bottom for one of such records. Using SRV means that every or every server can have their own certificate. Next slide, please. So about the properties of such a pool, well, to define some terms, we have the term membership, meaning that a specific server that is part of the pool is a member of that pool. And then we have the idea of selection, I. E, the process of choosing a specific NTS server to receive time information from. And then we have a couple of properties that need to hold, specifically that the client must be able to verify that current membership of some NTS server. And the second property is and that's the most important one, is that the selection must be between the pool operator and the client only. So we don't want third parties to be involved in this selection process because that would compromise the security of NTS. Next slide, please. To get the first property, we can simply do this with DNSSEC. DNSSEC cryptographically signs the DNS response, and that can also be done offline. So we can do this very efficiently, generate responses upfront, and that ensures that only the pool can sort of indicate this membership relation that we previously identified. Clients can then validate the DNSSEC signed responses. And then only if the validation succeeds, you'll know, okay. The server is in the pool, and I can safely connect to it assuming that this is actually in the pool. The issue, however, is that DNSSEC does not protect against replay attacks, so you can just capture a DNSSEC signed response and repeat it a second or third time. So what an attacker could do is could could keep continuously querying the pool until a specific response is generated that contains the attacker's server of choice, and then the attacker can replay that response as long as the DNS signing is valid. So that's an issue here. Next slide, please. So what can we do to mitigate that specific attack? We can keep the TTL. So so how long is the record valid? And the signing duration of records, we can keep it relatively low so that a a, like, set of servers that is in the attacker's wishes is only valid for a limited amount of time. The other thing we can do is increase the number of servers in the response so that the attacker has more difficulty finding a suitable set of servers that suits their purpose. But those mitigations contradicts the initial sort of niceties of of having this d n DNS based solution, I. That the caching is reduced because now the TTL is shorter, And the number of signing operations is now increased as well, so it increases load as well. So that's sort of there there is a tension between the initial goals and what we now have to do. The next slide, please. So this this proposal is also available on sectime.org, specifically srv.sectime.org. The instructions are as well on the website as well. So take a look if you wanna see and and try if this works for you. Note that to do this, you need an changed client. So the client is different to compared to a regular NTS client. We made patches for n t p sec and ntp-rs from version one point eight point one has experimental support as well. So you can try any of those. All the details are again on the on the website. The one thing to note here is that we definitely noticed that the client implementation service increases significantly because now we have to do all the DNS signing verification stuff, which is our main worry as well is that this is something that some client implementers might forego and then sort of reduce the the security for a specific client. Next slide, please. So one other thing there is that SRV based pools can only be used by pool aware and correctly configured clients, and there is no sensible graceful fallback unlike the current pool implementation where if you're not aware it's a pool, it will just take one address of the pool, and it will work just fine. This is not the case for SRV. It's also the case for the previous proposal that David mentioned. The there you have this graceful fallback. So that's one issue where you need to be very careful about your clients. And the implementation service increases significantly. There are very few DNSSEC libraries available that are fully grown and and work decently. Another problem is that often local caching stop resolvers, so, like, have a resolver on your system. This is typically the case of most operating systems. Those local resolvers, they typically do not do DNSSEC verification, unfortunately, so we can't rely on those. And recursive and stop resolvers have all been known to have bugs in reporting DNSSEC validation status, so we can't even rely on that. So it's really something that the client themselves currently has to do, which makes us all a bit not that nice. We've also seen that Recursive Endstop Resolver strip DNSSEC records as well, so then we can't even do the validation anymore. And one other thing to note is that the DNSSEC has a root key, and that root key needs to be refreshed every couple of years. And there is no real good process for that right now other than updating software to the latest version. So, like, not updatable clients are gonna have trouble with this relatively quickly as well. That's all I had to say about this thing. If there are any questions, please let me know.

[00:17:29] **Karen O'Donoghue**: Any comments or questions on this work? Going forward, do you have so we currently have sort of two approaches to doing this. Yep. And is your conclusion that this is not the way you want to go?

[00:17:49] **Marcus Dansarie**: So what we're gonna do now is keep this running as well for at least at least a year, and then we'll hopefully gather some data about how this actually runs in the network. So anyone is very much invited to try this out as well so we get more traffic on this, and we can hopefully see some of the caching behavior of DNS there. So please do do try it out, But we have some reservations about making this a recommended standard for now given the situation with DNSSEC and its verification.

[00:18:29] **Karen O'Donoghue**: Okay. The as a reminder to everybody, the the adopted pool draft that we have is on the experimental track, and the idea was that we would get some experience. And then in year or two or three, we would, decide which recommended process we wanted to follow. And so Yep. Alright. Alright. And no questions? Okay. The next item on the agenda is actually just a quick status report as well, and it's the NTS for PTP. Just as a sort of a background to anybody who's new in the room, we've used the process before of going through all of our documents whether there's any real updates or not, sort of to remind us these are the things that we're supposed to be working on. And in some ways it looks like the NTS for PTP document has slowed down. But what's actually happening is a significant amount of the work is actually happening in an IEEE fifteen eighty eight. So when the IEEE fifteen eighty eight work completes, then we will come back and start working more. We'll we'll update the one that's here to reflect the work that's been done in in the, I triple a fifteen eighty eight group. So, it's it's not completely dormant because it is actually getting a lot of, we need 1588 to come to consensus on how they're doing things, and I think we're pretty close there. Alright. David?

[00:20:36] **David Venema**: Yeah. So we're with a small group from the working group at the hackathon as well. Next slide, please. The main plan during the hackathon was basically to focus on three the three major drafts that are currently in development and and going through the working group, which was the n t p the NTS pools stuff. That was the ntpv5 draft, and that was roughtime. There was still some focus on roughtime as well with a primary focus on interop testing for the roughtime and then to p v five stuff and with getting people to engage with the pool experiment for the NTS pool stuff. Next slide, please. So for NTS pool, we found some bugs in the experimental pool around I p v four handling, helped some new people join the pool as servers, got a few people to actually start using this the pool as their time source. Calls action, again, to try use it. It's at sectime.org. We were also present with pool at the hack demo happy hour where it was also demoed to a lot of people. So, hopefully, it'll that'll get us some feedback on how it works and how people are experiencing it. Next slide, please. Next up, the for ntpv5, Sarah spent a lot of time creating a intro harness for ntpv5. There's some initial conclusions from that. There were some initial bugs found between Crony with ntpv5 and ntp-rs, specifically with the upgrade process not working. That's still being looked into at the moment. The internal partners works for the most part, and there's a spreadsheet now that's slowly getting filled in with results from interrupt testing. So that's that's ongoing work. Looking forward, hoping to fix, of course, those bugs. And the harness as it stands right now does not yet include NTS for ntpv5, which is implemented by at least one of the clients. So that's also future work. Next slide, please. Finally, for roughtime, additional interrupt testing was done to extend additional work was done to extend the framework for testing that to both UDP and TCP. TCP is not yet supported by number of the implementations, And the primary inter barrier with roughtime at the moment is that a lot of the implementations are still using incompatible versions of the roughtime standards, and not all of them are latest draft. So that's still a limitation there. The implementation is available at link in the screen. Final slide, please. And that was basically all that was done. These are the people that were involved, the main links for all the work, and main contacts if you have questions about anything. Feel free to contact these people. Any questions?

[00:23:54] **Karen O'Donoghue**: Sarah's in the queue. Go ahead, Sarah.

[00:23:58] **Sarah Dickinson**: I was just going to add a couple of bits and pieces to what David has said. Thank you, David. Around the roughtime issues with TCP, not only do we have the problem of very few implementations supporting it, but there isn't a clear way in the implementations to either force TCP use or get the interop harness to sort of control or convince implementations to fall back to TCP. So maybe there's is some work there by implementers, if any are around, to maybe help with that. But perhaps it would be better to wait for the publication of RFC and relook at this considering that that will then cause a version bump. As for the NTPv5 interop work that I did on the weekend, I think it would be kind of interesting to talk about the issue that the the sort of the our initial observations in the you know, in addition to the draft version mismatch that we've seen across a few implementations. The other thing that I think was interesting to bring up as well is that a few implementations seem to have a mismatch when they perform an upgrade, I. E. They send version four first and then giving some sort of indication that support V5, but then the server doesn't acknowledge this and the conversation continues as v four. So there may be some work there in terms of not just the implementations, but also in the documents on perhaps better describing this so so that implementations get it right. Yeah. That's all I wanted to say.

[00:26:12] **Karen O'Donoghue**: Alright. Thank you. Anything else related to the work that was done? No? Alright. I'd like to thank the folks that participated. Thanks, David. Alright. The So the next item on the agenda is the IEEE fifteen eighty eight update. The as we've discussed previously, there's a lot of correlation between these two groups. This is the current status of of IEEE fifteen eighty eight is also PNCS which is just IEEE way they call it. Going through these, there's a number of projects that are open. The roll up revision is is an IEEE process where you need to after you've done a certain number of amendments, you need to roll them all up into a single version that's the new version. So that is ongoing, the comment resolution for that. There is a asymmetry calibration effort that's not as necessarily as relevant to us. There's an announced message disable project and a profile configuration project. Unicast negotiations, these are all not necessarily related to us. The one that's most significantly impacted by us is the security one because the security subcommittee in IEEE fifteen eighty eight is looking at the use of network time security, which was developed here for both NTS and for both PTP and CSPTP. There is an open maintenance working subcommittee and that is specifically to deal with maintenance issues that come up. It's sort of the IEEE version of the errata process here. And then there's another accuracy related one. And finally there's CSPTP. Leveraging slides that have been done elsewhere. For the PTP security part of the security subcommittee, we are looking at three key work items. One is to address the identified PTP vulnerabilities. A good number of those vulnerabilities came from discussions in this working group to add NTS as a key management mechanism, and then finally to add datasets for PTP security. Being ever optimistic that we have a fairly solid draft that's made a lot of progress in the last six months. I'm hopeful that in the, you know, possibly the next six to eight, ten months that we'll be able to get that one finalized. I think by the fall, we should have enough updates done that Martin and Reiner will be able to update the draft that they're doing in here. There will be some enhancements to NTS required to support this particular set of work. The second item of interest is CSPTP. So CSPTP is client server PTP. It's a relatively new effort in IEEE 1588, and there has there were a number of proposals early on. We have a fairly solid draft at this stage, with additional, comments coming in. The key for this group is that CSPTP looks, for the purposes of security, a lot more like NTP than PTP itself does. And so the hope is that NTP that NTS will be able to map fairly directly onto that. So there is an initial proposal that was developed by David that will look at the use of NTS for CSPTP that has been submitted. And last year, we did some preliminary proof of concept implementation work at a previous IETF hackathon. So those are the two activities that are the most relevant to this particular working group. And I know that that one document has been sitting as an adopted document for a while, I expect, you know, within the next year, we ought to see a fair amount of movement with that. Are there any questions about that? Oh, no. I don't wanna do that. Alright. The next item is a liaison request that's been received from the ITU study group seventeen group. This is related to a number of rollovers that are expected in the 2036 to 2038 timeframe. If you looked on the mailing list, I have sent the documents that we've received to the mailing list. We will be answering that liaison. If anybody is interested, please review the documents. If you have any comments, we'll be following that up on the mailing list. The you know, the next steps, I've we've already had some preliminary discussions with the IAB liaison coordinators, and we plan to meet with them tomorrow, just to get a better idea of how they would like us to do this. And we will prepare a response, and, follow-up as going, you know, forward as it makes sense. So any questions on a liaison request? You guys are really quiet today. You're much more talkative on the interims. So with that, we actually have come to the end of our agenda. The is there any other business? Nope. We are we have did her and I have talked about possible dates for a potential virtual interim. We're looking at the September 15 with, hopefully, the the plan that the in particular, some of the ntpv5 open issues will be closed or close to closing in that time frame. So if you could mark your calendars for that, it would be great. Any last minute business? Oh, there you go. I give you an hour of your day back.