Re: [Ntp] Antwort: Re: Symmetric mode

[Danny Mayer <[e-mail]>]

On 10/3/22 3:47 AM, Miroslav Lichvar wrote:
> On Fri, Sep 30, 2022 at 08:25:00PM -0400, Danny Mayer wrote:
>> On 9/29/22 12:52 PM, Miroslav Lichvar wrote:
>>> How would they decide which one is a client and which one is server?
>> The initiator of the request is acting as the client for the packet and the
>> other one acts as the server. When the other peer initiates a packet it is
>> the client.
> I guess it might be possible to use the origin timestamp to detect
> requests and responses, but that is not how NTP was designed to work.
> It uses the mode number and in the case you are describing it's the
> client and server mode.

If you don't know about the packet then it's requesting the timing data. 
If you know about the packet then it's the response to the reequest you 
sent.


>>> In Figure 15 of the RFC (describing the state of two peers) you can
>>> clearly see that there are only 2 messages per poll.
>>>
>>>
>>>                   t2      t3                 t6          t7
>>>           ---------------------------------------------------------
>>>                    /\         \                 /\            \
>>>                    /           \                /              \
>>>                   /             \              /                \
>>>                  /               \/           /                 \/
>>>           ---------------------------------------------------------
>>>                t1                t4         t5                  t8
>>>
>> I'm not sure what you are seeing.
> There are two peers sending packets to each other. Each peer sends one
> packet per poll. There are four packets shown in the figure. Each one
> is a request and all except the first one are also responses. The
> peers update their state with each received packet.
No, the server only responds to a request. Peer A sends a symmetric mode 
packet to Peer B and Peer B sends a response. Then Peer B sends a 
request to Peer A and Peer A sends a response to Peer B. There's no 
mixing involved here.
>
> If they were using the client/server mode, it would look like this:
>
>          t2  t3        t5         t8       t10 t11      t13        t16
>    --------------------------------------------------------------------
>          /\  \         \         /\        /\  \         \         /\
>         /     \         \       /         /     \         \       /
>        /       \         \     /         /       \         \     /
>       /         \/        \/  /         /         \/        \/  /
>    --------------------------------------------------------------------
>      t1         t4        t6  t7       t9         t12      t14  t15
>
>
> There are twice as many packets for the same number of measurements.
> Half of them are requests and the other half are responses. Requests
> don't update the state of the server. This is why the client/server
> mode is more secure.
Yes and No. Symmetric mode is just as secure, but you are 
misunderstanding how it works. See above response.
>
> The best way to understand the protocol is to write your own minimal
> implementation. If you implemented both modes, I think you would agree
> that symmetric mode is not worth the trouble.
>
> Please, at least make your own packet capture between two peers and
> see that it works how described here. It's not a bug. If it was
> a bug, it would be noticed after all those years. You are just
> spreading misinformation and confusing others.

No, you are just misunderstanding for symmetric mode works.

Danny

>