Minutes interim-2017-ntp-03: Tue 12:00
Network Time Protocol
||Minutes interim-2017-ntp-03: Tue 12:00
NTPWG INTERIM MEETING
Karen O'Donoghue, Dieter Sibold, Ragnar Sundblad, Kristof Teichel,
Miroslav, Rob Nagy, Harlan Stenn, Tal Mizrahi, Dave Mills, Sam Weiler,
Daniel Franke, Denis Reilly, Rich Salz, Richard Welty, Martin Burnicki,
Doug Arnold, Stevo
Administrative and Agenda Bashing (Chairs)
Karen presents the Note Well
NTP WG Agenda
Karen presents the agenda. No agenda bashing.
Network Time Security
- Daniel: Martin Langer prepared flow diagrams for NTS. However, they
are to detailed to be incorporated into the specification. It is
intended to reduce them to be appropriate for inclusion. Hopefully,
this can be done before Christmas. Martin Langer's flow diagram will
be made accessible at NTS's GitHub repository.
- Dieter: Kristof started a mail thread on the NTP WG list to discuss
some of the comments we've got from Sharon during the last WGLC.
However, up to now there have been no feedback.
- Karen: How close we are to a new WGCL?
- Dieter: A new version of the document might be available in
- Daniel suggest to leave the document in a stable state until the
Hackathon in March and wrap-up the WGLC until we have a
- Karen's summary: a new version in January, a Hackathon meeting in
March and after that finalization of the document.
- Kristof: A normative issue might be the request to make the cookie
format more normative.
NTP Interleaved Modes
- Miroslav uploaded a new version which considers Kristof's comments.
- Servers do not need to save state for clients which don't use
- Changes are introduced to the symmetric mode
- Karen: WG adoption call will be issued. Anybody on this call who a
opposed to WG adaption of this draft? Nobody.
NTP Extension Fields
Network Time Protocol Version 4 (NTPv4) Extension Fields
- Harlan: this is out for a couple of years old. RFC 7822 is
overreached and badly designed. The goal of this document is to
maintain compatibility with old implementations of NTPv4.
Incorporates useful new flag bits.
- Karen: this version of this draft is from 4th Nov. Are there
question for clarifications of this draft?
- Danny points out that stealing bits from the EF for other purposes
is a really bad idea. From a protocol point of view this will cause
- Harlan points out that bits are taken from the EF field type field
- Danny: These bits are conflicting other EF related documents.
- Exchange between Harlan and Danny about the evidence of this claim.
Danny points out that he already provided a description of potential
conflicts to Harlan.
- Karen: Are there other questions for clarification?
- Daniel: What is the intension of the legacy MAC required bit?
- Harlan: RFC 5905, Sec. 7.5 states clearly that if an EF is presented
it must be protected by a MAC. RFC 7821 is the only other EF related
RFC which states that this EF cannot be protected by a MAC. This
draft introduce the legacy MAC required bit in order to provide
efficient parsing of incoming packets.
- Daniel ask what will happen of a MITM will alter this bit.
- Harlan: That depends. If an association is meant to be MAC protect
the packet would be dropped.
- Kristof: If the association expect a MAC why do I have the bit to
- Harlan: This is for the parser to increase efficiency.
- Danny: Efficiency of the parser is not the point in a protocol.
- Somebody: This sounds like a downgrade attack
- Danny: Two EF with different settings of the bit flags will cause
- Harlan asks how often this is going to be happened
- Danny: Anybody who wants to perform a attack is going to do this.
- Harlan states that this might happen in the Internet but within a
enterprise network the network control mechanisms will protect
against such attacks.
- Kristof: If there no attacker why requiring a MAC?
- Harlan: Because 5905 requires MAC protection for any packets with EF
and 7821 requires that there is no MAC.
- Tal: The sentence in 5905 (Sec 7.5) who requires a MAC if the
packets contains a EF is updated by an erratum.
- Harlan claims that this erratum is done wrong.
- Tal points out that right now this erratum is valid and it doesn't
state that there has to be a MAC.
- Somebody ask for clarification what specs are addressed by the RFC
numbers. Harlan provided a short overview of 5905, 5906, 7821.
- Tal: Harlan's draft has two main messages. The first: changing the
parsing logic, basically to cancel the minimum 28 byte EF length.
Secondly: taking some of the bit of the field type and allocating
these bits for different purposes which would probably require
changes in the IANA registrations. There are two separate questions
of whether the first or second or both parts are required.
- Danny supports Tal's statement.
- Karen ask for further opinions
- Martin Burnicki acknowledges that Harlan's proposal is more detailed
and clearer and therefore prevents implementers to provide buggy
code. Does it make sense to have a requirement that forbids the
intermix of old and new EF?
- Harlan doesn't think that this is necessary because he don't expect
that RFC 5906 will be around for much longer. NTS will be used for
packet protection and the extended information EF - if the document
will pass - for the TAI-UTC offset.
- Daniel states that the proposed parsing algorithm leaves an
acknowledged ambiguous case and leaves it to the the implementers
how to interpret this case. Daniel does not think this is acceptable
for the WG to publish. Protocols need to be unambiguous.
- Harlan disagrees. The proposal describes how to avoid unambiguity.
It is the choice of the implementation and deployment people to
- Daniel states that this approach form his point of view is
- Harlan again disagrees and insists on the possibility for a local
- Daniel points out that two implementations with different policy
choices are unable to interoperate.
- Harlan agrees. But from his point of view this will happen very
- Martin compare this approach with the acceptance rules of ssh keys
- Harlan again addresses the small likelihood for unambiguity if the
parsing rules of his proposal and what is specified in 5906 are
- Tal suggest that Harlan's draft should explicitly require that any
symmetric keys should have a keyid which is less than 64 k.
Currently it does not formulate this as a requirement.
- Harlan is not sure if this is necessary but it could be done.
- Tal: otherwise he agrees with Daniel that if people apply keyid
larger than 64k it won't work.
- Harlan again stresses the small probability of such an collision.
- Karen ask to incorporate Ta's suggestion.
- Harlan will check if this is possible
- Karen: any additional questions for clarification?
- Miroslav: Is the last EF draft a requirement for this draft to avoid
the unambiguity in parsing? The example parser doesn't seem to use
it. Is it a requirement that the implementation has to understand
the last EF draft?
- Harlan: no
- Danny: the last EF draft should only state that there is an legacy
MAC and its length is x. That should it be rather the current
- Harlan disagrees.
- Discussion between Danny and Harlan of the usefulness of the last EF
- Karen interrupts the discussion.
- Karen comes back to Martin's point about legacy vs new EF. It is
planned to obsolete RFC 5906.
- Daniel: the IETF way is to publish a new informational document that
describes the problem of the old document and states don't use it
- Karen: any other questions?
- Kristof: Why is the legacy MAC required bit necessary?
- Harlan stresses that is proposal is consistent with 7821, 5905, 5906
and 7822. Harlan claims that 7822 introduced a big hole in not
requiring a MAC if a EF is present.
- Kristof asks how is Harlan's proposal better than 7822? He claims
that the introduction of the MAC required bit does not improve
- Some discussion between Kristof, Harlan, Martin, Daniel and Danny
about this issue.
- Kristof does not feel that his questions is answered.
- Karen has the impression that persons talking past other and
questions are not answered.
- Karen: This proposal is an individual submission. The next step is a
call for adoption by the WG. Who is in favor for adopt this as a WG
draft? Two persons are in favor for adaption.
- Daniel suggest to submit a call for WG adoption to the WG mailing
- Karen will do the call and ask for short and precise comments.
- Harlan ask if this call is for the EF draft only?
- Karen: Yes, because of its importance to 7822.
- Harlan points out that his other EF related drafts depend on this
- Daniel replies that some of the EF draft does not fundamentally
depend of this draft but also can be adapted to 7822.
- Discussion with open end on the dependence of EF drafts and Harlan's
proposal between Daniel and Harlan.
Network Time Protocol Extended Information Extension Field
This EF transports extra information such as:
- TAI-UTC offset
- Interleave mode
- maybe leap second correction
Network Time Protocol I-Do Extension Field
- What am I be able to process?
Network Time Protocol MAC/Last Extension Fields
- Includes either a MAC or a signature or or a set of MACs in
- Last extension field
Network Time Protocol Suggest REFID Extension Field
- IPv6 hash value
Karen will send a single email and ask for comments of the different EF
NTP Correction Field
- Miroslav: There is a new version of the correction field draft. It
addresses some of the comments raised by Tal.
Network Time Protocol REFID Updates
Open work items (No updates since IETF 100):
Message Authentication Code for the Network Time Protocol
- will be an update coming up shortly
NTP Client Data Minimization
- Deny ask for refreshing the draft.
- Karen: Yes, this is appreciated.
A YANG Data Model for NTP
- no updates
Guidelines for Defining Packet Timestamps (Mizrahi)
- no updates. An update should be presented soon.
On Implementing Time
- Kristof added as editor.
Open work items
No updates since IETF 100
IEEE 1588 Enterprise Profile
- no updates
YANG data model for IEEE 1588v2
- no updates
- Updates for NTS and preparation for the Hackathon
- Extension fields
- An additional Interim in January (mid to late January)
- Are there preferences between Webex and ZOOM? Daniel would prefer
Meetecho. Karen not sure how to use it between meetings.