-
Notifications
You must be signed in to change notification settings - Fork 12
Description
Background:
In gossip_producer.rs is a function called produce(). Toward the end of this function is a big // TODO comment on code that decides, for each Node in the Gossip produced, whether the Gossip target will be given that Node's IP address.
The gist of the existing code is that if it looks like the target Node already knows the candidate Node's IP address, then we'll go ahead and tell it, since it won't be revealing a secret.
However, upon further reflection, we think this is silly, unnecessary, and dangerous.
- If a Node already knows another Node's IP address, it doesn't need to receive it in Gossip.
- If we're Node A sending Gossip about Node B to Node C, and we notice that Node B's IP address has changed since the last time we sent Gossip to Node C, Node B will have informed Node C already; that responsibility is not ours.
- Given the way the existing code works, Node C could be an evil Node that is claiming to have a neighborship with B when it really doesn't; in that case we will blithely supply it with B's IP address and create a security problem.
Task:
In general: Fix things so that Standard Gossip never contains any IP addresses at all. Debut Gossip doesn't really need an IP address either, because the Gossip itself is coming over the network from an IP address, which can be read more reliably from the network stack. The only kinds of Gossip that really need to reveal IP addresses are Introduction Gossip and Pass Gossip. And these only need to reveal the IP addresses of the introducee and pass target, not that of the Gossip source, because again, the IP address of the Gossip source should come from the network stack.
Considerations:
- Make sure a Node can still alert its neighbors when its own IP address changes. This may or may not turn out to be a reason to keep a Gossip source's own IP address in the Standard Gossip it sends.
- The
qualify()methods in theGossipHandlerclasses are very particular about exactly how Gossip is supposed to look. When you remove IP addresses from Gossip, you'll technically be creating a different class of Gossip. Your new Gossip messages might not pass thequalify()constraints in the old code. Make sure you know what is going to happen when you release the new code. Is this going to be an official Gossip migration version, or are you going to deal with the consequences of a breaking change?
Metadata
Metadata
Assignees
Labels
Type
Projects
Status