=============================== NTP Virtual Interim April 6th, 2020 15:00 UTC Meeting Minutes =============================== Chairs: Karen O'Donoghue, Dieter Sibold Minutes: Tal Mizrahi Virtual meeting material: https://datatracker.ietf.org/meeting/interim-2020-ntp-03/session/ntp Participants: ============= Karen O'Donoghue, Internet Society Dieter Sibold, PTB James Gruessing, BBC Denis Reilly, Orolia USA Joachim Fabini, TU Wien Tal Mizrahi Dhruv Dhody, Huawei-India Daniel Franke, Akamai Marcus Dansarie Miroslav Lichvar Danny Mayer Rich Salz, Akamai Phil Roberts Fernando Gont, SI6 Networks Ragnar Sundblad Kristof Teichel, PTB Watson Ladd, Cloudflare Erik Kline, Loon LLC Doug Arnold, Meinberg Leif Johansson, Sunet Eric Gray Introduction ============ Slides: https://datatracker.ietf.org/meeting/interim-2020-ntp-03/materials/slides-interim-2020-ntp-03-sessa-chair-slides Presenter: Karen O'Donoghue Summary: - Karen presented the note well. - Meeting is recorded for the purpose of minute taking, but will not be posted. - Welcome Erik Kline, our new responsible AD. - Karen presented the agenda for this meeting. - This virtual meeting replaces the IETF 107 NTP session, which did not take place due to the Coronavirus. - Jabber will not be used in this virtual meeting. - This meeting uses Zoom. Are there any comments about tools used for virtual meetings? - Danny: we will need to reconsider Zoom due to the security issues that were recently published. - Two drafts are currently in the RFC Editor's queue: the NTS draft, and the packet timestamp draft. Congratulations to the authors. - Rich: congrats to the NTS authors for their amazing work. - Three more drafts are ready for the IESG: YANG model, Interleaved mode, and Mode 6. Port randomization ================== Presenter: Fernando Gont No slides Summary: - The draft is pretty stable. - Recent change: the draft calls to randomize the port number on a per session basis. - There was a comment that we should not mandate how randomization should be performed, that we should just require the port to be randomized, without mandating how this is done. The comment was that it is enough to discuss the options and tradeoffs between them. Two main requirements: one is to randomize the port, and the other is to randomize on a per-association basis. The feedback we got was not to specify per association. - We are looking for some more feedback about whether this makes sense. Discussion: - Karen: any comments about this? - Danny: was there a specific reason to specify how exactly you randomize? - Fernando: I agree. We started by deciding that per-associatin makes sense, and changed it to per request basis. But the important part is that ports should be randomized. I do not think we should mandate one way to do it. - Eric Klein: I can see the rationale for not over specifying. - Fernando: I do not think that folks who are randomizing on a per-request basis should be non-compliant. - Danny: are you recommending that each association will have a different port number? - Fernando: of course, and another option is to randomize in each request. - Danny: why not use the same port for all associations and then close the port? - Fernando: in a way that is okay, but some may argue that it is orthogonal to port randomization. - Danny: the cost of doing it for each request is very high. - Fernando: right, that is why we are suggesting to leave it to the implementation. - Miroslav: reusing the port for different associations would open the port to any address, and there would be no point for randomization. It would open a vulnerability. - Fernando: yes, I believe that was implied. Among associations the port should be different. We will clarify that. - Karen: please post the question to the mailing list. - Fernando: yes, we want to ask the WG before we start with a LC. - Karen: right, we have not done a WG LC for this draft yet. Please follow up on the mailing list, and then we will decide whether it is ready for WG LC. Chronos ======= Presenter: Tal Mizrahi Summary: - The authors have recently published an updated version which is aimed at addressing the main issue that was raised so far, that Chronos improves security at the cost of precision. - The authors believe that the approach of the current draft provides improved security without compromising the precision compared to NTPv4. - Please read the latest draft and send comments. Discussion: Danny: based on my discussion with Michael, one of the authors, you lose a lot of the precision, since you change the set of servers you sync to. Tal: I urge you to read the latest draft, which I believe addresses this problem. The current approach is that Chronos runs as a watchdog in the background, and only kicks in when a potential security attack is detected, allowing you to enjoy the best of both worlds. Karen: another issue that was discussed was whether this should be informational or experimental. Tal: in my opinion informational. The thing about experimental is that you are expected to revisit the draft after a couple of years. Informational is not as demanding as standard track, and fits this draft because you can implement it without compromising interoperability. Watson: the new filtering mechanism - was there an experiment to verify the stability? Another question: is it related to NTPv5? Tal: yes, the authors have presented some of their experimental evaluation about the previous version of Chronos. Evaluation of the current version is in progress. As for NTPv5, I believe that one of the proposals for NTPv5 is to separate the protocol from the algorithm, which seems to work well with Chronos, since different implementations may have different algorithms. Danny: some of the experiments that were presented by the authors were on virtual machines, where you do not know what the clock is doing. Tal: okay, thanks. Karen: Tal, please post something on the mailing list summarizing the changes and encouraging discussion. Roughtime: ========== Presenter: Watson Ladd Summary: - There are a few implementations, which may not be exactly the same. - There is now a version field at the start of the packet, which allows multiple versions out there. This also enables protocol agility. - There is also some more information about leap seconds, TAI, UTC. Discussion: - Karen: any questions? - Karen: the next step would be more review and comments. - Watson: we are hoping for more implementations and feedback from the field. - Karen: are you tracking the different implementations? - Watson: I am trying to. - Karen: please ask the WG for more comments on the mailing list. Please also ask implementers to step forward and share. Alternative port for NTP ======================== Presenter: Miroslav Lichvar. Summary: This draft presents a new port for NTP that cannot be used in the control and private modes. It is meant to resolve amplification attacks. Discussion: - Watson: the draft requests a UDP/TCP allocation. Do we really need the TCP port? - Danny: you should probably need the TCP port. What is the problem with control and private mode? - Watson: it is already in the hardware of some devices. - Rich: right. Port are not a scarce resource any more. The fact that NTP port is open to amplification attacks needs to be fixed. Hardware needs to be fixed. - Daniel: instead of having clients try two ports, maybe we can have the port as part of the negotiation? We do not want to block Modes 6 and 7, but instead we want to prevent amplification. For example, Autokey can amplify as well. We should take a more general approach. - Miroslav: draft says that client should try to switch between ports. In NTS it make sense to use the port from the negotiation, but if you do not use NTS we need the client to discover it. - Watson: changing the port does not solve the problem of port firewalls; we will still need to open a port. - Danny: you cannot assume that NTS is used. - Watson: if they are using NTS then problem solved. - Danny: maybe the new port should be strictly for non-NTS cases. - Watson: the pool statistics show that some networks are heavily policing, messing things up. - Danny: why does NTS not use a different port? - Miroslav: why? it is still NTP. - Danny: but NTS has different requirements. - Watson: so any extension will have to use the new port. - Danny: maybe, because most firewalls are limiting the size of NTP packets. - Watson: that would prevent any extensions. - Danny: right, the size of the packet causes all sorts of problems. - Miroslav: for the NTS, we will need to define how it can work with two ports. - Daniel: why two different ports? Why not respond with the alternate port? - Watson: you can be in a network where this causes a problem. - Karen: we need more discussion on the mailing list about the various options. - Erik: sounds like there are many questions. Does this apply to NTPv5 as well? - Watson: I do not think so. - Erik: has anyone done any measurements? - Watson: there are challenges in that. We do not exactly have the telemetry for that. - Daniel: what would IANA think about this? - Karen: you mean are they willing to allocate a port? - Daniel: we need to understand if we can get a port. - Karen: this is a 00 submission. - Daniel: right, but we have discussed it for a year. - Erik: I can ask the IESG. People allocate ports all the time. If the question is whether we can get a port for *this*, I can find out. - Karen: we need more comments on the mailing list for this document before we decide whether it should be a working group document. Measuring NTP from multiple vantage points ========================================== Slides: https://datatracker.ietf.org/meeting/interim-2020-ntp-03/materials/slides-interim-2020-ntp-03-sessa-measuring-ntp-from-multiple-vantage-points Presenter: Watson Ladd Summary: - Overview of field experience from Cloudflare based on measurements. Discussion: - Karen: any other operators on the call would like to comment about what they do for measurement? - Ragnar: we have not done any measurements. - Karen: this is a bit outside the scope of the working group, but we encourage such discussion in the working group. We encourage more deployment experience. - Miroslav: I wonder if anyone has analyzed the effect of NTS on stability. - Watson: from what we saw there is no difference. I will share data with the WG later. - Dieter: I believe Martin Langa did some measurement about this on the internet. I can ask him to send some data to the WG. - Karen: that would be helpful. - Karen: in the past we used the hackathon to make progress in the NTS specification. I am not sure whether a hackathon will take place in the near future. There is a need for testing and measurement tools. We need to help new deployments figure out what is going on. - Watson: we have some code that may help NTP observeability. Not sure if we published it. Will look into it. - Karen: right, we need to consider measureability more in the future. NTS Deployment ============== - Karen: we would like people to say whether their implementations comply with the new version of the draft. NTPv5 ===== - Karen: we have a Wiki about NTPv5 (links to the Wiki can be found below). It is time for people to start putting together drafts. NTP WG Wiki https://trac.ietf.org/trac/ntp NTPv4 Issues https://trac.ietf.org/trac/ntp/wiki/NtpVersionFourIssues NTPv5 Feature Requests https://trac.ietf.org/trac/ntp/wiki/NtpV5FeatureRequests - Danny: we need to make sure that the protocol packet is at least compatible with NTPv4 so that applications that do not understand NTPv5 can respond. - Watson: but the server can always respond with NTPv4. - Daniel: the only requirement is to be able to parse the version field by old implementations. - Danny: right, but we still need to require it. - Watson: so we need version negotiation to work. - Danny: a v5 server will need to see which requests it receives. It should be in the requirements. - Erik: all packet size concerns apply here. - Danny: I expect v5 packets to be larger. - Erik: it is interesting to know what may or may not be forwarded by existing networks. - Daniel: I have a preliminary version for the NTPv5 packet format. Not sure if other people will be able to understand that. - Karen: please review the Wiki, and it is time to start writing drafts. TICTOC Update ============= - The Enterprise Profile draft is ready for the IESG. - There is a new draft that introduces a Synchronous Ethernet YANG model:   https://datatracker.ietf.org/doc/draft-jiang-tictoc-syncphy-yang/ - We were planning to close the WG after the Enterprise Profile draft is done. AOB === - We will have another virtual interim in May. We now need AD approval for virtual interims. - Danny: does our meeting time fit other places in the world such as Asia? - Karen: right, we will need to find a time that fits most people, and we may need to move around the time. - Rich: maybe we can try to poll on the mailing list to see the best time. - Doug: there is no time that works for America, Europe and Asia at the same time. Maybe it is possible to record and make it available for people who are not able to join. - Karen: not sure there is a place in the Datatracker for recordings. - Doug: it may be enough to have the recording available for a short time. - Karen: another issue we need to consider on is minutes. - Denis: we may try to find out before the meeting who plans to show up. - Karen: right, a poll may be useful. - Doug: it would be a good idea to check the IEEE 1588 calendar to avoid conflicts. - Karen: the IETF is trying to be more inclusive in these meetings. Most of the work is still done on the mailing lists. - Karen: any other business? - Ragnar: regarding measurements of NTP connectivity, I hope you have all seen Steven’s work, the latest presentation seemingly being: http://www.leapsecond.com/ntp/NTP_Suitability_PTTI2020_Revised_Sommars.pdf - Karen: we will try to have more interim meetings in May and June. Adjourned at 16:35 UTC.