Re: Need for HW-clock independent timestamps

[Kalin KOZHUHAROV <me.kalin@gmail.com>]

On Tue, May 15, 2018 at 10:21 PM, Devan Carpenter <mail@dvn.me> wrote:
> Aaron Jones transcribed 3.1K bytes:
>> On 12/05/18 19:29, Axel Neumann wrote:
>> > You want WG to secure your network. So the suggestion can not be to open
>> > your network for a pretty insecure deamon in order to get WG working.
>> > This would essentially allow attackers to a fake the ntp server and then
>> > block WG forever.
>>
>> Someone in a position to fake NTP (which needs bidirectional
>> communication) is already in a position to block WG forever (by simply
>> refusing to forward its packets).
>>
>> Additionally, there are a few very well-designed and secure NTP daemons
>> out there (such as OpenNTPd).
>>
>
> Using NTP is not a viable solution for a distributed mesh network. What
> if the Internet is only accesible via WG, or what if the network is not
> connected to the Internet at all?
>
Why do you need the Internet at all?
You can do as simple as plug a $20 GPS receiver (serial/USB) in any
node and get precise time that is shared with others in the network.
Heck, even go analog and use the Colorado WWV radio signal.
Or go fancy and buy a dedicated Cesium-backed "private" NTP server.

> It's not a trivial problem, but I think it would be benefecial to WireGuard as a project to not depend on
> centralized time authority *if there is an option not to*.
>
I wouldn't call universal time a "centralized authority", it is more
of a well-agreed-upon concept.
With a clear view of the sky and some math, you can use the stars (Sun
incl.) even and nobody can ban you from knowing the time.
It is not like say centralized DNS.

So, yes you need a method for obtaining the time at somewhat precise
scale[1], but "NTP-to-I'net" is just one somewhat convenient method.

[1]  Can anyone point me to the piece in code that shows that
precision? In other words, how far apart can 2 peers' clocks be and
still connect.
I spend some time grepping, but couldn't find it... I guess it is
connected to 'REJECT_AFTER_TIME = 180 * HZ;' ?

Cheers,
Kalin.