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

On 8/24/22 1:54 AM, Ulrich Windl wrote:
>>>> 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).

No need. When it's a stratum-1 server the referenceID in the packet 
indicates the clock being used. See RFC5905 Figure 12.

Danny

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