WireGuard and distributed hashtables

[zrm <zrm@trustiosity.com>]

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