On Tue, 8 Jan 2019 at 03:43, Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Mo, 07.01.19 16:58, Stephen John Smoogen (smooge(a)gmail.com) wrote:
> > I wonder if it is worth introducing an entirely new tracking concept
> > here if you actually don't want to track but just count. The NTP
> > approach has the benefit that you introduce no new tracking concept at
> > all, but you just use the data that is pretty much generated
> > anyway. It also makes this all feel less one-sided, after all you
> > provide them with a deal: fedora gives the user correct time, the user
> > is therefore counted.
>
> The problems with NTP are the following:
> 1. The administrative headaches of regular
> blocks/takedowns/ill-advised security emails because our servers are
> attacking someone's box on port 123. [As funny as this sounds, getting
> regular angry emails from some site whose security tool has decided
> that 123/{tcp,udp} is a major threat still occurs. ]
This is not realistic. NTP is not really just an option, it's pretty
much a must-have in todays's Internet. You cannot properly validate
SSL certs if you don't have correct time, which shuts you out of a
good part of the Internet, including typical download servers that do
https.
I don't disagree that it should be unrealistic. I also know that it
still gets reported regularly as an attack and sites get dropped
off/spam blocked because some antivirus/firewall router reported it to
<fill in major cyber security company>. As such it needs to be listed
as a possible problem. [This is just the usual risk management CYA so
that when it does happen we can say 'we considered it a risk and
mitigated it with X'. I just don't have an X when I wrote that list
and don't want it to be 'spend 2 hours a day calling clients who can't
connect to RH data-centers because someone thought 123 was a hacker
attack.' ]
If a system doesn't do NTP then it will cetrainly encounter a lot more
problems then are created by switching from NTP pool servers to Fedora
servers by default.
Moreover, afair we install and enable NTP clients by default on all
our installations, no? just like pretty much any other OS these days
does... counting by NTP mostly just means switching from NTP pool
servers to fedora's own servers.
> 2. NTP bandwidth while small per system grows a lot as you wrack up
> servers randomly checking in. Having a pool of servers around the
> world would require us to get NTP GPS clocks, getting the datacenters
> to put the antenae out and a bunch of other items. [The budget for
> this is non-zero.]
Nah, that's not how NTP works, you don't have to have a "GPS clock",
you can simply replicate the time of a set of upstream servers, that's
totally OK.
I expect I am running off of old knowledge as I got out of running NTP
servers 10 years ago. At that time it was 'required' that a stratum 1
clock was supposed to have a GPS, atomic or similar solid time. If you
are just relaying you are supposed to be a stratum 2 clock. If you are
the main clock for a large set of systems you should be a stratum 1
system. If you ran a dedicated system you wanted to have 3-5 systems
spread out.
For how the old way of doing things was
https://www.endruntechnologies.com/stratum1.htm
I expect with a large pool of stratum 2, the noise between them is
averaged out of over time lowering the need for a clock. I will go
look at current best practices and revise.
--
Stephen J Smoogen.