fix: time-impurity within boringtun library
#45
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
thomaseizinger
changed the title
boringtun library
thomaseizinger
force-pushed
the
feat/fix-time-impurity
branch
from
f4bc849 to
4987ed2
Compare
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jan 7, 2025
As per the WireGuard spec (https://www.wireguard.com/papers/wireguard.pdf#page=14), every time an expiring timer causes a handshake initiation, a random jitter between 0 and 333ms should be added. This prevents nodes from attempting to re-initiate a new session at the same time. In Firezone's strongly-deterministic test suite, this is triggered very easily because we advance time at the exact same pace. In order to make use of the deterministic functions added in #45 within Firezone, this needs to be fixed. Generating the jitter requires randomness. In order to be deterministic, a new `rng_seed` parameter is added to the `Tunn::new_at` function. An observer cannot guess this seed and thus, will be unable to proactively attempt to initiate handshakes at the same time as the current node. Fixes: #19.
This was referenced Jan 7, 2025
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jan 9, 2025
With #45, the need for mocking `Instant` in order to test time-related functionality has been obsoleted. All functions simply take `Instant` as a parameter now. In order to preserve backwards-compatibility, an empty feature has been added that replaces the optional dependency.
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jan 13, 2025
At present, `boringtun`'s time handling works by storing the "current" time on every update to `update_timers_at`. This time is then used to timestamp sessions, keep-alives etc. This isn't as precise as we can be! With #45, we now track time as an explicit dependency to all functions, meaning functions such as handling an incoming packet already have access to precisely the current time! We can leverage this to use that provided timestamp instead of keeping around the `TimeCurrent` timer. This results in a few more parameters here and there but makes reasoning about time within `boringtun` easier. Depends-On: #58.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In its current implementation,
boringtunis impure w.r.t. time because it callsInstant::nowandInstant::elapsedinternally. To test time-related functionality, themock-instantdependency is currently used.This is unnecessary and can also be solved by introducing
Instantparameters to all necessary functions.This PR does that in a fully-backwards compatible way by introducing
_atfunctions for all necessary public functions that require the current time.Resolves: #41.