Network Time Protocols (ntp) working group @ IETF 121

Monday, 4 November, 2024
17:30 - 19:00 GMT (UTC)
Liffey MR 3

1. Draft Agenda

Administrative and Agenda Bashing (Chairs)

2. NTP/TICTOC Document Status Review and Update

RFC Editor Queue

• https://datatracker.ietf.org/doc/draft-ietf-ntp-update-registries/
• https://datatracker.ietf.org/doc/draft-ietf-tictoc-ptp-enterprise-profile/

Awaiting author update

• https://datatracker.ietf.org/doc/draft-ietf-ntp-interleaved-modes/

This document requires updates from the author in response to received
comments.

Shepherd writeup

• https://datatracker.ietf.org/doc/draft-ietf-ntp-over-ptp/

Discussion

Eric is going to close the TICTOC WG as soon as the Enterprise Profile
is done.

3. Hackathon update

NTPv5 (David)

• During the hackathon, we focused on the following topics:

  • Enabling NTPv5 by default through improved implementation.
  • Implementing a fallback mechanism in case NTPv5 fails.

• Clarifications are still required in certain sections of the NTPv5
  specification.

• I am interested in learning if other implementors, such as Chrony or
  NTPsec, are also working on NTPv5 implementations.

Discussion:

• Miroslav: My implementation is still in an experimental state. I did
  not do any work to integrate it into Chrony. I'm uncertain whether
  the design is finalized, and I would like to avoid complete rewrites
  because of potential design changes.
• Karen: The Hackathon website has links to the repositories of all
  NTPv5 implementations. See:
  https://wiki.ietf.org/en/meeting/121/hackathon

Roughtime (Marcus)

Presentation:
https://datatracker.ietf.org/meeting/121/materials/slides-121-ntp-summary-of-roughtime-work-at-hackathon-00

Discussion:

• Erik: Not a question but a note. Whenever you want a Security
  Directorate review prior to the working group and IETF last call, we
  can arrange for that. This might help to find security issues at an
  early stage.
• Karen: Thanks to David, Marcus, and Ruben for their activities.

4. NTPv5 Requirements draft (Karen)

https://datatracker.ietf.org/doc/draft-ietf-ntp-ntpv5-requirements/
This is close to being done. It has been moved to the NTP's GitHub
organization. There are some remaining issues. We need to decide within
the next month what to do with this draft and how we will move it
forward. We will follow up with the authors on that.

5. NTPv5 Protocol Document (Miroslav)

https://datatracker.ietf.org/doc/draft-ietf-ntp-ntpv5/
There are some changes in the version on GitHub prepared for the next
version of the draft.

• The Leap second indicator, which has now a value for unknown and the
  original unsynchronized value, is now a flag. This flag is set when
  the server is synchronized. Clients have to check this flag.
• The Refid for reference clocks are not specified. They are included
  in the Bloom filter that allows clients to identify the source of
  the time.
• The usage of SHOULD needs to be reviewed. There may not be enough
  context to explain the SHOULDs. Either provide more context or
  replace SHOULDs with MUSTs.
• One implementor proposed to improve the handling of the extension
  fields.
• Also, there remains a lot of editorial work to be done.

Discussion

• Karen: Please review this draft. It will be challenging to finalize
  it without proper reviews.
• Benson: The draft includes a section that discusses various methods
  for comparison and statistical means (different round trip
  measurements between client and server) to calculate the most
  accurate time. Are you looking for other methods as well, or just
  the one from IEEE 1588 as a new method?
• Miroslav: Are you referring to the approach used in PTP broadcast
  mode?
• Benson: My question is, are there other approaches worth to be
  considered?
• Miroslav: I'm not aware of any other approach.
• David: Benson, I would guess you are referring to the algorithmic
  side of the NTPv5. One of the goals of NTPv5 is be only normative on
  the on-wire protocol. The section you are referring to outlines how
  to achieve this, but it does not mandate this approach. There are,
  of course, other interesting ways to do this. I would suggest
  staying with this decision not to include the algorithm part of NTP
  in this document. We could draft a separte document to describe
  clock steering algorithms. Personally, I think that an RFC is not
  the most suitable format.

6. Roughtime (Marcus)

https://datatracker.ietf.org/doc/draft-ietf-ntp-roughtime/
Presenation:
https://datatracker.ietf.org/meeting/121/materials/slides-121-ntp-roughtime-issues-and-discussion-points-00

Discussion:

• Karen: Rough idea about how close to WGLC
• Marucs: Some issues may be fixed fast. Some needs some more work.
  One iteration may be necessary.

7. NTS for PTP

https://datatracker.ietf.org/doc/draft-langer-ntp-nts-for-ptp/

• Martin: The implementation work is progressing, however, slower than
  planned. First test likely towards the end of this year or the
  beginning of next year. I intend to participate in the Hackathon mid
  next year in Madrid for additional testing.
