The Network Time Protocol (ntp) Working Group virtual interim meeting Date: Tuesday 12 February 2019 from 16:30 to 18:30 UTC. Participants: Watson Ladd, Aanchal Malhotra, Steve Sullivan, Kristof Teichel, Danny Mayer, Marcus Dansarie, Sam Weiler, Thomas Peterson, Steve Guendert, Tal Mizrahi, Martin Langer, Dieter Sibold, Ragnar Sundblad, Rich Salz, Christer Weinigel, Karen O'Donoghue, Miroslav Lichvar, Harlan Stenn, Denis Reilly Beginning at 8:30 AM pacific with a minute or two for people to join. Minutes taker: Watson Ladd No objections to recording. Administrative agenda bashing. Chair slides up, post NTS security changed to roughtime. Materials include Notewell. https://datatracker.ietf.org/meeting/interim-2019-ntp-01/session/ntp No other bashing. TICTOC quick document status. Karen: Beyond pleased to report YANG module is in RFC editor queue. Enterprise profile needs to be done. Issues with referencing to IEEE solved, will be smoother hopefully for enterprise. Nits cleared and then submit revised version. General thought is that wraps up TICTOC and remaining time in NTP. NTP Quick Doc status: Karen: Beyond excited to report MAC doc has cleared ISEG and is now in the publication phase, in RFC editor queue. Second document is the BCP, 1 DISCUSS left from EKR. Suresh (sp) will be cleared by end of week, move to editor queue. BCP took a lot longer then expected. A couple other queued up for ISEG. Next: NTS Karen: last spoken single paragraph edited, Danny: round of applause. Dieter: Update done, content can be spoken to by Marcus or Kristoff. Marcus: here with Ragnus and Krister. We're done with the paragraph. Karen: issue resolved, another question, discussion on mailing list. Kristoff: Everything seems resolved. Marcus: Impression is everyone is happy in 16. Concern about encoding of addresses (i18n again) Would like discussion of it. We need to handle this in some way Christer: I raised a few issues, the one that is really important is % encoding URI, really painful because character encoding not specified. Better to say must be ASCII. Use IDNA. It will work, won't take away functionality, simplifies things. Karen: not in the draft yet. Do we have rough agreement on the solutions? Can we incorporate? Danny: why ASCII? Marcus: Encoding not specified with % encoding. Unicode codepoint then IDNA because DNS. Having to do all that is painful. Marcus: submit PR, get it fixed. Dieter: supports proposal for sending PR. After fix, should send. Karen: sooner is better. Can take a while to go through ISEG. Krister, PR, then Dieter update and submit to ISEG. Danny: Can we obsolute 5906? Karen: not a full replacement. How to move NTP to a full standard and clear up docs. Would like to see 5906 removed. Other thing is to move to historic. Planning for NTS interop: Another hackathon in Prauge, before IETF 104. Anyone at all interested strongly encourage to try to participate. Kind of tough to do remote, have done it. Most of Swedish contingent did it. Martin, Dieter, Aanchal might be there. Mailing list to coordinate. Bit of conversation and facilitate implementation. Mailing list set up, not sending annoucement. Anything else in hackathon for NTS? Anything on NTS in general? NTF implementation status. Steve: no update. Trying to get Harlan online. Heard from Richard. Let's see if I can get update. Karen: hackathon seperate registration. Is open. Registration for IETF definitely open. Hackathon wiki listing all projects. NTS is on list. Depending on who is interested could set up some infrastructure. Previous years an Etherpad. How to best facilitate can move to Hackathon planning list. REFID updates: Don't know anything to report. Harlan not on call. Table and come back. Interleaved: conversations Miroslav: several comments after meeting, suggestion to specify followup for client server so server could avoid client specific state. fundamentally different solution. So it should be in other document. Also has problem that it enables traffic amplification. Better not to specify at all. Comment that references should be moved fixed in Git. Another one about problem with NAT. Already addressed with a statment about server times being unique, if not good enough let me know, most important is intention... implementations that might accidentally send requests in interleaved that can't get responses from interleaved. Selection not ideal, don't think it's brittle. Extension field increases delay not compatible Watson: Why not? Miroslave: currently client sending interleaved mode gets basic back. extension makes packet longer. Different measurement then in basic mode. Basically clock filter could drop interleaved mode because the delay is longer. Basic idea is basic and interleaved could be used at same time, fallback should happen only when packet loss or server lost timestamp. Watson: oh its that broken. I'll just accept that and be sad. Miroslav: can't use extensions. Most popular implementation doesn't do this. Anyway analyzing 1 TB of data for interleaved to see how currently used. As expected used very rarely 1 ppm doesn't look like any clients accidentally implement interleaved requests, a few instances of the older NTPsec which removed support for interleaved responses sending requests. What should we do about this? Avoid completely breaking by requiring server use each time stamp only once. Advantage is conforming clients will get a response in the basic mode when there is a real packet loss. Question is do we care about this? any guidelines about breaking implementations that don't follow current spec. Not sure what to do. Danny: Can't force em Miroslav: do we go out out of way to fix it for them Danny: Some conversation about unknown extension fields. Should ignore them or drop whole thing. Miroslav: currently don't use any. Danny: preculiar situation. Not sure how we should handle it. May be some security issues with interleaved. Miroslav: pointers? Danny: No. Discussion made me think. Harlan joins meeting. Is sorry he is late. Karen: Miroslav: question was guidence. Sure there is far amount of it. Haven't done good job of maintenance to start with. Hope in 2019. Need to add new functionality. Do think we care about this. Not something a lot of people would use but is useful. A lot of mailing list traffic on it. Karen: did nice summary of issues. Can you summarize on mailing list? Watson: can we fix this extensions? Danny: extension fields just bad, people not handling. Watson: In TLS clients fall back, eventually stopped. Real pain, took years to end. Security issue. Clients would fall back if things didn't work. Danny: with NTS set up the connection then use whatever you need. So interleave isn't involved. Karen: Right way forward is to clarify issues on mailing list. See if we can get WG consensus on the individual questions. At highest levels agree that not being able to use extension fields to extend protocol seems odd. Anyway, any other conversation, questions on this? Capability to do it. Harlan: what is the apparent problem with extension fields? Miroslav repeats: The issue was that in interleaved mode we wouldn't want to use an extension field because it would make packets longer therefore delay is longer and problems in filtering. Other issue is incompatibility with servers. Currently will nicely fallback. Suggestion to use extension field. Either to exchange transmit or to detect support. One issue is current servers don't support unknown extension fields meaning they don't respond correctly the other is that if and how to use it in the interleaved mode. Harlan: got proposals on everything and assuming there is a good reason why people aren't looking at that. Danny: broken server that doesn't understand extension field doesn't mean we shouldn't use it. Can't fix everything. Shouldn't say we shouldn't use it because X doesnt support it. Karen: Miroslav fill in open issues and questions for WG or next step. Harlan: extended information proposal out there. Includes bit for interleave mode. Miroslav: is it that I can use or am currently using? Miroslav: can see from the timestamps. Harlan: Not saying you can't. I'm saying there is a bit. Miroslav: how do you detect? Harlan: I-DO for that. Currently not a fan of client-server interleave because of state on the server. Miroslav: followup message allows amplification. No way around it. Harlan: I-DO can do it. Not lots of precision unless you have a very accurate clock and high precision timestamps Miroslav: hardware timestamp supported. Common these days. Harlan: then client server negotiation can work with I-DO. If can't detect with timestamps then extended information. Not sure what issue is. Miroslav: Protocol works fine. Trouble is there is a NTPsec version had to remove support, sends requests in interleaved mode, not able to support responses. Older release Client will experience packet loss or fail association. Danny: We can't fix that. If not following broken. Don't think we should spend time on working around that. Miroslav: basically what I was asking. Karen: anything else? Sam Weiler: deeper dive into I-DO or extended information draft. Karen: can do that. Thing is there the extension field doc that is a dead working group doc. Last guidance was invididual extensions compatible with 7822 could be consider. Sam: not sure if responsive. Would it help the working group. As in do people understand them? Karen: we could dig in in more depth if you like. Is that responsive? Crickets Sam: move on. Karen: we will see what we can do about extension field Karen: Client data minimization. Is Daniel on the call? Issues need to move forward with that one. Seperate note to summarize for group. Aanchal hasn't talked to Daniel. At last virtual meeting don't think there was followup. Harlan and Aanchal were to summarize Karen: summarized results as far as 1 objection, 1 no clear statement, some no objections with comments Next document that we have is YANG data module. This has gone through YANG doctors, read for WGLC, authors not on call. Will send out for WGLC. Listed: other WG docs. Part of what we need to do is we have a whole bunch of individual submissions to triage. Agenda, welcome for requests, got none. Suggest people look at related ids and see how to move forward with some of these docs. Next thing was next steps and we got request to talk about Roughtime. Aanchal: submitted draft, got comments. Can summarize what its about. Have gotten comments to address. Discussed, haven't yet updated. Roughtime protocol: rought time synchronization but is useful in various context. Main difference is that it provides third party evidence of misbehavior of a server, which client can prove the server misbehaved. Main advantage of roughtime. Server signs response, details in draft. Sounds like any other protocol which also uses MAC, but roughtime uses public key signatures required for functionality so can verify. Now were various issues and comments. One of the concerns is around leap second or how to implement. Currently smearing, Marcus: implementation appears to work. Three more nits. If i can add, Aanchal motivated begining use. Like to add main advantage is application that can't set clock. Can use roughtime to see how wrong, and can adapt sense of time. See that this could be used in browsers to validate certs. Aanchal: IOT Marcus: don't see this as a competitor. NTP and NTS different role from roughtime. Aanchal: not replacement Danny: NTP can Harlan: NTP and POSIX don't set time backwards, slow clock down. Issue isn't with UTC it's with POSIX. Watson: is linux mainline broken? Mirsolv: Can use own timescale. Suggesting can be used in parallel to improve Watson: Agree Miroslv: Can use interleaved mode to recover. Watson: applications we're thinking of don't have that tight a need for time bad. Sam: What about live PKI? Watson: update files Marcus: publish JSON file in existing format on HTTPS website. Or can do what cloudflare does and have public certificate in DNS. Sam: Two different models Marcus: two different suggestion. Sam: part of the system, worth contemplating, affects analysis. Harlan: still chicken or egg. Watson/Aanchal: not quite, can update. Original proposal for updateable devices Marcus: furthermore, eventually anchor trust Watson/Aanchal: individual Rich: First time to include a config file will win. Marcus: such a file with 5 servers. Rich: overlap of trust store, 95% Watson: not same incentives as PKI. Marcus: and again don't think we have to solve maybe not at all. Nicholas Marcus: Systemic decisions to make on the list Aanchal: we knew, wanted to make sure the draft got here. Would love suggestions. Important to address Karen: important issues. Need to address, 5-6 weeks before meeting can plan update. Watson: Drop dead date? Rich: March 16 on the order, it's March 9th Karen: will get back. 10 min to hour, at that have have operability going, andminstrative stuff, last stuff. AOB? Denis: ISPCS Denis: ISPCS held in Portland Oregon Sept 22. Last year had it at CERN. Even though ISPCS is forum for PTP papers, conference could have good NTP based papers, charter is clock synch over networks in general. I'm telling you because I'm a cochair. Want good papers submitted. More convenient for all West coast people. ispcs.org Karen: Rumors about about NTS paper submitted. Rough idea a bit late doing the hackathon has been very helpful for focusing and progressing WG efforts, one in July. Considering Nov because Singapore is tougher. Hard to get people to. Keep that in mind. Don't have to limit to NTS, would be helpful to look at other things and progress. Last thing 11 March is cutoff for IDs for IETF. Feel free not to wait, 22 Feb. This meeting was focused, so some outstanding requests. Datatracker for NTP working, before extension field if we had a side meeting and got traffic on mailing list to revisit these. About it. Would like Harlan, Sam, to coordinate OOB and be prepared coming into Prauge to discuss them. 9:55 final remarks. Harlan: did we discuss the BCP Aanchal: send out mail about hackathon. Just wanted to confirm. Karen will preenroll a bunch of us, can unsubscribe. Meeting wraps with 30 min to spare.