Re: [Ntp] NTPv5 Loop Detection without Stratum

Are timing loops an actual, real problem?

If so, what are the significant considerations?

What core variables are in play?  Root distance?  Root/peer dispersion?

What are the root causes of these loops?

H

On 8/23/2022 3:21 AM, Heiko Gerstung wrote:
> 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
> - a stratum two server would add its own ID to the ID of its upstream server, responding with a sync trace of two 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 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.
> 
> 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
> 
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp

-- 
Harlan Stenn <stenn@nwtime.org>
http://networktimefoundation.org - be a member!