Minutes interim-2018-ntp-01: Thu 16:00

Meeting Minutes Network Time Protocol (ntp) WG
Title Minutes interim-2018-ntp-01: Thu 16:00
State Active
Other versions plain text
Last updated 2018-09-19

Meeting Minutes



1.  Administrative and Agenda Bashing
    Minutes: Sam and Dieter Sibold

    Karen O'Donoghue ,
    Daniel Franke,
    Dave Mills,
    Dieter Sibold,
    Miroslav Lichvar,
    Jeff Prillman,
    Kristof Teichel,
    Marcus Dansarie,
    Ragnar Sundblad,
    Rich Salz,
    Samuel Weiler,
    Harlan Stenn,
    Denis Reilly

- Karen: any objections to this meeting bring recorded? [no objections]
- Karen starts the meeting with the Note Well
- Agenda Bashing


TICTOC quick document status (documents we hopefully won’t need to discuss)

1588 version 2 Yang is send to IESG. It has been sent to IETF last call.
PTP Enterprise was updated since the last IETF meeting. It will be submitted to
IESG for review. Karen gave an update to Suresh about that document.

After these docuements are finished the TICTOC WG shall be closed and NTP
Carter will be updated to accommodate not only NTP subjects.

NTP quick document status (documents we hopefully won’t need to discuss)

- The updated MAC draft is ready to be sent to the IESG.
- Suresh will send to the BCP, the YANG, and the MAC draft to to the IESG.
- The WGLC for the Mode 6 cmds document has been completed. Last issues have
  resolved. It is waiting to be sent to Suresh.
- The YANG data model for NTP document has been send to YANG doctor review
prior to
  the WGLC.

4. NTS for NTP (pending updated draft)

Some new inputs:
- Results from the Hackathon
- Inputs from Marcus
- Daniel: version 13 submitted. Still has some rough edges.
  - incorpoates most of feedback from Marcus and Ragnar.
  - Added new record types for server negotiation & format changes for
    fields - please review.
  - TODOs include introductory text rewrite & merging NTP pools text.
  - amplification discussion. -13 addresses issue from hackathon regarding
    amplification if client is sending a one-byte nonce. 16 bytes of
- Harlan: so your solution to avoid amplification is to pre-amplify?
- Sam: why are we worried about a 16 byte amplication?
- Daniel: It's greater than zeor. Protocol shouldn't do that .
  Any amplification is not acceptable.
- Dave Mills: wouldn't the problem be a cascade?
- Daniel: I'm not claiming that it can cascade.
- Miroslav: I agree with Daniel that a protocol should not cause any
  amplification - that's common sense.
- Harlan: shouldn't waste space to prevent it.
- Daniel: force the client to do at least as much work as the server.
  To avoid giving leverage for DDoS.
- Harlan: If this is an optional behavior thats great. I don't see benefit in
  seems to be wasting bandwidth.
- Kristof: This doesn't applies other participants as just the server and
client talking
  to each other. This is not a matter of choices for everyone involved.
  There are two people talking and one of them is potentially damaging a third
  party and this party has no choice. Leaving choices is not applicable in this
  case. Also, I agree with Daniel and Miroslav that this is generally a good
  idea. We're doing amplification prevention at multiple points - at each one
  it's just a few bytes.  If we drop them all, we might have a problem.
- Marcus: Ragnar and I agree with the amplification prevention. 16 byte is
about 10%
  of an NTP packet. It is bib enough to be interesting for an attacker. Also,
  most users will use the 16 byte nonce length. In those case there is no need
  for the additional padding.
- Sam: I think this is not a big enough deal to keep fighting it. Harlan?
- Harlan: Okay to let it go.
- Daniel: The other issue I want a review of is just the change I did to the
  negotiation. The IP address is now a host string.
- Ragnar: we plan to have a list of hostnames.
- Daniel: I briefly wrote it up that way, but there is a danger: if the
  client gets a list and associates w/ mutliple on them, it leads to a
  potential of a Sybil attack where one server can assume multiple identities
  and abuse the selection algorithm.
- Marcus/Ragnar: We will study this issue.
- Karen: Next steps: Daniel when will you update the draft.
- Daniel: another update next week.
- Karen: when we get a draft addressing all of these, we'll do a WGLC.
  Another interim in early October, maybe?  Look at doc now, before that
  WGLC - feel free to submit pull requests in the github repository.
