forked from cloudflare/boringtun
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix: only rekey after timeout from first unreplied packet (#66)
As other forks have already identified (e.g. [0]) and tracked in an upstream issue ([1]), `boringtun` currently has a bug that makes it perform spurious rekeys because it considers the session dead due to "missing replies" from the remote. The WireGuard spec forsees a passive keepalive mechanism that - in the absence of an organic reply to a data message (i.e. an ICMP echo reply to an ICMP echo request) - a WireGuard keepalive message is sent after `KEEPALIVE_TIMEOUT` ([2]). Thus, we can assume that a healthy peer will reply to every data packet, either naturally or with a keepalive. If don't receive _any_ packet within `KEEPALIVE_TIMEOUT + REKEY_TIMEOUT` after sending one, the session should be considered dead and we want to initiate a new handshake. At present, `boringtun` tracks this timer from when it last received a packet. This is wrong because the last received packet may be quite old and thus, as soon as we send a new packet, the "grace period" is immediately reached not even giving the remote time to answer. This results in the spurious rekeys mentioned in other forks and also upstream. To fix this, instead of just tracking whether we have sent unreplied packets, we track when we have sent the first packet that hasn't seen a reply yet. This allows us to correctly apply the grace period of `KEEPALIVE_TIMEOUT + REKEY_TIMEOUT` and only invalidate the session if the remote doesn't reply within that period. [0]: NordSecurity#8 [1]: cloudflare#363 [2]: https://www.wireguard.com/papers/wireguard.pdf#subsection.6.5
- Loading branch information
1 parent
a0a4ab0
commit 2f0467f
Showing
2 changed files
with
107 additions
and
11 deletions.
There are no files selected for viewing
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
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