View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003932 | GNUnet | core service | public | 2015-08-07 17:16 | 2022-02-23 23:01 |
| Reporter | dangole | Assigned To | Christian Grothoff | ||
| Priority | low | Severity | feature | Reproducibility | N/A |
| Status | feedback | Resolution | open | ||
| Product Version | Git master | ||||
| Summary | 0003932: GNUnet relies on absolute time | ||||
| Description | In 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 Reproduce | Obvious, right? | ||||
| Tags | No tags attached. | ||||
|
|
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). |
|
|
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... |
|
|
Yes, that's what I suggested as the "alternative", and yes, it won't be trivial at all. |
|
|
https://github.com/aphyr/distsys-class#wall-clocks |
|
|
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. |
|
|
Is this still a thing with hello-ng? |
|
|
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. |
| 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 |
