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

Dieter Sibold <> Thu, 29 August 2019 10:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4959712003E for <>; Thu, 29 Aug 2019 03:03:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.989
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fhTYDM1CJl0J for <>; Thu, 29 Aug 2019 03:02:51 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E172A120018 for <>; Thu, 29 Aug 2019 03:02:50 -0700 (PDT)
Received: by with SMTP id h8so3398020edv.7 for <>; Thu, 29 Aug 2019 03:02:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 ([2603:1026:207:143::5]) by with ESMTPSA id v13sm356965edr.38.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Aug 2019 03:02:48 -0700 (PDT)
From: Dieter Sibold <>
To: Heiko Gerstung <>, Harlan Stenn <>, "" <>
Thread-Topic: [Ntp] Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Thu, 29 Aug 2019 10:02:47 +0000
Message-ID: <>
References: <> <> <> <> <20190828103752.GI24761@localhost> <> <20190828111458.GJ24761@localhost> <> <>
In-Reply-To: <>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Exchange-Organization-SCL: -1
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: 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.


Am 28.08.19, 13:24 schrieb "ntp im Auftrag von Heiko Gerstung" < im Auftrag von>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.
    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:20 "ntp im Auftrag von Harlan Stenn" < im Auftrag von> 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 - be a Member!
        ntp mailing list
    ntp mailing list