- Harlan: I submitted objections or complaints many times that have not
  been addressed.  Should I repeat these again?  I'm kind of tired of it.
- Karen: remind me of your objections other than "we're not solving the
  whole problem"?
- Harlan: we had agreed to use extension field type 4, and while that's
  what we're doing with interop, this draft leaves it to IANA to assing
  random numbers, and that's not going to work.
- Dieter: during WGLC, I replied to each of your comments.  The current
  format of the extension field type is in accordance to RFC7822.
- Harlan: we need to pre-test extension field types to make sure they
  work.  Don't want to update code afterwards.
- Daniel: per RFC, these need to be assigned by IANA.  If we need
  advance assignments ...
- Karen: I authorized early assignment by IANA earlier in this process.
  I've taken that pre-assignment off the table.  If the question on the
  table is not changing assignments, we can make that request again at
  the WGLC stage.
- Daniel: we want to avoid getting those assignments and keep using
  private/experimental range until we're sure we're not making more
  changes to the draft.
- Harlan: what is this private/experimental range?  How does that EF
  types?  The IANA registry does not have an experimental range.
- Daniel: we should fix that.
- Harlan: I'm not sure we should.  Does no good to declare something as
  experimental.  Agreed w/ Karen and Dieter to have internal chalkboard.
- Daniel: you're describing how those are usually managed.
- Harlan: IANA isn't going to do anything we don't ask them to do.
- Karen: there is no internal chalkboard at this time.
- Harlan: let's forget about this for now.
- Karen: our only mechanism for allocating these is the IANA
  pre-allocation mechanism or docs.
- Harlan: your proposal requires that we change things when we go from
  experimental to production.
- Daniel: of course.  The whole point of IANA is not to have mutual
  non-interoperable implementations.  Until we're sure that the format
  is finalized, we shouldn't finalize the number.
- Sam: Harlan, was this the only issue?
- Harlan: no.
- Karen: Harlan, please raise these in WGLC.  We'll track issues in WGLC
  with an issue tracker.
- Sam: break off this experimental / allocation bit into its own discussion.
- Karen: want to have a clear description of any issue. We have the datatracker
  and tools.ietf.org - I appreciate the diff tool.

5. NTP Data Minimization (results from WGLC)

Karen: Results from WGLC. We've gotten no comments.  I intend to extend the
WGLC one week.  Please be specific and propose a resolution when you raise an

6. Additional possible agenda items depending on status and updates

6.1. Guidelines for Defining Packet Timestamps

- Karen: there was ambiguity in last minutes and difference in
- Daniel: we've gone back and forth on the purpose of this doc.  If this
  is "here's what's in use" - no objection to advancing other than I
  think it's redundant.  If these are recommendations, then I'm unhappy.
- Karen: that's clarifies Daniel's position during the last meeting.
  Maybe we should have a mailing list discussion to include Tal
  and Al Morton .
  We need to have a discussion regarding what are the right   recommendations?
- Sam: have recommendations or not?
- Karen: not sure.  Up to WG. The draft did go to originally to another WG
  and then was redirected here. Bottom line is to have a discussion on the
  mailing list about the purpose of this draft. Other WG and other efforts make
  use of timestamps and we want to provide better documentation for them.
  Having not spoken to Al about his underlying motivation.
- Sam: two topics for discussion whether to have recommendations or
  not?  and, if so, what they should be?
- Karen: I liked Daniel's wording.
- Harlan: I agree with Daniel.  If it documents existing practice it is fine.
  It's not enough regarding what SHOULD be done.

6.2. NTP Interleaved Modes

- Miroslav: no changes since last meeting.  In the last meeting there
  was the suggestion from Daniel to save the previous transmit timestamp in an
  EF.  I agree it would have advantages but I don't think that would work
  well with this draft because this document describes what currently is used
  with some smaller changes for robustness.  Goal is to document what's there,
  but not break compatibility with exisiting implementations.  Extension field
  would make packet longer which would increase the delay. This could lead to
  the situation that the average delay in the interleave mode would be longer
  than the delay in basic mode.
- Daniel: interleaved mode is not used widely enough that we should care
  we should be willing to break backward compatibility and just do it
