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

Dieter Sibold <dsibold.ietf@gmail.com> Thu, 29 August 2019 10:03 UTC

Return-Path: <dsibold.ietf@gmail.com>
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 4959712003E for <ntp@ietfa.amsl.com>; Thu, 29 Aug 2019 03:03:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 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, T_FILL_THIS_FORM_SHORT=0.01] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhTYDM1CJl0J for <ntp@ietfa.amsl.com>; Thu, 29 Aug 2019 03:02:51 -0700 (PDT)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 E172A120018 for <ntp@ietf.org>; Thu, 29 Aug 2019 03:02:50 -0700 (PDT)
Received: by mail-ed1-x52b.google.com with SMTP id h8so3398020edv.7 for <ntp@ietf.org>; Thu, 29 Aug 2019 03:02:50 -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 :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=X+mkSGWwf1XThaFklNJ7FMrWuUaRaHd4avW8B+mQTow=; b=Zrdea3IVu9ztZhnZDe9q4WA9lmB1y4e6mGR/HVFj9TIstqXQEMp/sLK3l3AVNC2T6o DEq84ZtjBlLEGFh+tCTQA2W2oE/utyXGYhGa0Q7nLxOEsBG5ZTsQHM5iRlVe8cvyykZK iEQw2KMpvLBS3MzJgr3CKzlQCYNP0iQ3qAJcP1G4Bn8CylvAQVng/HsYMtCQHBoilfDT Vb1FaRRuIMUfV7Ujl8Rt6I5CUXSgE/qoYevti2DaUl83WdSpQB4afLzBlyOpZjUEdg9m vpa+oiTW7DaM9KOkgFTSxC2XK+xPdghNO8/u2yxD/w4Pe6/JU2Z0tg9XOWvTWyuNIS8e Uh8w==
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:references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=X+mkSGWwf1XThaFklNJ7FMrWuUaRaHd4avW8B+mQTow=; b=B8SkbdOmIfD1CYnR3kzpieIJOANHY3nvACfeuJ1AL8mjtaxHf7NQu6xHemRV1T/7+o Hm33PKD0djUsqoQ33ddSCjXdQiSuBIvUjZSjuWQJ+7ML0tuA3ay0PNdcLxQlpDslmYvA FvzOwaVbANbiIUWWJlBXb0g95B1kAeR5Sc+CgBbPgFeqOGxjSpcv4QEJRSYMfS4sC/7i i1DeTFpbmQW6ZGXDOSGGUjicjCbfy2yc8tOMao4CrtuVsetuSRCEM1hMGXrLw2beI7AW omeWek1Z0/H5pqdDh7JY2i+XyyKR4BcR9hfIqGNtyWFuJ/BOuZChEDfKC/zhSRamWyFO dewQ==
X-Gm-Message-State: APjAAAVgccToxJoc/jegUKIiDIlNifIe6I2Kwv3gOd9oSFS0wtsZTaUF 4pUw1V9kYRFjC1uzxgKPyBc=
X-Google-Smtp-Source: APXvYqzEIL7S7xl81vLEDrXHkXrtIMjD/F91qnSiJjLfludReTPvQzKCmaS8FJPyMCZAWV5GR0tCMA==
X-Received: by 2002:a50:c385:: with SMTP id h5mr8652009edf.18.1567072969402; Thu, 29 Aug 2019 03:02:49 -0700 (PDT)
Received: from AM0PR08MB4546.eurprd08.prod.outlook.com ([2603:1026:207:143::5]) by smtp.gmail.com with ESMTPSA id v13sm356965edr.38.2019.08.29.03.02.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Aug 2019 03:02:48 -0700 (PDT)
From: Dieter Sibold <dsibold.ietf@gmail.com>
To: Heiko Gerstung <heiko.gerstung@meinberg.de>, Harlan Stenn <stenn@nwtime.org>, "ntp@ietf.org" <ntp@ietf.org>
Thread-Topic: [Ntp] Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts
Thread-Index: AQHVXXlsckTpN2NMrEWTfPcHsCXYGqcQVfaAgAAIYACAAAE6gIAACSQAgAABQ4CAAAElgIABe79F
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Thu, 29 Aug 2019 10:02:47 +0000
Message-ID: <AM0PR08MB4546A7C31E68D958680ABF22F8A20@AM0PR08MB4546.eurprd08.prod.outlook.com>
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>
In-Reply-To: <55867E75-9813-466B-8E57-0E157DE5AEB9@meinberg.de>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
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/psUwY_FWnFJjG_72BtVvfeYCx_8>
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: Thu, 29 Aug 2019 10:03:09 -0000

With the WG chair hat off: I agree with Heiko. If we specify NTPv5 we should not restrict ourselves to the limitations of the existing packet format.

Regards
Dieter

Am 28.08.19, 13:24 schrieb "ntp im Auftrag von Heiko Gerstung" <ntp-bounces@ietf.org im Auftrag von heiko.gerstung@meinberg.de>gt;:

    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
        
    
    
    _______________________________________________
    ntp mailing list
    ntp@ietf.org
    https://www.ietf.org/mailman/listinfo/ntp