gossipsub v1.1: Security extensions to improve on attack resilience and bootstrapping

[vasco-santos]

With the new spec of the gossipsub protocol already finished and implemented in go-libp2p, other implementations are starting to update to v1.1

While it is backwards compatible with v1.0, there are important updates regarding security, as well as bootstrapping that makes it important to update sooner rather than later.

@wemeetagain what are your expectations for this update?

---

Gossipsub v1.1 checklist

• explicit peer agreements - gs1.1 direct connect #99
• peer exchange (PX) on prune - gs1.1 peer exchange #100
• graft/prune backoff gs1.1 pruning backoff #95
• flood publishing - gs1.1 flood publishing #89
• adaptive gossip dissemination - gs1.1 adaptive gossip #94
• outbound mesh quotas - gs1.1 outbound mesh quota #91
• peer scoring - gs1.1 peer score #83 gs1.1 Integrate peer score #87
  • score thresholds - gs1.1 peer score #83
  • heartbeat maintenance gs1.1 outbound mesh quota #91
  • opportunistic grafting - gs1.1 opportunistic grafting #96
  • score function - gs1.1 peer score #83
  • topic parameter calculation and decay - gs1.1 peer score #83
  • extended validators - gs1.1 extended validators #93
• spam protection measures
  • GRAFT messages for unknown topics are ignored - gs1.1 outbound mesh quota #91
  • IWANT message responses are limited in the number of retransmissions to a certain peer - gs1.1: feat: track ihave/iwant counts #104
  • IHAVE messages are capped to a certain number of IHAVE messages and aggregate number of message IDs advertised per heartbeat - gs1.1: feat: track ihave/iwant counts #104
  • In flight IWANT requests, sent as a response to an IHAVE advertisement, are probabilistically tracked. feat: add iwant request tracking #107
  • Invalid message spam, either directly transmitted or as a response to an IHAVE message is penalized by the score function gs1.1: feat: add invalid message spam protection #113

Polishing

• refactor libp2p-pubsub feat: refactor validate libp2p/js-libp2p-pubsub#61 feat: update publish function signature libp2p/js-libp2p-pubsub#62 feat: refactor peer class libp2p/js-libp2p-pubsub#63 chore: refactor topics map libp2p/js-libp2p-pubsub#64 chore: refactor messagePublicKey libp2p/js-libp2p-pubsub#65 chore: fix verifySignature libp2p/js-libp2p-pubsub#66
• refactor gossipsub to use libp2p-pubsub v0.6.x chore: update libp2p-pubsub #110
• refactor internal maps to use string peer ids where appropriate gs1.1: use string peer id consistently #111
• allow node configurability of constants gs1.1: configurable overlay params #112
• copy go-libp2p-pubsub gossipsub tests
• final close reading of go-libp2p-pubsub, ensure nothing was missed gs1.1: use publishThreshold for floodsub fallback peers #102 chore: update gossipsub multicodec #108
• migrate ts/pubsub.js to libp2p-pubsub repo

[wemeetagain]

Thanks for bringing this up!
We'll be needing v1.1 for our purposes sooner rather than not. ethereum/consensus-specs#1792

We can start the implementation initiative in the next few weeks.
Do you see any potential blockers for implementing this? Should we wait for libp2p 0.28 for the refactored peer store?

[vasco-santos]

I was thinking about that last week, but I think that only the gossipsub protocol here needs to be updated. We aim to get the libp2p@0.28 release candidate soon, but this can be a parallel effort, since we will not need to do any release for it. We just need to guarantee that libp2p@0.28 comes in earlier because the update here will come with no PeerInfo.

Anyway, let me know here when you start working on it, so that we get aligned and I can unblock you with anything that is needed :)

[wemeetagain]

Ok, thanks for the info, I had forgotten that we are already ready to go for 0.28 here.
I've read through the specs and some supplemental docs. Planning on setting aside time late this week as well as next week to start a branch.

One question I have is around the signed envelopes and peer routing records described here libp2p/specs#217
How do you see those standards implemented for js-libp2p? Will these live in separate repos, to be (re)used here and elsewhere?

[vasco-santos]

We foresee libp2p to provide the node's signed addresses via its API (it would be cached interally and updated when the addresses change).

So, I would say for you to not worry about that. Me or Jacob can work on that, and then we integrate this in gossipsub as a follow up PR. It should be straightforward. However, if you want to get it in js-libp2p as well, I would not say no 😆 But let's focus first on updating everything here, and than we can just call this API method

[wemeetagain]

taking notes on https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md for my own organization
see also: libp2p/go-libp2p-pubsub#263

• explicit peer agreements:
  • list of peers, similar to bootnodes
  • connect on router boot, periodic reconnect check
  • forward all messages to them (peer agreements are not per-topic)
  • do not graft, do not accept graft, respond with prune
• peer exchange (PX) on prune
  • ensure pruned peers do not regraft, maintain an entry for a backoff period
  • regrafting violations result in pruning and backoff period extension
  • prune control message optionally includes "peer infos" of other peers in the topic
  • "peer infos" include peer id and (optionally during transitional phase) signed peer record (fetched via libp2p api)
  • if pruned, attempt to reform full mesh by connecting to peer infos we receive, if peer score is above acceptPXThreshold
• flood publishing
  • optional feature, should be configurable (defaulted on?)
  • publish all own messages to all peers above publish threshold
  • peers must be above publishThreshold
• adaptive gossip dissemination
  • send gossip to random max((peers above gossip threshold) * gossip factor), D_lazy) peers
  • gossiped peers must have score above gossipThreshold
• peer scoring
  • configurable thresholds (gossipThreshold, publishThreshold, graylistThreshold, acceptPXThreshold, opportunisticGraftThreshold)
  • maintain score for each peer
  • one score per peer, 6 parameters feed the score, 4 parameters are per-topic, 2 are global
  • score maintained for some time after a peer disconnects
• heartbeat maintenance
  • peers with negative scores get pruned from all meshes
  • when pruning bc of oversubscription, sort peers by score to prune lowest scoring peers first, randomly pick in case of tie
  • when grafting bc of undersubscription, filter out negative scored peers
• opportunistic grafting
  • periodically check for median score of peers in mesh (per topic?)
  • if score is below opportunisticGraftThreshold, graft two peers above the score to graft
• extended validators
  • validator function must support at minimum 3 outputs: accept, reject, ignore
• Topic Parameter Calculation and Decay
  • configurable decay interval, param-specific decay factor
• each score param
  • read spec
• new configurable params
  • see spec for list
• spam protection measures
  • graft from unknown topics are ignored, no prune returned
  • track iwants responded to by peer, limit to certain number, drop after threshold reached

[wemeetagain]

🎉