[Ntp] Antwort: Re: Symmetric mode

[[e-mail]]

Some responses in-line.

Besten Gruß / Kind regards,
Kristof Teichel

__________________________________________

Dr.-Ing. Kurt Kristof Teichel
Physikalisch-Technische Bundesanstalt (PTB)
Arbeitsgruppe 4.42 "Zeitübertragung"
Bundesallee 100
38116 Braunschweig (Germany)
Tel.: [phone]
E-Mail: [e-mail]
__________________________________________

-----"ntp" <[e-mail]> schrieb: -----

>An: "Miroslav Lichvar" <[e-mail]>, "Hal Murray"
><[e-mail]>
>Von: "Danny Mayer"
>Gesendet von: "ntp"
>Datum: 20.09.2022 15:41
>Kopie: "[e-mail]" <[e-mail]>
>Betreff: Re: [Ntp] Symmetric mode
>
>On 9/19/22 5:01 AM, Miroslav Lichvar wrote:
>> On Sun, Sep 18, 2022 at 07:46:14PM -0700, Hal Murray wrote:
>>> Is symmetric mode interesting enough that we should try to fix
>that? If so,
>>> would you please say a few words about why it is interesting?
>> It's not very useful. I think the most interesting thing about it
>is
>> that sources using the symmetric mode are marked differently in
>tools
>> like ntpq, so it's more obvious to the admin that synchronization
>can
>> work in both directions.

>It's extremely useful, particularly when you end up in orphan mode or
>just need to make sure that all systems in the local network are
>synchronized. 

1) You say particularly. Is it useful in any other known use-cases?

2) Also, how often do we think the former case happens? A feature might be incredibly useful in the case of heavy acid rain, but that alone is not reason to implement it. Also, see 3)

3) I'm increasingly approaching NTP from a viewpoint of metrological traceability (this is important to PTB as an NMI, I intend to contribute text suggestions for documents in the future). I believe there is a strong case to be made for a simple hierarchical approach (i.e. get time from one, pre-specified server, and secure it with NTS or other authenticity-protection) if traceability is what one is thinking about. Under this perspective, the latter use-case honestly seems problematic (traceability mostly goes out the window once you don't have a "source" and instead are keeping several equal-level partners synchronous, IMO).

>You really need to take the time to understand it.

I'll reiterate my point from a few weeks ago that I would prefer if we keep our tone constructive in WG exchanges.

This seems like a pretty broad dismissal of a bunch of statements and a hard assumption of ignorance.

Can you give us hints how you find Miroslav's statements wrong/misleading (and which ones) so that the rest of us can be part of the conversation? 

>> At the protocol level it's just trouble. It's difficult to
>implement
>> if you want to handle all the corner cases and difficult to secure.
>> The main problem is that there is no response for each request, so
>the
>> peers have to select to which request they respond, i.e. guess
>which
>> one was genuine. Authentication with a symmetric key doesn't
>prevent
>> a replay attack.
>See above.

I really don't see how this can be "see above".

Even if we accept that symmetric mode useful, that doesn't mean it's not diffcult.

Or do you mean this is another case of "need to understand"? (In which case: see above).

We certainly agreed to give up on the attempt to secure symmetric mode with NTS, which supports "difficult to secure".

>> There are ephemeral associations, where only one peer is configured
>> with the address of the other peer. This enables attackers to
>replay an
>> authenticated message to create an unlimited number of associations
>on
>> the peer. In the ntp.org implementation there is a possibility to
>> limit keys to IP addresses to prevent that, but in that case it's
>> easier to just specify the address directly as a peer in the
>> configuration file and you don't have to worry about associations
>> created on different ports of the address.
>>
>Not really. Again you need to understand how it works.

Again, could you qualify which of these statements you disagree with and/or how so?

>Danny
>
>_______________________________________________
>ntp mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ntp" target="_blank" rel="noopener noreferrer nofollow">https://www.ietf.org/mailman/listinfo/ntp
>