[Ntp] Minutes from the last NTP Interim Meeting (2019-09-10)

Dieter Sibold <dsibold.ietf@gmail.com> Mon, 14 October 2019 11:37 UTC

Return-Path: <dsibold.ietf@gmail.com>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B48C3120043 for <ntp@ietfa.amsl.com>; Mon, 14 Oct 2019 04:37:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 583D3tb4Zxhy for <ntp@ietfa.amsl.com>; Mon, 14 Oct 2019 04:37:32 -0700 (PDT)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B74312001E for <ntp@ietf.org>; Mon, 14 Oct 2019 04:37:24 -0700 (PDT)
Received: by mail-ed1-x534.google.com with SMTP id r4so14511667edy.4 for <ntp@ietf.org>; Mon, 14 Oct 2019 04:37:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:thread-topic:thread-index:date:message-id :accept-language:content-language:content-transfer-encoding :mime-version; bh=wRJTFLOl7KQjIPq+Ols+9wNxeBOX2AjAXJ7J/pWgQ88=; b=RYaKrNcS7SWofNnisGABU+hKrj5Xmr4vGzkl2ZjeHlqnGfEq8YsBpFtRGxECGjxrrY er5bUpTTGjZ1QUhf3XnOEPuEYaUI+6mqR/yjcKeoB1mNHFrixbRuPu9pn6dVSeAF+gIt fhQDl9Ar3tmDwZJ+j6BYXD08D2MDMyfiRjTvsVh0szbNOLKdLZbCPdFTs1kB0ZaKqG91 04uZnyy06vMVtzMLJvS6MAgqwK3RDu2FEbdKT8LX3Onj1VNwrsCzqBZ13BMTiV+a74+o XDLxE24963o9Bfb78WXeTkffqCOp2QWtk+YlwpM6EL9py99W6xf+AQnvZyEuEbQTjR7j 4WuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:accept-language:content-language :content-transfer-encoding:mime-version; bh=wRJTFLOl7KQjIPq+Ols+9wNxeBOX2AjAXJ7J/pWgQ88=; b=FPYJKYoJJOvNH1uE9d5kriwshT02og8TQYzRKsKsiou7xcHEo8HZvO54gO2g1eNgB9 szcWozNg53euL4NtOI/c3lnxK7Lv1Vt0kr4p3Thiid6S8h1+VPO89Yj8va+DpD8QYEO/ PjkUb+wJAg6fW8QNXLV2QmRnooDx6nZHavIb4Z6akSbieXZ4FYzW5f1dr3Kql/G7sLHy QF8wMWpfJXZ2e1B4GFYI6itOoSoOIhk1LcSww9iVeDavuEU1fC29igCgFxlCVe6yczaB 98SLKhe4woDk9obLVhASAuMXriBr7Pv3SZ1Rx2xqQob95oN9yMZiDc5dcGKbqqL/YlG2 v2Cg==
X-Gm-Message-State: APjAAAWzK/mEORbIVbsswL1zaT/sUD9UuqHRxieCIhn/nFr7FjnWhy+u 3+rt78CqwXs5NGiSzL9WIhpPI3iY
X-Google-Smtp-Source: APXvYqx6iI37ffC4EYkS/CMXX8V9vc7A0/b+kNlLMoQu1TNUxFNkPD39bc/1XFJ+F6OzfCU7yHQ8dw==
X-Received: by 2002:a17:906:4948:: with SMTP id f8mr27568292ejt.318.1571053042340; Mon, 14 Oct 2019 04:37:22 -0700 (PDT)
Received: from AM0PR08MB4546.eurprd08.prod.outlook.com ([2603:1026:207:143::5]) by smtp.gmail.com with ESMTPSA id j43sm3125727eda.19.2019. for <ntp@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Oct 2019 04:37:21 -0700 (PDT)
From: Dieter Sibold <dsibold.ietf@gmail.com>
To: "ntp@ietf.org" <ntp@ietf.org>
Thread-Topic: Minutes from the last NTP Interim Meeting (2019-09-10)
Thread-Index: AQHVgoO9dep/YVB9/UKrNvEAkdGgqg==
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Mon, 14 Oct 2019 11:37:20 +0000
Message-ID: <AM0PR08MB4546AF0FDC514F8074C7CC32F8900@AM0PR08MB4546.eurprd08.prod.outlook.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Exchange-Organization-SCL: -1
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/xud6SCdKsaqsWh2X6kO7657YAIA>
Subject: [Ntp] Minutes from the last NTP Interim Meeting (2019-09-10)
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Oct 2019 11:37:35 -0000

