Distributed hashtables use overlay routing networks that typically have
between dozens and thousands of peers per node. Suppose it's 480 peers.
Then a node might forward a message between two peers once a minute or
so (using of 2/480), but the mean time between use of a given peer link
could be an hour or more.
Now consider the WireGuard rekey-after time if DHT peer links are via
WireGuard. If keepalives are used so that an active key is always
available then a 120 second rekey interval with 480 peers has you doing
four rekeys per second despite mostly-idle peers. We'd have to measure
in rekeys per message rather than messages per rekey and have a lot of
idle chatter.
But not having active keys would _triple_ the DHT request latency.
Instead of a message from A -> B -> C, you get a handshake initiation
from A -> B, handshake response from B -> A, and finally the message
from A -> B, which then causes B to need a handshake with C.
The rekey time is fixed by the protocol.
If I was going to suggest a protocol change, what might help is to have
longer and shorter rekey-after/reject-after times and the long timeout
starts at handshake whereas the short timeout starts at the first
non-keepalive transport data message. Then a peer purposely kept active
with keepalives without any real traffic wouldn't have to be rekeyed so
often.
The question is, can anyone see a good solution to this that doesn't
involve a protocol modification?
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
