View Issue Details

IDProjectCategoryView StatusLast Update
0003932GNUnetcore servicepublic2022-02-23 23:01
Reporterdangole Assigned ToChristian Grothoff  
PrioritylowSeverityfeatureReproducibilityN/A
Status feedbackResolutionopen 
Product VersionGit master 
Summary0003932: GNUnet relies on absolute time
DescriptionIn decentralized mesh environments systems often have no means to have synchronized absolute time (as in "planetary time" or "wall clock time") due to the lack of access to any central time authority (as in NTP, GPS or NPL).
If system time is not synchronized, communication fails.
Aug 07 02:16:29-729042 core-2168 WARNING Ephemeral key message from peer `XXXX' rejected as its validity range does not match our system time (1438913789728960 not in [1438957895757173,1439001395757226]).

This affects autonomous systems quite badly, as there might not be any facility to syncrhonize time and small embedded systems typically don't have a built-in RTC.
Steps To ReproduceObvious, right?
TagsNo tags attached.

Activities

Christian Grothoff

2015-08-08 12:21

manager   ~0009544

Yes, that's been the case since 0.0: we said we require *roughly* synchronized global time and the protocol does use (absolute) expiration dates in various places.

In the 0.0 to 0.8 versions of the protocol, there were some features in CORE that really required the use of an absolute expiration time to protect against replay (this was pre-ECDHE), and thus is was actually best-practice to ensure that *all* signatures expired (since the availability of time was already an assumption build into a lower layer).

Right now, the NSE (network size estimation) protocol, which the DHT depends upon, still *fundamentally* requires roughly synchronized global time, and I see no way to avoid this. So even if we did eliminate the requirement at the CORE layer, other layers (at least NSE) will still have it.

An alternative solution might be to have a configuration option to say "this peer's hardware doesn't have a clue as to what the current time is and should learn it from the network" -- and then have such peers pull their neighbours and set the clock based on the result(s).

dangole

2015-08-08 13:29

developer   ~0009545

Grepping through the code, I found roughly 700 occurances of GNUNET_TIME_absolute_get. Finding ways to get around the need to use global time in all these places seems like a lot of work compared to the alternative:
Having better-than-nothing time-syncrhonization built-into CORE that can set host-time in situations where neither an RTC nor rdate, NTP nor any other means for time synchronization exists.
Doing that right is also not trivial, because it has to happen *before* relying on signature validity times and yet shouldn't be easily tricked by malicious or misconfigured nodes.
From what I remember, the BitCoin research paper had a strong focus on getting around absolute time and purely relying on precedence of events which led to the birth of the block-chain pattern...

Christian Grothoff

2015-08-08 13:35

manager   ~0009546

Yes, that's what I suggested as the "alternative", and yes, it won't be trivial at all.

dangole

2016-07-13 01:19

developer   ~0010989

https://github.com/aphyr/distsys-class#wall-clocks

Christian Grothoff

2016-08-03 11:55

manager   ~0011001

danogle: most of the uses of GNUNET_TIME_absolute_get() are pretty harmless, as they involve measuring local time to determine duration (performance measurements, latency measurements).

A few are more interesting because they relate to signature validity (in case records expire, etc.). I don't think we have a place where distributed time is used for ordering events.

Anyway the critical one is in CORE, as here the code prevents peers from even connecting if they are too desynchronized. If we fix that, we can then build distributed clocks at a higher level. Right now, I think this will happen _after_ the next release, as I try to batch/group changes that break protocol compatibility, and there is another related breakage change that is a few months away.

schanzen

2020-10-29 10:57

administrator   ~0017054

Is this still a thing with hello-ng?

Christian Grothoff

2022-02-23 23:01

manager   ~0018713

Yes, hello-uri.c still signs HELLO messages with addresses with a 2 day expiration time. It seems a bit dangerous to allow signatures completely without any expiration logic.
That said, this is indeed something we should discuss, and maybe revise. One particular sub-problem here is that the current hello-uri doesn't allow generating a HELLO message to be shipped with the distro, as the code doesn't offer a path for creating a HELLO with a longer or even indefinite expiration time.

Issue History

Date Modified Username Field Change
2015-08-07 17:16 dangole New Issue
2015-08-08 12:21 Christian Grothoff Note Added: 0009544
2015-08-08 12:21 Christian Grothoff Priority normal => low
2015-08-08 12:21 Christian Grothoff Severity major => feature
2015-08-08 12:21 Christian Grothoff Reproducibility always => N/A
2015-08-08 12:21 Christian Grothoff Status new => acknowledged
2015-08-08 13:29 dangole Note Added: 0009545
2015-08-08 13:35 Christian Grothoff Note Added: 0009546
2016-07-13 01:19 dangole Note Added: 0010989
2016-08-03 11:55 Christian Grothoff Note Added: 0011001
2020-10-29 10:57 schanzen Assigned To => schanzen
2020-10-29 10:57 schanzen Status acknowledged => feedback
2020-10-29 10:57 schanzen Note Added: 0017054
2022-02-22 23:11 schanzen Assigned To schanzen => Christian Grothoff
2022-02-23 23:01 Christian Grothoff Note Added: 0018713