Re: [Ntp] Antwort: Re: Symmetric mode

[Danny Mayer <[e-mail]>]

See below.

On 9/20/22 11:26 AM, kristof.teichel=[e-mail] wrote:
> Some responses in-line.
>
> Besten Gruß / Kind regards,
> Kristof Teichel
>
> -----"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?
Yes. Any set of systems that need to ensure that they are synchronized 
together can take advantage of this. Most of the time you would want to 
do this if they are all on a LAN. Broadcast, Multicast and Symmetric 
Peer modes are particularly useful on a LAN.
> 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)

I can't answer that since I don't maintain those kinds of systems. If 
you loose your external internal internet connections, which we know 
happens from time to time, having internal systems synchronized with 
each other keeps things working in a coordinated fashion.

> 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).
For some cases simple hierarchical approach is simpler. PTP does that. 
NTS was trimmed down to only handle client/server mode in order to get 
it out the door. There's nothing to prevent other modes using NTS, 
though Broadcast and Multicast might more be tricky to implement.
>
> >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?
This was not meant as any disrespect of Miroslav or anyone else. I can 
only point to documentation and explanations of why symmetric peer mode 
is useful. Dave Mills spent years conducting research and development on 
this and he has written plenty of papers on this.
>
> >> 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.
The main difficultly seems to be understanding why it's used, hence the 
subject line of this thread. The implementation is pretty straightforward.
> 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".
It was done in the name of getting NTS out the door.
>
> >> 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?

Symmetric peer associations are not ephemeral since both sides keep 
information of each other the same way that any client does. An attacker 
cannot really replay an authenticated message as it would be rejected as 
already received. I'm not sure what is meant by limiting IP addresses to 
prevent that since a replay attack would have to use the same IP address 
to send the packet. In any case you would use a MAC with an agreed-upon 
algorithm to prevent fiddling with the contents. You don't however want 
to specify specific IP addresses since those can change, you need the 
FQDN in any configuration.

Does this help?

Danny