Minutes interim-2017-ntp-03: Tue 12:00

Meeting Minutes Network Time Protocol (ntp) WG
Title Minutes interim-2017-ntp-03: Tue 12:00
State Active
Other versions plain text
Last updated 2018-03-27

Meeting Minutes





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
    January 2018.
-   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
    interleave mode.
-   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
    signal this?
-   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
    avoid unambiguity.
-   Daniel states that this approach form his point of view is
    fundamentally inacceptable.
-   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
    by SSH.
-   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
    broadcast mode
-   Last extension field

Network Time Protocol Suggest REFID Extension Field


-   no-you,
-   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


-   WGLC



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

TICTOC Agenda:

Open work items

No updates since IETF 100

IEEE 1588 Enterprise Profile


-   no updates

YANG data model for IEEE 1588v2


-   no updates

Next steps

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