Minutes interim-2018-ntp-01: Thu 16:00
Network Time Protocol
||Minutes interim-2018-ntp-01: Thu 16:00
NTP/TICTOC INTERIM MEETING
1. Administrative and Agenda Bashing
Minutes: Sam and Dieter Sibold
Karen O'Donoghue ,
- Karen: any objections to this meeting bring recorded? [no objections]
- Karen starts the meeting with the Note Well
- Agenda Bashing
2. TICTOC STATUS
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.
3. NTP STATUS
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
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
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
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
- 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
- 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.
- 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
- 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
- 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
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
- Karen: possible virtual meeting Oct 8th or 15th