Re: [Ntp] NTPv5 Loop Detection without Stratum - Why do we want this?

[Danny Mayer <[e-mail]>]

On 9/12/22 6:24 AM, Miroslav Lichvar wrote:
> On Thu, Sep 08, 2022 at 06:18:24PM -0400, Danny Mayer wrote:
>> On 9/8/22 2:24 AM, Miroslav Lichvar wrote:
>>> An NTP client can select multiple sources at the same time for its
>>> synchronization. Look for "combine" in the NTP RFCs. With the "ntpq
>>> peers" command you would see sources marked with the * and + symbols.
>> Only is chosen (marked with a *). The + ones are possible candidates.
> Only one is chosen to be the system peer (*), which determines stratum
> and other values of the client, but other sources can pass the
> clustering algorithm and be combined with the system peer for
> synchronization. They have the + symbol.

NTP looks at the selected candidates and chooses what it considers the 
best at that time. Only one source is the chosen system which as you 
note is marked as the one with the asterisk (*). You can only find that 
out with ntpq (mode 6) queries. That becomes the reference ID for any 
downstream NTP servers. I'm not sure what you are trying to point out.


>
> Sources that don't pass the clustering algorithm have the - symbol.
> They are not used for synchronization.
>
>>>>> In orphan mode stratum is interpreted differently. Symmetric mode or
>>>>> client/server mode makes no difference.
>>>> There is no symmetric mode for client/server. A client is by definition one
>>>> stratum value larger than the server. Peers can have the same stratum.
>>> This is about the onwire protocol, not about source selection or
>>> synchronization. A client polling a server can have a smaller, equal,
>>> or higher stratum than the server.
>> That's irrelevant. You are polling a server for time, what you do with it
>> depends on the analysis done on the packets.
> Right. So can you explain where measurements made in symmetric mode
> are handled differently than in client/server mode? A pointer to the
> RFC or code is sufficient.
The NTP reference implementation does this.
>
>>> Two client/server associations in opposite directions provide the same
>>> functionality as a symmetric association, except the number of
>>> exchanged messages is doubled, it's much easier to implement and
>>> understand, and there are no replay attacks.
>> That's a naive assumption. You can send any kind of replay no matter what
>> the mode of the packet. Why do you think that you are sending twice as many
>> packets in a symmetric association?
> In symmetric mode each packet is a request and response at the same
> time, i.e. the number of messages is halved when compared to two
> client/server associations.
No. See the source code.
>
> As the responses follow the polling interval and are not send
> immediately when the request is received, this makes the symmetric
> mode susceptible to replay attacks. In client/server mode each request
> has its own response, independently from the polling of the other
> client/server association.
Not true. You misunderstand how symmetric mode works.
>
>>>>> If a local stratum-1 server had a poor reference clock (e.g. a GPS
>>>>> receiver without PPS), it would be better to use a distant server with
>>>>> higher stratum, i.e. stratum doesn't say much about accuracy.
>>>> Then it wouldn't be a stratum-1 server any more.
>>> What it would be?
>> I can only assume you have not read Section 3 of RFC5905 which tells you the
>> answer.
> Which part exactly?
>
> In Section 3 I see: "Primary servers are assigned stratum one"
>
> That is, a server that uses a poor reference clock is still stratum
> one. A client which polls multiple servers would likely prefer a
> different server, possibly with a higher stratum.
>
A stratum-1 server that decides that it's reference clock is not 
reliable, or unavailable, is no longer a stratum-1 server, it's just a 
downstream server from it's selected server and is a stratum lower than 
that server. I'm not sure what your question is since it's very basic to 
NTP.

Danny