Dear all,
below, please find the minutes from the last NTP Interim meeting. 


NTP Virtual Interim
September 10th, 2019
15:30 UTC
Meeting Minutes

Karen O'Donoghue
Dieter Sibold
Daniel Franke
Tal Mizrahi
Marcus Dansarie
Steve Sullivan
Watson Ladd
Denis Reilly
Kristof Teichel
Marcus Dansarie
Danny Mayer
Miroslav Lichvar
Rich Salz

Chairs: Karen O'Donoghue, Dieter Sibold
Minutes: Tal Mizrahi

Chair Slides
Presenter: Karen O'Donoghue

- Note well was presented.
- The agenda for the current session was presented.
- Discussion about call for adoptions will take most of the time.
- Some discussion about NTPv5 is expected.

WG Document Status:
- Guidelines for timestamps and NTS drafts are ready to be submitted to the IESG, and will be submitted to the IESG in the next 24 hours.
- The YANG model is ready for WG LC.
- Data Minimization has been through WG LC, and there are some comments. Will be moving this draft to WG consensus, and then send it to the IESG.

Interleave Mode Draft
  - Miroslav: it passed last call.
  - Daniel: I was the only one who objected.
  - Karen: Daniel's objection is noted, and we are moving on.

Port randomization Draft
  - Karen: There was quite a bit of discussion. Does anyone have anything to comment?
  - Danny: the draft does not do anything for the protocol itself in terms of securing it. If we want this document we should actually improve security, and not just write a BCP. 
  - Daniel: Watson had the most notable comments here. Even when we use NTS the port randomization is an issue.
  - Watson: right, annoying from a DoS perspective.
  - Danny: can you explain?
  - Watson: you cannot have a firewall that limits the number of responses. It is difficult at the network layer.
  - Danny: that needs to be laid out as an issue.
  - Watson: can NTS clients randomize the port?
  - Daniel: yes, NTS clients can randomize.
  - Danny: in NTPd, the source port is used for filtering and reconciliation.
  - Daniel: there is nothing in the draft that says you need a random port for every request you generate.
  - Danny: we need to clarify that in the draft, and make sure we know what we can and cannot do.
  - Karen: two question here - what do we think about the latest draft, and whether we want it to be adopted. Danny - do you think it should be adopted?
  - Danny: my opinion is it should not be about port randomization, but rather more generally about security.
  - Karen: so what are the other pieces?
  - Danny: Miroslav brought this up - the timestamp should be a local thing, and when you get a response you should match it to the timestamp.
  - Daniel: not in the minimization draft.
  - Danny: but it should be there.
  - Karen: we are wrapping up a few loose ends with NTPv4, and getting NTS published. Maybe this should be just a loose end to tie before we move on to NTPv5. Do you think this should wait for NTPv5?
  - Danny: not sure. We need to look closely at what we are doing. I have not looked at the latest draft.
  - Karen: we just published the NTPv4 BCP. The combination of the BCP and port randomization could work. What do people think about this?
  - Denis: I think this document should be adopted. Some issues can be handled in NTPv5, but it will take a while. As it stand, this document is important.
  - Karen: from a WG perspective, we need to work on what people are willing to make contributions on. In NTS for example - it does not solve all the problems, but it did serve a client. At this point I do not see the willingness to do all we should be doing in this context.
  - Denis: so if there are people who are willing to work on this document, we should take advantage of that now.
  - Karen: right.
  - Watson: if the goal is mitigate on-path attackers, then the port randomization draft does not seem like a major change in what is already done, so I think we should move forward with it.
  - Danny: let's notice that it is very easy to find out what the port is. You will end up with just a few port numbers. It is pretty easy to figure out which port is used.
  - Watson: but you bind the port to the server. Any other port will not produce a response.
  - Danny: only if you close the port.
  - Daniel: Watson is right. A port scan will not tell you what source port the client is using.
  - Danny: you can query the client to find out the port.
  - Daniel: the client is not going to get the packet.
  - Miroslav: it will not even reach the client if it is not from the right IP address. The draft should recommend using POSIX system. This will prevent getting responses from wrong addresses and ports.
  - Karen: the consensus on the mailing list was to adopt. From a WG perspective we are going to adopt it, and continue to improve it. We will move the draft status to accepted, and ask for more reviews and comments.
  - Karen: our recent calls for WG adoption - Dieter and I have looked at the emails.

