Re: [chrony-users] Decision algorithm, compatibility

[Uwe Fechner <fechner@xxxxxxxxxxx>]

Dear Miroslav,

Thanks a lot for your reply!

Regarding the first issue, I will add the option

stratumweight= 0.01

and see if the issue is fixed.

Regarding the second issue, I found the following info on
https://fedoraproject.org/wiki/Changes/NetworkTimeSecurity

ISPs may block or rate limit longer NTP packets as a mitigation for amplification attacks using NTP mode 6 and 7. NTS-KE supports port negotiation and servers can provide an alternative port to avoid this issue.

Questions:

1. Does chrony supports port negotiation?
2. If yes, does it needs to be enabled on the server or the client or both?
3. How can it be enabled, if that is an option?

Looking forward for your reply!

Uwe

Am 16-09-2021 um 09:43 schrieb Miroslav Lichvar:

> On Wed, Sep 15, 2021 at 04:18:02PM +0000, Uwe Fechner wrote:
> > chronyc sources
> > MS Name/IP address         Stratum Poll Reach LastRx Last sample
> > ===============================================================================
> > ^* time.cloudflare.com           3  10    42   41m  +2690us[+3783us] +/-   26ms
> > ^- nts1.time.nl                  2   9   377   389  +2364us[+2364us] +/-   67ms
> > ^+ ptbtime1.ptb.de               1  10    20   95m   +439us[+1470us] +/-   24ms
> > ^+ sth1-ts.nts.netnod.se         2  10   377   201  -2001us[-2001us] +/-   35ms
> > ^+ sth2-ts.nts.netnod.se         2  10   377   927  +1983us[+1983us] +/-   25ms
> >
> > Why is cloudfare selected? It has the worst stratum AND a bad reach.
> >       
> It probably has the lowest root distance on average. You can enable
> the measurements log and check. But note it's not used alone. It's
> combined with the other three servers with similar root distance. It's
> not very important which one of them has the '*' symbol.
>
> > Why is the reach for cloudfare and ptbtime1 so bad? Is it a compatibility problem
> > or are the servers overloaded?
> >       
> Some major network operators have middleboxes that rate limit long NTP
> packets as a mitigation for the ntpd mode 6/7 amplification attacks.
> There is not much we can do, except move NTP to a different port. The
> NTP working group is working on a draft to do that, but it will take
> time.
>
>