[Ntp] Antw: [EXT] NTPv5 Loop Detection without Stratum

>>> Heiko Gerstung <heiko.gerstung@meinberg.de> schrieb am 23.08.2022 um 12:21
in
Nachricht <DA1F1664-8A84-4197-844A-CA7E8DAA36B8@meinberg.de>:
> One way of avoiding/detecting loops:
> - upon startup, an NTPv5 instance creates a random 64bit ID
> - we add a loop detection EF that can include n IDs (or we use n EFs)
> - a stratum one server, when ask for his "sync trace", responds with only 
> his ID

Considering that a stratum-1 server may have more than one reference clock
(say m) to pick, I think a stratum-1 server should actually prepare one ID per
reference clock. It's a design issue whether to return one ID that is different
for each clock (see below), or two IDs (server's + clock's).

> - a stratum two server would add its own ID to the ID of its upstream 
> server, responding with a sync trace of two IDs

So would it still be a loop if you find the same server, but the server itself
is syncing from a different source now?
I mean: What if sending one ID that is the conceptual concatenation of all
"upstream IDs" (like SHA-ing the concatenation for to form a new ID) instead of
several? You would need to calculate the new ID only if the reference changes.

The other thing is: Return or concatenate only the reference ID, or even the
selected IDs?

> - a stratum 1+n server would respond with the sync trace of its upstream 
> source(s) plus its own ID 
> - if you use more than one upstream source, you can respond with a list of 
> all IDs from the sync trace of all your upstream sources (removing 
> duplicates)
> - by checking if your own ID is in the sync trace of your upstream 
> source(s), you can find out if there is a loop
> 
> Maybe smaller IDs (32 bit, 16 bit) would be OK as well. 10 IDs would be 80 
> octets on the wire. No question that we would have to find a way to avoid 

I think it's rather commonsense that 64-bit is enough for global. Considering
that the number of NTP setrvers at the moment is "rather small" 48 or 32 bits
might do, but remember that those IDs are _not_ unique; they are random, so
there may be collisions even when being used by just a few hundreds of
servers.

> amplification attacks (hello monlist!). Maybe by making it mandatory to send

> a request (with padding bytes) that is as big as the worst case response. 

Amplification by replay attack? If not, then authentication might help.

Regards,
Ulrich

> 
> Regards,
>   Heiko
> 
> --
> Heiko Gerstung | Managing Director
> T: +49 (0)5281 9309-404 | LinkedIn Profile 
> <https://www.linkedin.com/in/heikogerstung/> | Twitter 
> <https://twitter.com/hgerstung>
> heiko.gerstung@meinberg.de 
> 
> MEINBERG® The Synchronization Experts
>  
> Meinberg Funkuhren GmbH & Co. KG
> Lange Wand 9 | 31812 Bad Pyrmont | Germany
> Web: http://www.meinberg.de | http://www.meinbergglobal.com | LinkedIn  
> <https://www.linkedin.com/company/meinberg-funkuhren-gmbh-&-co--kg>
> 
> Amtsgericht Hannover 17HRA 100322
> Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre 
> Hartmann, Heiko Gerstung
> 
> Do not miss our Time Synchronization Blog:
> http://blog.meinbergglobal.com 
>  
>  
> 
> Am 23.08.22, 12:07 schrieb "ntp im Auftrag von Miroslav Lichvar" 
> <ntp-bounces@ietf.org im Auftrag von mlichvar@redhat.com>:
> 
>     On Tue, Aug 23, 2022 at 11:30:44AM +0200, Ulrich Windl wrote:
>     > So my conclusion still is that the "ping pong" style of time exchange

> between
>     > peers is in accordance with the protocol specification.
> 
>     If the protocol cannot prevent the loop, there is no other option :).
> 
>     If NTPv5 can detect all loops, the client can decide to ignore the
>     measurements of the source to avoid the loop.
> 
>     > (However if those peer have no other time source, the quality should 
> become
>     > worse over time, eventually declaring them unsynchronized)
> 
>     If they have no other time source, the protocol will block the
>     synchronization by ignoring sources with larger stratum (NTPv3) or
>     ignoring sources with matching refid (NTPv4).
> 
>     > > It causes oscillations, which has a negative impact on stability of
>     > > the clocks. If you remove the symmetric associations, it performs
>     > > better. You can easily verify that.
>     > 
>     > It may be, but would it be in the spirit of the protocol
specification?
> 
>     I'm not sure what you mean by this.
> 
>     -- 
>     Miroslav Lichvar
> 
>     _______________________________________________
>     ntp mailing list
>     ntp@ietf.org 
>     https://www.ietf.org/mailman/listinfo/ntp 