Chronons Draft
    - Karen: we have WG consensus to adopt it as an experimental draft. Any comments about that?
    - No comments.

Roughtime Draft
    - Karen: we have WG consensus to adopt. There are some comments on the list.
    - Daniel: I am in favor of adopting. People have a misconception about what the draft does. It does not even set the local clock. I originally thought it was not in our charter. It needs to be adopted.
    - Karen: we need to re-charter.
    - Daniel: it is not just a formal issue of what is in our charter. I believe the NTP scope and the Roughtime scope are distinct.
    - Karen: we will adopt it and move forward.

Extension Field Drafts
- Karen: at this point there is no WG concensus to adopt these drafts. Harlan is not on the call. The documents are not adopted.

NTPv5 Discussion:
- Karen: Miroslav created a page with a list of issues for NTPv5. A link to the page was sent to the mailing list.
- Daniel: I added a few issues to the Wiki.
- Karen: you may want to add your name to the issues as you add them. NTPv5 is not a clean slate protocol. Somewhere between minor tweaks and clean slate.
- Daniel: I think we have a clean slate, other than considerations given existing implementations.
- Karen: more contribution would be welcome.
- Tal: what is the scope here? Resolving open issues / adding new features?
- Karen: the scope is what we are looking to discuss in the Wiki.
- Danny: one of the biggest problem is the MAC, which does not have a length field.
- Watson: one could imagine adding an extension with a length.
- Danny: right, that was proposed, along with the Last-EF.
- Daniel: right, but we are looking for the least clumsy thing we can think of.
- Danny: right. With an extension field you can have multiple MACs. There are other things that Miroslave listed.
- Karen: we started the Wiki, and between now and the next meeting people can review and suggest items, and then we can discuss them. We seem to be gaining momentum for NTPv5. First we need to think what we want to do here. Another way to go is that someone who is interesteed can start to actually work on it. We also want to move NTP to a full standard.
- Daniel: I do not agree. If we move forward with a new protocol, it is an argument against moving to a full standard.
- Karen: right. When we get to a point where we understand whether it is a significant change we can reconsider this question.
- Watson: RFC5905 discusses one synchronization algorithm. It is useful to have an example of a synchronization algorithm.
- Miroslav: some implementations use a completely different algorithm. It would be better to specify general requirements.
- Karen: I originally wanted to separate the protocol from the algorithm. The algorithm can be informational. We can use different algorithms. Actually it was the case at one point.
- Danny: the protocol and algorithm are intertwined. It is not trivial to pull them apart.
- Karen: it will not be easy, but it is done for example in IEEE 1588.
- Danny: it is not that simple.
- Karen: but needs to be done.
- Daniel: I would like to see an example of two algorithms that work well, but blow up when both operate in the same network. I can see it in TCP, but not in NTP.
- Watson: if estimate the first derivative, that work well, but if you do that twice in a row it becomes very unstable.
- Danny: I agree, but we will not be able to resolve it here. It is a very complicated discussion.
- Karen: we need a few people who are interested to work on the text. The spec says a few things that nobody implements and still implementation work well. 
- Karen: thanks Miroslav for the Wiki.

- Kristof: when we changed the scope of NTS, we suggested to document the design guidelines. People who implement basically deal with the same problems. I wonder whether this should be compiled into an internet draft.
- Karen: any document that pulls together some of the issues we had would potentially be useful.
- Miroslav: could this be used for symmetric mode?
- Kristof: no. More along the lines of broadcast, and also using NTS a bit similar to NTP MD5.
- Danny: I would recommend an informational document.
- Kristof: so I will write something up.
- Karen: send it to the list and see what feedback you get.
- Karen: any other AOB?

Next Meeting
The week of October 14th.

Adjourned at 16:30 UTC.