IETF Logo Mail Archive

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

Heiko Gerstung <heiko.gerstung@meinberg.de> Wed, 28 August 2019 11:24 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 06ED6120105 for <ntp@ietfa.amsl.com>; Wed, 28 Aug 2019 04:24:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.289
X-Spam-Level:
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: 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 op8FAONrPtQz for <ntp@ietfa.amsl.com>; Wed, 28 Aug 2019 04:24:01 -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 3A1E1120100 for <ntp@ietf.org>; Wed, 28 Aug 2019 04:24:01 -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 E919D71C01BA; Wed, 28 Aug 2019 13:23:37 +0200 (CEST)
X-DKIM: Sendmail DKIM Filter v2.8.2 server1a.meinberg.de E919D71C01BA
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=meinberg.de; s=mail201101; t=1566991439; bh=P6hkTsi19ARXys+YfVDpydkX19pC6H04yHaDL8VEfJQ=; h=Date:Subject:Message-ID:References:In-Reply-To:Mime-version:From: To:Content-Type:Content-Transfer-Encoding; b=mKQ7AiK24rzDet5AsBdEvk1T8rMWrHR2fLQg/e+kp0N1WO4RrXWPShn8NaZwr1vyJ Sy7xOVTBvyHTIz+D1jL+otGvIiji/MtX3wV8nMyKJlsGTJgYghVhg1D+JRL/zcpD5+ en5af2Kae1fl+fTMcP1ig3EMqhEkryVQMbo2d6oM=
X-Kerio-Anti-Spam: Build: [Engines: 2.15.9.1266, Stamp: 3], Multi: [Enabled, t: (0.000005,0.005486)], BW: [Enabled, t: (0.000006)], RTDA: [Enabled, t: (0.116111), Hit: No, Details: v2.7.53; Id: 15.1i61l6q.1djbvev76.dggn1], total: 0(700)
X-Footer: bWVpbmJlcmcuZGU=
User-Agent: Microsoft-MacOutlook/10.1c.0.190812
Date: Wed, 28 Aug 2019 13:23:35 +0200
Message-ID: <55867E75-9813-466B-8E57-0E157DE5AEB9@meinberg.de>
Thread-Topic: [Ntp] 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>
In-Reply-To: <e50112dd-f918-1135-74c8-a738ecb70b70@nwtime.org>
Mime-version: 1.0
Importance: Normal
X-Priority: 3
Thread-Index: AZ2x3tU+MDNjYzVhNjFjMDY4OWQ0MA==
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/xrQScqzFv21vjJ7s9e7FBAwo27k>
Subject: Re: [Ntp] 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: Wed, 28 Aug 2019 11:24:03 -0000

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.

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 28.08.19, 13:20 "ntp im Auftrag von Harlan Stenn" <ntp-bounces@ietf.org im Auftrag von stenn@nwtime.org> wrote:

    
    
    On 8/28/2019 4:14 AM, Miroslav Lichvar wrote:
    > On Wed, Aug 28, 2019 at 03:42:15AM -0700, Harlan Stenn wrote:
    >> On 8/28/2019 3:37 AM, Miroslav Lichvar wrote:
    >>> My suggestion would be to keep the NTP header 48 octets long and
    >>> change only two fields: the refid and reference timestamp. They are
    >>
    >> If you change the refid field how will you effect degree 1 loop detection?
    > 
    > Hopefully with something better than the current refid field based on
    > (hashes of) addresses. Something like your suggested-refid proposal,
    > except the extension field would contain both the ID of the server
    > (randomly generated) and the ID of the its reference.
    
    Extension fields are optional.
    
    What benefit is there to requiring them if there's already an adequate
    field for the information in the base packet?
    
    I'm very curious how the ID if the remote server's reference will be
    useful, and not just another attack vector.
    
    > This could fit into the space of the NTPv4 refid and reference
    > timestamp, but it would take 64 of those 96 bits and I'm not sure if
    > 32 bits is enough for the other new stuff.
    Exactly what do you see as the use-cases for this information in the
    base packet?  Exactly how would this information be used?
    
    >>> ignored by current servers and most clients. That gives us 12 octets
    >>> of contiguous space in the header to work with. That's plenty for the
    >>> timescale negotiation and other metadata. Longer fields should be in
    >>> extension fields. No MACs allowed.
    >>
    >> I assume you meant "No >legacy< MACs allowed."
    > 
    > Right.
    > 
    
    -- 
    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