• Martin: Regarding the draft document: There are no updates yet. A
  major update is planned for February next year. There are some
  simplifications in the protocol processes and additional small
  changes.
• Martin: The new version of the draft document will also be provided
  on the NTP's Github organization.
• Martin: IEEE's P1588 security subcommittee: Securing PTP messages
  requires the transport of data which is currently not supported by
  the PTP's authentication TLV. Rainer B. Steffen F., and I are
  working to enhance the authentication TLV. A first proposal has been
  submitted which shall be discussed at the next meeting of the P1588
  security subcommittee. This enhancement ist necessary for the IETF
  draft document.

Discussion

• Karen: I will provide a brief overview of the overall status of 1588
  later.

8. NTS extensions for enabling pools (David)

https://datatracker.ietf.org/doc/draft-venhoek-nts-pool/
Last year we made a first draft of a client-transparent version of a NTS
pool; i.e., what is needed to support that. Since then, there have been
only minor changes.

Most of the discussion in the mailing list is about whether this is the
right approach and whether there are other approaches as well. We have a
reasonable view of the options.

Open questions remain. Primarily, is it feasible to run a pool with the
pool providing the NTS servers and NTS KE, or is this load too high?

Ruben and I are looking for funding to start the implementation of a
pool with parties that have already indicated they will provide servers.
Our goal is to gain operational experience. With that experience, we
want to proceed with the draft document. Our current draft describes a
pool that manages NTS servers as well as NTS key establishment.
Alternatively, others may draft a document for pools using different
approaches.

Discussion

• Ask: I run an NTP pool. Currently, about 500,000 DNS queries per
  second. Will those numbers correlate with the number of NTS KE? I’m
  worried about putting more computing logic towards the
  non-distributed part of the pool.
• David: We are looking at that. 500,000 DNS queries are less than
  what I expected. The problem with these numbers is that there might
  be DNS caching in places you probably don’t judge.
• David/Ask: DNS TTL is set to a few minutes.
• Ask: The number of DNS queries depends linearly on the TTL value.
• David: Part of what we want to investigate is whether this is going
  to be reasonable. Millions of seconds is in a doable category for
  TLS. There might be reasons why we might find this approach more
  interesting than others. Our goal is to get experimental experience
  with it.
• Ask: I fully support that. The current NTP pool is run by very few
  people. Its design allows for a lot of things going wrong without
  impeding the service. The NTS KE seems monumentally more complicated
  to keep running than a highly distributed DNS service. That is my
  feedback on the current draft.
• David: Yes, there are challenges here.
• Marcus: When we designed NTS and did the decoupling of key exchange
  and time exchange, we did that in order to ensure that the time
  exchange works even if key exchange does not work. Ideally, the
  client should do the key exchange only once. So the availability
  requirements for the key exchange server should be low because only
  new clients will be affected.
• Karen: I marked the draft document as a candidate for WG adoption. I
  know there are other proposals to solve that problem. I think it is
  a good idea to experiment with it. It is possible to publish an
  experimental RFC. Or we have drafts with other ways to do this and
  to help facilitate the experimentation. Any idea how to forward with
  this draft?
• David: From my perspective, the way forward is to await the
  experimentations. One of the advantages of this draft is that the
  changes are mostly on the server-side of NTS. Experimentation can
  therefore start with a relatively small set of changes. If we have a
  clear view of how we want to move forward with operational pools, we
  might look at adopting the draft.
• Karen: At the meantime we will leave it as a candidate for adoption.
  I strongly encourage people to review it. And if you people have
  other ideas to solve this problem it would be helpful to have other
  drafts submitted.

• 9. IEEE 1588 Updates (Karen)

  This is a quick update on two activities within the 1588 PTP.

  1. The Security subcommittee of PTP is looking at NTS for PTP. They
     are also looking at issues with the authentication TLV that have
     been brought forward by members of this working group. We expect
     to have some corrections or amendments to the authentication
     TLV. And we expect to have NTS for PTP be defined in this new
     context.
  2. There is now a 1588.1 which is CS PTP (Client-Server PTP). This
     is a simplification of PTP in a lot of ways to make it more of a
     client-server model. There is now a CS PTP sub-group. There is a
     draft now that has just begun to be discussed. This group is
     open for contributions from this WG. If you are interested in
     these activities, you can be added to the central desktop. I
     strongly encourage you to follow this work. It has also
     implications for our crossover security work. You can contact me
     if you want further information.

10. Any Other Business (AOB)

• Hope to have an interim in January.
• In December, we will have a call between the NTP and 1588
  security-interested people.
• The next F2F is in Bangkok, Thailand. I think we are not going to
  have a hackathon activity in Thailand.
• The mid-year IETF is in Europe. Good location for the next
  hackathon.
• Adjourned: 18:15