IETF Logo Mail Archive

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

Heiko Gerstung <heiko.gerstung@meinberg.de> Mon, 02 September 2019 10:46 UTC

Return-Path: <heiko.gerstung@meinberg.de>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7350012006A for <ntp@ietfa.amsl.com>; Mon, 2 Sep 2019 03:46:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.29
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=meinberg.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hy4dru_Y7SxX for <ntp@ietfa.amsl.com>; Mon, 2 Sep 2019 03:46:02 -0700 (PDT)
Received: from server1a.meinberg.de (server1a.meinberg.de [176.9.44.212]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E77C120089 for <ntp@ietf.org>; Mon, 2 Sep 2019 03:46:02 -0700 (PDT)
Received: from srv-kerioconnect.py.meinberg.de (unknown [193.158.22.2]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server1a.meinberg.de (Postfix) with ESMTPSA id AACBA71C08AB; Mon, 2 Sep 2019 12:45:58 +0200 (CEST)
X-DKIM: Sendmail DKIM Filter v2.8.2 server1a.meinberg.de AACBA71C08AB
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=meinberg.de; s=mail201101; t=1567421160; bh=6BsWxzPOFSMBfP3eE08kkFr/iX88YRI6U1kni1SoQyw=; h=Date:Subject:Message-ID:References:In-Reply-To:Mime-version:From: To:Content-Type:Content-Transfer-Encoding; b=XieAirpFiWU14xxq8PbX7W/dHPIKo2WkrHZMb7FWn6BstlWBfxnIf6UlDNHzStVRl NbyNY5pfCCfE8qDzEx2oZSnJv8157ZIgcG640uvQyX26NUrOup9VlPx9Nr58JOlEGC 6oZd7uM+AZxQn1KdhhFjxemc+aF32x8Fnyx/JKOs=
X-Kerio-Anti-Spam: Build: [Engines: 2.15.9.1266, Stamp: 3], Multi: [Enabled, t: (0.000008,0.005118)], BW: [Enabled, t: (0.000009)], RTDA: [Enabled, t: (0.037623), Hit: No, Details: v2.7.53; Id: 15.1i61gv1.1djop9it0.2o6a9], total: 0(700)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/10.1c.0.190812
Date: Mon, 02 Sep 2019 12:45:54 +0200
Message-ID: <3A3B41F1-9B5F-4ADB-B674-89AD5C055FD1@meinberg.de>
Thread-Topic: [Ntp] Antw: Re: Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts
References: <1B4A56E7-16A6-4767-9268-BCF4BEB9A247@isoc.org> <BCA949D7-7D92-43A9-9766-573559A9FC70@meinberg.de> <5D66392D020000A100033273@gwsmtp.uni-regensburg.de> <8F6BAF5F-CC7B-47B9-90FD-BD20D6ABE845@meinberg.de> <20190828103752.GI24761@localhost> <3f4b55ca-02d9-a470-229b-40860866efbf@nwtime.org> <20190828111458.GJ24761@localhost> <e50112dd-f918-1135-74c8-a738ecb70b70@nwtime.org> <55867E75-9813-466B-8E57-0E157DE5AEB9@meinberg.de> <d308b5d4-3d6e-981b-3dfc-9d5938bad78d@rubidium.se> <5D6CB84E020000A100033405@gwsmtp.uni-regensburg.de> <43FFB9C5-8F9D-491C-8FC6-9DD292009E2A@meinberg.de> <26eeb953-301f-682e-47fe-cd34518d53e3@nwtime.org>
In-Reply-To: <26eeb953-301f-682e-47fe-cd34518d53e3@nwtime.org>
Mime-version: 1.0
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+MGQ3NGNiYTgyN2MxZTBhYw==
From: Heiko Gerstung <heiko.gerstung@meinberg.de>
To: Harlan Stenn <stenn@nwtime.org>, "ntp@ietf.org" <ntp@ietf.org>
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: <https://mailarchive.ietf.org/arch/msg/ntp/J-MMVwWEdHTNf1Js40YTzhiQGDg>
Subject: Re: [Ntp] Antw: Re: Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts
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, 02 Sep 2019 10:46:04 -0000

Not talking about the refid. An "InstanceID" could be a unique identifier of an NTP instance. It could be used as a refid as well in the NTP responses of an instance. Every server in a chain would be able to ask its upstream NTPv5 servers for their chain and passes that chain down to its clients (upon request) adding its own instanceID to the list. Any NTPv5 server receiving that chain could check if its own instanceID is already in the chain and then reject the upstream server due to a time loop detection issue. 

This higher level knowledge is not part of the *NTPv4* protocol, but it could be part of the NTPv5 protocol. If we add a flag to each entry in that chain indicating if that instance was protected with NTS, we could come up with a "chain of trust" thing and we could not only detect timing loops but would also be able to find out if the chain of clocks is fully NTS protected. 

There might be other benefits, I am just tossing ideas around..

Best Regards,
   Heiko


-- 
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

Email:
 heiko.gerstung@meinberg.de 
Web:
 Deutsch   https://www.meinberg.de
 English    https://www.meinbergglobal.com

Do not miss our Time Synchronization Blog:
 https://blog.meinbergglobal.com 

Connect via LinkedIn: 
https://www.linkedin.com/in/heikogerstung
 
 

On 02.09.19, 12:22 "ntp im Auftrag von Harlan Stenn" <ntp-bounces@ietf.org im Auftrag von stenn@nwtime.org> wrote:

    The refid has meaning on the system that issues it.
    
    The refid is a nonce to any system that receives it.
    
    Any meaning of the refid outside of the issuing system relies on
    higher-level knowledge that is not part of the protocol.
    
    On 9/2/2019 1:00 AM, Heiko Gerstung wrote:
    > Hi Ulrich,
    > 
    > good point. That is why NTP would use that "ID" instead of the IP address to identify itself. That means ntpd could find out timing loops even if they are caused by a routing loop.
    > 
    > Regards,
    >    Heiko
    > 
    > 
    
    -- 
    Harlan Stenn, Network Time Foundation
    http://nwtime.org - be a Member!
    
    _______________________________________________
    ntp mailing list
    ntp@ietf.org
    https://www.ietf.org/mailman/listinfo/ntp

v2.23.0 | Report a Bug | By Email