Skip to content
Snippets Groups Projects
  • Kristian Klausen's avatar
    6d8afe73
    Improve time robustness by switching to chrony, trustworthy time sources and NTS · 6d8afe73
    Kristian Klausen authored
    From chrony FAQ[1]:
    "1.2. Should I prefer chrony over timesyncd if I do not need to run a
    server?
    
    Generally, yes.
    
    systemd-timesyncd is a very simple NTP client included in the systemd
    suite. It lacks almost all features of chrony and other advanced client
    implementations listed on the comparison page. One of its main
    limitations is that it cannot poll multiple servers at the same time and
    detect servers having incorrect time (falsetickers in the NTP
    terminology). It should be used only with trusted reliable servers,
    ideally in local network.
    
    Using timesyncd with pool.ntp.org is problematic. The pool is very
    robust as a whole, but the individual servers run by volunteers cannot
    be relied on. Occasionally, servers drift away or make a step to distant
    past or future due to misconfiguration, problematic implementation, and
    other bugs (e.g. in firmware of a GPS receiver). The pool monitoring
    system detects such servers and quickly removes them from the pool DNS,
    but clients like timesyncd cannot recover from that. They follow the
    server as long as it claims to be synchronised. They need to be
    restarted in order to get a new address from the pool DNS.
    
    Note that the complexity of NTP and clock synchronisation is on the
    client side. The amount of code in chrony specific to NTP server is very
    small and it is disabled by default. If it was removed, it would not
    significantly reduce the amount of memory or storage needed."
    
    This commit fixes the issue by switching to a proper NTP client
    (chrony), trustworthy time sources from Netnod and
    Physikalisch-Technische Bundesanstalt which distributes the official
    time for Sweden[2] and Germany[3] respectively, and finally NTS is used
    to protect against MITM attacks.
    
    Since most of our servers are in Germany or Finland (close to Sweden),
    it makes sense to use these time sources as a low round-trip delay[4] is
    preferred for NTP. For the few servers[5] we have outside Europe, the
    root delay[4] will be higher than desired, but with the current use-case
    for these servers, it should not be a problem.
    
    [1] https://chrony-project.org/faq.html#_should_i_prefer_chrony_over_timesyncd_if_i_do_not_need_to_run_a_server
    [2] https://www.netnod.se/swedish-distributed-time-service
    [3] https://www.ptb.de/cms/en/ptb/fachabteilungen/abt4/fb-44/ag-442/dissemination-of-legal-time.html
    [4] https://blog.meinbergglobal.com/2021/02/25/the-root-of-all-timing-understanding-root-delay-and-root-dispersion-in-ntp/
    [5] {america,asia,sydney}.mirror.pkgbuild.com
    Verified
    6d8afe73
    History
    Improve time robustness by switching to chrony, trustworthy time sources and NTS
    Kristian Klausen authored
    From chrony FAQ[1]:
    "1.2. Should I prefer chrony over timesyncd if I do not need to run a
    server?
    
    Generally, yes.
    
    systemd-timesyncd is a very simple NTP client included in the systemd
    suite. It lacks almost all features of chrony and other advanced client
    implementations listed on the comparison page. One of its main
    limitations is that it cannot poll multiple servers at the same time and
    detect servers having incorrect time (falsetickers in the NTP
    terminology). It should be used only with trusted reliable servers,
    ideally in local network.
    
    Using timesyncd with pool.ntp.org is problematic. The pool is very
    robust as a whole, but the individual servers run by volunteers cannot
    be relied on. Occasionally, servers drift away or make a step to distant
    past or future due to misconfiguration, problematic implementation, and
    other bugs (e.g. in firmware of a GPS receiver). The pool monitoring
    system detects such servers and quickly removes them from the pool DNS,
    but clients like timesyncd cannot recover from that. They follow the
    server as long as it claims to be synchronised. They need to be
    restarted in order to get a new address from the pool DNS.
    
    Note that the complexity of NTP and clock synchronisation is on the
    client side. The amount of code in chrony specific to NTP server is very
    small and it is disabled by default. If it was removed, it would not
    significantly reduce the amount of memory or storage needed."
    
    This commit fixes the issue by switching to a proper NTP client
    (chrony), trustworthy time sources from Netnod and
    Physikalisch-Technische Bundesanstalt which distributes the official
    time for Sweden[2] and Germany[3] respectively, and finally NTS is used
    to protect against MITM attacks.
    
    Since most of our servers are in Germany or Finland (close to Sweden),
    it makes sense to use these time sources as a low round-trip delay[4] is
    preferred for NTP. For the few servers[5] we have outside Europe, the
    root delay[4] will be higher than desired, but with the current use-case
    for these servers, it should not be a problem.
    
    [1] https://chrony-project.org/faq.html#_should_i_prefer_chrony_over_timesyncd_if_i_do_not_need_to_run_a_server
    [2] https://www.netnod.se/swedish-distributed-time-service
    [3] https://www.ptb.de/cms/en/ptb/fachabteilungen/abt4/fb-44/ag-442/dissemination-of-legal-time.html
    [4] https://blog.meinbergglobal.com/2021/02/25/the-root-of-all-timing-understanding-root-delay-and-root-dispersion-in-ntp/
    [5] {america,asia,sydney}.mirror.pkgbuild.com
Code owners
Assign users and groups as approvers for specific file changes. Learn more.