Trust system: track full Peer.t instead of just IPs #4096
Labels
Comments
bkase
pushed a commit
that referenced
this issue
Feb 10, 2020
This is the revival of the tmp/cmr/net2 branch rebased onto develop. Some important user-facing changes: - No separate discovery/communication/etc ports. One port for all public daemon communications. - Automatic port forwarding with UPnP. If your local network supports UPnP, there should be no configuration required. - Local peer discovery. If your local network supports mDNS broadcast, coda daemons will automatically discover each other. This includes several daemons on the same machine- no more building peer lists! - New libp2p keypairs. These are managed the same as our key pairs with secret_file. Without configuration, key pairs are ephemeral and will disappear when the daemon restarts. (TODO: should we instead persist the keypair? does it matter for non-infrastructure?) Some important internal changes: - All daemon-daemon connections are now authenticated and confidential. - Connections are no longer transient and per-request. Individual requests get multiplexed as their own stream over the one connection between the peers. This is analogous to HTTP/2. Outgoing connections will appear to originate from the libp2p listening port, vs some transient port. Outstanding details: - Trust system needs to get augmented to track Peer.t instead of just an IP. Until then we can't implement ban_notify (#4093, #4096). - Libp2p has little per-connection structured reporting, some things we currently penalize trust for are not detected (eg opening a libp2p connection without also opening a coda RPC stream) (#4098). - New pubsub allows banning senders by peer ID. We currently don't do this but we should ban peerIDs that originated bad info and not just the IP of the whoever relayed it to us (#4096). - ~~Current pubsub validation flow goes a bit against the libp2p grain, and it's not clear to me that the current behavior will survive [this libp2p PR](libp2p/go-libp2p-kad-dht#388). There's an inline comment near the should_forward_message impl (#4097).~~ done - Connection limit enforcement (#4095) Other changes: - Rips out the last vestiges of old membership, which aren't in use. - The connection info in envelopes is much more accurate now. We shouldn't start trusting it just yet due to some future vagaries around relaying. - bump nixpkgs version Future improvements: - IPv6. There's a hardcoded IPv4 assumption in the helper around IP filtering. - Investigate libp2p autorelay. This should help nodes in restrictive networks achieve better connectivity, but has a host of problems. - Intelligent request routing. I believe we can use the "provider" feature to, at the very least, only send eg sync/bootstrap requests to nodes who believe themselves to be in sync. There are other options.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We need to be tracking the peer IDs for trust actions, and not just the IP. This is necessary for #4093, and enables banning by peer ID (eg originator of pubsub messages).
The text was updated successfully, but these errors were encountered: