The network key should periodically change

[tomaka]

paritytech/smoldot#3077

[tomaka]

Right now, it is intended that the network key gets regenerated every time the light client is loaded. This doesn't work due to the issue found by paritytech/smoldot#3095

However, this is IMO not enough. Smoldot could in principle run for days or weeks, in which case the network key should indeed get periodically regenerated.

[tomaka]

The modifications needed for this issue probably overlap with #111

[tomaka]

I can see three ways of implementing the rotation:

• Rotate the network key if we hit 0 peers, meaning that it would rotate for example if you lose Internet connectivity for a while or if you put your laptop in sleep mode.
• Rotate the network key at a periodic interval, and when doing so kill all existing connections.
• Allow a mix of connections with multiple different local PeerIds, and periodically rotate the network key used for newly-established connections only, without touching the existing connections.

As a reminder, the objective is to avoid giving the possibility for full nodes to maintain a map of IP address <=> PeerId, since that would allow tracking users if they move around the planet.

Solution 3 seems strictly superior in all ways to solution 1, assuming that the key rotation period is small enough to not give the time for the user to travel somewhere and maintain the same key. We could also do solution 3, but rotate the key both periodically and when we hit 0 peers.

One thing that could unfortunately happen is: the user is on a fixed location IP that is geotracable, then switches to mobile IP while keeping the same PeerId, then switches again to another fixed location IP that is geotracable while keeping the same PeerId. Even if the PeerId rotates, as long as it doesn't rotate precisely when the IP address changes, the full node can trace the movement between the two fixed location IPs.

However I think that we can simply ignore this corner case, and do this on a best effort rather than reliably.

[tomaka]

One tricky issue I didn't think of is how to handle the Kademlia protocol. This is to be brain stormed.

[tomaka]

One tricky issue I didn't think of is how to handle the Kademlia protocol. This is to be brain stormed.

I think that it's actually a non-issue.
Light clients rotate their key but don't need to have k-buckets, and full nodes don't rotate their key.
It would only be an issue if you both need k-buckets and rotate your key.

[tomaka]

After #1255 this is done for the light client.
The full node should do this as well, but it's obviously more complicated due to the fact that it has to maintain k-buckets and is supposed to be reachable for a long time.