Re: [Ntp] Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts

Heiko Gerstung <> Mon, 02 September 2019 11:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C9F7712011C for <>; Mon, 2 Sep 2019 04:49:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.29
X-Spam-Status: No, score=-4.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sizZ0Y5csie3 for <>; Mon, 2 Sep 2019 04:49:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CD160120052 for <>; Mon, 2 Sep 2019 04:49:24 -0700 (PDT)
Received: from (unknown []) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 357AF71C08F3; Mon, 2 Sep 2019 13:49:21 +0200 (CEST)
X-DKIM: Sendmail DKIM Filter v2.8.2 357AF71C08F3
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail201101; t=1567424963; bh=mosvefPPiwAo8oDuDSLwPZW9d14AOgyvpNxY1Kw7ptI=; h=Date:Subject:Message-ID:References:In-Reply-To:Mime-version:From: To:Content-Type:Content-Transfer-Encoding; b=XBbAzHfTtX7bVg1EIYDUnuzzrmtBYepALHQg4vD6am/XmyaAWLuUv3IGi6pOJyt7e dAbmLncY46+sz17Aw11MeNsF4/3P7mNVDwqG4MGf7OjQ7g3tDKypWSfS+ZKr75Krct IKds+1tIjtawo817yw28xPeH7WxFnfI6nYcNcJSA=
X-Kerio-Anti-Spam: Build: [Engines:, Stamp: 3], Multi: [Enabled, t: (0.000005,0.007756)], BW: [Enabled, t: (0.000006)], RTDA: [Enabled, t: (0.081888), Hit: No, Details: v2.7.53; Id: 15.1i61cs0.1djostm0v.2q0sf], total: 0(700)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/10.1c.0.190812
Date: Mon, 2 Sep 2019 13:49:20 +0200
Message-ID: <>
Thread-Topic: [Ntp] Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts
References: <> <> <> <> <20190828103752.GI24761@localhost> <> <20190828111458.GJ24761@localhost> <> <> <> <> <> <>
In-Reply-To: <>
Mime-version: 1.0
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+MDNjYzVhNjFjMDY4OWQ0MA==
From: Heiko Gerstung <>
To: Harlan Stenn <>, "" <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: clamav-milter 0.100.3 at server1a
X-Virus-Status: Clean
Archived-At: <>
Subject: Re: [Ntp] Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Sep 2019 11:49:28 -0000

On 02.09.19, 13:30 "ntp im Auftrag von Harlan Stenn" < im Auftrag von> wrote:
    On 9/2/2019 3:59 AM, Heiko Gerstung wrote:
    > Harlan,
    > I am not sure I understand you correctly. My point was that we can change the base format of an NTP packet because we mark it as version=5. If someone sends a request with version=4, he should get a version=4 response with the v4 packet format. If someone sends a version=5 request, they will get a version=5 response with the new packet format, because the v5 request indicated that the client wants and understands a v5 response.
    > Maybe we both agree on this one here and just misunderstand each other? ;-)
    People are saying that regardless of the version number in the packet,
    one should respond with the version the other side offers, with the data
    that *we* understand.
    How can that possibly work if you want to make a v5 packet that changes
    the format and/or content of the base packet?
    How can a v4 server that gets a v5 packet possibly respond with correct
    v5 data?

I did not say that (or at least I did not mean it). I said that a server supporting both v4 and v5 should always respond with a v4 packet if the request is v4 and responds with a v5 packet it the request was v5. If a v4 only server receives a v5 request, it should not respond (or respond with a v4 packet instead). 
    > Again, the loop detection algorithm for degree-n-loops would be one benefit from a chain of refids that are passed on from top to down. It would also allow to identify if two or three of my stratum 3 sources get their time from the same stratum 1 source. If we add a flag to the chain that indicates that this InstanceID contributed to the chain using an NTS protected connection, a client could reject any source that is not providing a fully protected chain. Or it prefers a source that can come up with such a chain.
    How do you propose getting that refid chain "downstream"?

Using an EF. Adding an EF which says "send me the chain" to a request, triggering the upstream server to send its resonse with an EF attached to it that includes the chain.
    We've just spent YEARS doing our best to remove meaning from the refid
    field to prevent abuse vectors for a single upstream, and now you want a
    method to clearly identify a chain of upstreams?

A unique chain of InstanceID's which does not include any IP addresses or host names is not a way of clearly identifying anyone in that chain. 
    Indeed, for this chain to work one would need to know all the players in
    the tree between the top of the heap and the "bottom", as  the loop
    detection would need to know the various possible systems in the middle.

As far as I can see, you do not need to know anything about the players in the tree. You just get a list of instanceIDs and as long as your own is not included, and there is none appeariong twice, you can assume that there is no loop.
    When did NTS evolve to provide assertions about the intentions of the
    "middle players"?

I did not say anything about intentions. I just stated that it could be useful to verify that the whole chain of clocks talked to each other using NTS. I know that any man-in-the-middle being able to trick its downstream NTS clients into trusting them will be able to fool a client. But that is true in general, i.e. any MITM attack that successfully gets into the chain will be able to spoil the time downstream. 

No need to freak out about this, just ideas for v5. Yes, I know that all this is not part of the protocol in its current state. But we are talking about the future version of the protocol and I see use cases for this. 
Best Regards,

Heiko Gerstung 
Managing Director

MEINBERG® Funkuhren GmbH & Co. KG
Lange Wand 9
D-31812 Bad Pyrmont, Germany
Phone:    +49 (0)5281 9309-404
Fax:        +49 (0)5281 9309-9404

Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung


Do not miss our Time Synchronization Blog: 

Connect via LinkedIn: