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

Heiko Gerstung <> Wed, 28 August 2019 11:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D444E120123 for <>; Wed, 28 Aug 2019 04:59:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.289
X-Spam-Status: No, score=-4.289 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, URIBL_BLOCKED=0.001] 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 ReerlVHEGA1D for <>; Wed, 28 Aug 2019 04:59:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9B21B12004A for <>; Wed, 28 Aug 2019 04:59:33 -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 B972571C0794; Wed, 28 Aug 2019 13:59:29 +0200 (CEST)
X-DKIM: Sendmail DKIM Filter v2.8.2 B972571C0794
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail201101; t=1566993572; bh=Mk+Zcl8e64BgmXknL0PpWwtFVrdHfbBKFY9yxUcdiB0=; h=Date:Subject:Message-ID:References:In-Reply-To:Mime-version:From: To:Content-Type:Content-Transfer-Encoding; b=gWIl2Zb6Brwr9PtwOl+U+2Zl5AO47WHYPKyjAYu2bXm059+SIJP9X0OIfShhjdX9N QzV6a/JM6PdyylfGLBDxuxhJCCPxunnX+R+WsLfRuC4LZACPob5I5I7sugH7Its83h 9XaVOR/hz/rvMsxiymuIUnbe1k6de0gP0BWrr9no=
X-Kerio-Anti-Spam: Build: [Engines:, Stamp: 3], Multi: [Enabled, t: (0.000006,0.006991)], BW: [Enabled, t: (0.000007)], RTDA: [Enabled, t: (0.162225), Hit: No, Details: v2.7.53; Id: 15.1i65o8b.1djc1gksc.dps5e], total: 0(700)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/10.1c.0.190812
Date: Wed, 28 Aug 2019 13:59:26 +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: Wed, 28 Aug 2019 11:59:36 -0000


I asked why we would not want to improve the loop prevention mechanism, I do not have a solution at hand which I sketched out in full detail already. But here is a possibility that came to my mind just now, it certainly needs to be refined and checked and modified:

- create a random ID on each server at startup
- communicate that ID to each client which indicates (e.g. by an EF) that it is interested in this information, for example if it wants to be a server itself (stratum 2+)
- a tier-2 server uses that ID from its upstream server as its refID
- any server that is interested in degree n - loop detection will indicate this (using an EF, maybe something like the I-DO EF) to its upstream server(s)
- those servers respond with an EF containing a list of IDs representing the sync chain, maybe limited to n entries (if the requesting client asks for only n entries)
- now, if this server which received the chain of IDs from its upstream server(s) now is questioned by one of its downstream clients about the chain of sync, it will add the RefID of its upstream servers to the sync chain received by that upstream server and push this down to the client

This way, those clients interested in only degree 1 loop protection just use the RefID field. And those who are interested in degree n loop protection can request the chain of IDs from their upstream servers. 

The freedom to change the packet header format would allow us to increase the number of bytes for the RefID to improve security (more bytes, harder to guess). 

We have had cases where a server A was synchronized by server B which was synchronized by server C. Server C also used Server D which was synchronized by Server A, i.e. whenever your client believes it has more than one source of time and it turns out that all of them go back to one single source. Adding non-randomized IDs like "GPS" to the sync chain (by the stratum 1 server) would also allow the clients to identify if they are relying on one single source of time, which in turn would make it possible to choose another server with a different source (like Galileo) instead.

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:

On 28.08.19, 13:38 "ntp im Auftrag von Harlan Stenn" < im Auftrag von> wrote:

    On 8/28/2019 4:23 AM, Heiko Gerstung wrote:
    > Why not define a method in v5 that not only protects against degree 1 loops but maybe also against degree 2,3 or n? 
    > This is what I meant when trying to explain that we should not stick to the existing packet format with its shortcomings.
    Exactly how would this work?
    Has there been any reported instances of this being useful or needed for
    What abuse vectors would this create?
    > Regards,
    >    Heiko
    Harlan Stenn, Network Time Foundation - be a Member!
    ntp mailing list