- Miroslav: disagree. It's used and it is working well.
- Daniel: The EF address both the symmetric problems and the NAT problem.
  NAT problem: protocol as spec'ed is broken by NATs.
- Miroslav: it works fine through NATs.
- Daniel: have you tested with a NAT with multiple clients behind it?
- Miroslav: yes.  One implementaion has this problem, but it's not a
  protocol problem.
- Daniel: I disagree.  There's too much ambiguity.
- Miroslav: There is no ambiguity.  The origin timestamp is unique.
  How would EF fix it, if it is really an issue?
- Daniel: EF can carry a session identifier.
- Miroslav: that's the origin timestamp. You don't need an additional
identifier. - Daniel: think that if you run this to a model checker you will
find that an
  additional identifier is needed.
- Miroslav: send an example where is doesn't work. I think it does work;
  there is no issue with NATs.
- Karen: Miroslav, would you kick off an email thread to bring this question
  to the mailing list so that you and Daniel discuss it there?
- No further comments on the draft.


6.3. REFIDs

- Karen: Agreement on the last meeting was to split this document into two.
  Aanchal is supposed to do this effort.
- Harlan: she should talk to me.

6.4. NTP Correction Field

- Harlan: that's on experimantal track, right?
- Someone: yes.
- Miroslav: have a question for these people here.
  Tal suggested we change EF to use the PTP format to make it easier
  for hardware that does PTP.  I think that makes sense.  Two  Issues:
  1. The EF would be longer.
  2. And we'd now mix seconds and nanoseconds, which I think is weird. So
     far anything in NTP is in seconds.
- Daniel: why not use nibi seconds (2^-32)?
- Miroslav: that doesn't help hardware that supports PTP correction field.
  Conversion is between seconds and nanoseconds is expensive.
- Harlan: I don't see that conversion is needed - just addition. The switches
  does not change the base packet.
- Daniel: if leaving it in nanoseconds solves an engineering problem,
  then okay to leave it in nanoseconds.
- Dave Mills: why not use interleave mode for this? If the intent is that you
  compute the timestamp after the packet is sent and include it in the next
  packet. If you can do it fast (e.g. with an FPGA), then you don't need a
  correction field.
- Harlan: these (interleave and this) are two separate proposals.  This
  experimental correction field proposal is to allow switches along the
  away to accumulate the delay they're adding.
- Karen: rough consensus: go with nanoseconds.

6.5. Additional Extension Field Proposals

- Karen: This document was not adapted by the WG.
- Harlan: I updated the EF doc that the WG rejected, and I'd like a do-over.


- Karen: the additional EF proposals are you going to bring them in compliance
  7822 and move them forward?
- Harlan: yes

7.  DTLS email thread

Mills: want to present a alternative view.
       - preserve precise time synchronization performance as possible, i.e.,
       no EF - Concerned about the assumption of infrastructure. The intend of
       my design was
         to be independent on infrastructure such as DNS and PKI.
       - make it clean and simple

- Daniel: this protocol doesn't work. In particular the attempts to establish
  without infrastructure an prior knowledge is logically impossible.
  Without pre-sharing of keys or a trusted authority there is no possibile way
  for the two parties to distinguish them from an adversary.
- Mills presents a very rough description of the proposal
- Daniel: no of the mechanism mentioned as been specified in adequate detail to
  whether this is secure or not secure. Going back to the earlier points. The
  trusted root you are describing is in consistents with the claim that this is
  an infrastructure protocol.
- Kristof: want to support this point.
- Karen: the real question is to move this proposal forward in more detail and
in a
  draft spec.
- Mills:  cannot write it myself.
- Karen: If anyone is interesseted or now people who would be willing to help
  contact Dieter or me.
- Harlan: few issues. one of which is one aspect of Dave's paper is: here are
issues that
  NTS in its current form are not addressing. A separate issue: NTS is assuming
  some functioning infrastructure. The problem is when NTP is coming up this
  assumption is not really valid. But we are building on it. That is one of the
  points Dave is mentioning.
- Daniel: what infrastructure you are referring to that is not functional when
  system boots up?
- Harlan: NTS assumes a third party for key validation without knowing the
correct time. - Karen: want to interrupt. This was already discussed. - Karen:
want to do a WGLC on NTS. I intends to run an official issue tracker for the

8.  AOB
- Karen: possible virtual meeting Oct 8th or 15th