2018-08-30 NTP/TICTOC INTERIM MEETING 1. Administrative and Agenda Bashing Minutes: Sam and Dieter Sibold Attendees: --------- Karen O'Donoghue , Daniel Franke, Dave Mills, Dieter Sibold, Miroslav Lichvar, Jeff Prillman, Kristof Teichel, Marcus Dansarie, Ragnar Sundblad, Rich Salz, Samuel Weiler, Stevo, Harlan Stenn, Denis Reilly - 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) https://datatracker.ietf.org/doc/html/draft-ietf-tictoc-1588v2-yang https://tools.ietf.org/html/draft-ietf-tictoc-ptp-enterprise-profile 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) https://datatracker.ietf.org/doc/html/draft-ietf-ntp-mac https://datatracker.ietf.org/doc/html/draft-ietf-ntp-bcp https://datatracker.ietf.org/doc/html/draft-ietf-ntp-mode-6-cmds https://datatracker.ietf.org/doc/html/draft-ietf-ntp-yang-data-model - 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 been 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) -------------------------------------- https://datatracker.ietf.org/doc/html/draft-ietf-ntp-using-nts-for-ntp 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 encrypted 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 amplification. - 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 what 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 host 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) -------------------------------------------- https://datatracker.ietf.org/doc/html/draft-ietf-ntp-data-minimization 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 issue. 6. Additional possible agenda items depending on status and updates ------------------------------------------------------------------- 6.1. Guidelines for Defining Packet Timestamps ---------------------------------------------- https://datatracker.ietf.org/doc/html/draft-ietf-ntp-packet-timestamps - Karen: there was ambiguity in last minutes and difference in understanding. - 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 -------------------------- https://datatracker.ietf.org/doc/html/draft-ietf-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 right. - 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. (50:30) 6.3. REFIDs ----------- https://datatracker.ietf.org/doc/html/draft-ietf-ntp-refid-updates - 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 ------------------------- https://datatracker.ietf.org/doc/html/draft-mlichvar-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 ----------------------------------------- https://datatracker.ietf.org/doc/draft-stenn-ntp-extended-information/ - 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. https://datatracker.ietf.org/doc/draft-stenn-ntp-i-do/ https://datatracker.ietf.org/doc/draft-stenn-ntp-mac-last-ef/ https://datatracker.ietf.org/doc/draft-stenn-ntp-suggest-refid/ - Karen: the additional EF proposals are you going to bring them in compliance with 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 Discussion - Daniel: this protocol doesn't work. In particular the attempts to establish trust 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 establish 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 please 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 the 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 NTS WGLC. 8. AOB - Karen: possible virtual meeting Oct 8th or 15th