Skip to main content

Minutes interim-2020-ntp-03: Mon 15:00

Meeting Minutes Network Time Protocols (ntp) WG
Title Minutes interim-2020-ntp-03: Mon 15:00
State Active
Other versions plain text
Last updated 2020-04-06

NTP Virtual Interim
April 6th, 2020
15:00 UTC
Meeting Minutes

Chairs: Karen O'Donoghue, Dieter Sibold
Minutes: Tal Mizrahi

Virtual meeting material:

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

Presenter: Karen O'Donoghue

- 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

- 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.

- 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.

Presenter: Tal Mizrahi

- 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.

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

Presenter: Watson Ladd

- 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.

- 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.

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.

- 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

Measuring NTP from multiple vantage points
Presenter: Watson Ladd

- Overview of field experience from Cloudflare based on measurements.

- 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.

- 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 NTPv4 Issues NTPv5 Feature Requests

- 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.

- The Enterprise Profile draft is ready for the IESG.
- There is a new draft that introduces a Synchronous Ethernet YANG model:
- We were planning to close the WG after the Enterprise Profile draft is done.

- 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: -
Karen: we will try to have more interim meetings in May and June.

Adjourned at 16:35 UTC.