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

>>> Heiko Gerstung <heiko.gerstung@meinberg.de> schrieb am 28.08.2019 um 13:59
in
Nachricht <E58275AC-9EC8-46D7-B160-7F8F3EF1C817@meinberg.de>:
> 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

I'd add a "double-may" there: The ID MAY be random, and it MAY be re-created
on each server startup.
Maybe think of it like the driftfile that preserves some value across
restarts.

> - 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+)

Why not always add it?

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

So this applies only to stratum-1 servers (which had spacial refIDs anyway).
What about having a "normal" REFID for stratum 1 servers, and adding a
mandatory "reference source class" (like "GPS", "Gallileo" (note the extra
length!), "NTP" (for stratum > 1), "DCF-77", etc? (Or even do it the GPT-way:
Allocate UUIDs (well, GUIDs will do as well) for all known reference clock
sources?)
And if you like splitting hairs, you could have different IDs for the "time
source" (like TAI), the "time carrier" (like GPS) and the "time access point"
(effectively the interface providing GPS time) like "Product X from Vendor Y
with further details Z"...
So if a specific product has a bug, you could filter it; if a specific carrier
has a problem, you could filter it, and if you distrust some source, you could
filter it... ;-)

Regards,
Ulrich

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