[Ntp] NTPv5 Loop Detection without Stratum

[Heiko Gerstung <[e-mail]>]

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: [phone] | LinkedIn Profile <https://www.linkedin.com/in/heikogerstung/> | Twitter <https://twitter.com/hgerstung>
[e-mail]

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" <[e-mail] im Auftrag von [e-mail]>:

    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
    [e-mail]
    https://www.ietf.org/mailman/listinfo/ntp