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

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

    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