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

Harlan,

I asked why we would not want to improve the loop prevention mechanism, I do not have a solution at hand which I sketched out in full detail already. But here is a possibility that came to my mind just now, it certainly needs to be refined and checked and modified:

- create a random ID on each server at startup
- communicate that ID to each client which indicates (e.g. by an EF) that it is interested in this information, for example if it wants to be a server itself (stratum 2+)
- a tier-2 server uses that ID from its upstream server as its refID
- any server that is interested in degree n - loop detection will indicate this (using an EF, maybe something like the I-DO EF) to its upstream server(s)
- those servers respond with an EF containing a list of IDs representing the sync chain, maybe limited to n entries (if the requesting client asks for only n entries)
- now, if this server which received the chain of IDs from its upstream server(s) now is questioned by one of its downstream clients about the chain of sync, it will add the RefID of its upstream servers to the sync chain received by that upstream server and push this down to the client

This way, those clients interested in only degree 1 loop protection just use the RefID field. And those who are interested in degree n loop protection can request the chain of IDs from their upstream servers. 

The freedom to change the packet header format would allow us to increase the number of bytes for the RefID to improve security (more bytes, harder to guess). 

We have had cases where a server A was synchronized by server B which was synchronized by server C. Server C also used Server D which was synchronized by Server A, i.e. whenever your client believes it has more than one source of time and it turns out that all of them go back to one single source. Adding non-randomized IDs like "GPS" to the sync chain (by the stratum 1 server) would also allow the clients to identify if they are relying on one single source of time, which in turn would make it possible to choose another server with a different source (like Galileo) instead.

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

    On 8/28/2019 4:23 AM, Heiko Gerstung wrote:
    > 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.

    Exactly how would this work?

    Has there been any reported instances of this being useful or needed for
    NTP?

    What abuse vectors would this create?

    > 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