P2P: Validations for certain messages allow spam

[dylanlott]

An attacker could create a slashable message, and then use that to create valid-looking slashing messages that could be spammed.

https://github.com/ethereum/eth2.0-specs/blob/v0.10.0/specs/phase0/beacon-chain.md#proposer-slashings

https://github.com/LeastAuthority/eth2.0-specs/blob/dev/specs/phase0/p2p-interface.md#global-topics

[keks]

Hm, for each slashable message they can only create one slashing-message, right? So the only thing they can do is send the same message over and over again? Or do you think more complex attacks are possible?

[djrtwo]

Thanks for bringing this to my attention in telegram. Copying over some relevant notes of mine from telegram wrt voluntary_exit, proposer_slashing, and attester_slashing.

tldr; just like attestation and beacon_block messages -- once an attacking validator creates 1 slashable offence, they can can create an infinite number without further punishment. Protecting against such a dos vector with further gossip channel conditions is prudent.

notes from telegram

I was admittedly lazy on those three message types 😬. The functions referenced check the validity of the message and I wanted to avoid repeating each of those checks in the p2p spec. Beyond that in light of the mods coming to the other gossip types, it seems these message types could use some additional rules in their gossip channel.

To create a valid proposer slashing or attester slashing, a validator would have to create a slashable message (double signing, etc). This provides some protection in these messages not being common, but they then have the same problem as previously discussed with blocks and attestations. Once you make 1 slashable message, you can now create any number without additional punishment

Something worth stating explicitly — all gossip channels have an implicit rule to not gossip duplicate messages (the algorithm we use maintains some cache for a time to drop strict repeats — this is what we use message-id for). Beyond that it seems prudent to add rules that prevent valid-looking messages flooding from a single validator (thus the rules being discussed in issue 1595)

For voluntary_exit the rule can just be one valid voluntary exit per validator (maybe flushing cache per epoch or set of epochs). A slightly more advanced rule would be to only broadcast an additional exit for a validator if it has a more recent exit epoch than one you previously know about. I’d say this is likely not a valuable feature to distinguish but thinking about it more

For proposer_slashing, we likely want to limit this to 1 per validator — a slashing is a slashing and further unique slashable messages for the same validator do not provide additional value. Otherwise, a to-be-slashed validator could create infinite different proposer-slashings and dos the gossip.

For attester_slashing this is a little tougher because the slashable attestations contained within can contain many different validators. We could make the condition that the slashable attestations contain new validators (in the overlap between the two included attestations) not yet seen in another attester_slashing.

[djrtwo]

Hm, for each slashable message they can only create one slashing-message, right?

Being slashed is binary -- a validator is or is not. If say you create two block proposals for the same slot, then you can create an unbounded amount of additional block proposals (slightly modify the contents of the block) for that slot without any additional punishment being able to be brought upon you.

[nginnever]

For attester_slashing this is a little tougher because the slashable attestations contained within can contain many different validators. We could make the condition that the slashable attestations contain new validators (in the overlap between the two included attestations) not yet seen in another attester_slashing.

Is this problem twofold, where slashable attestations can be accumulated by 1) number of validators committing offense during a given slot, and 2) number of previous slots for which these sets of validators committing slashing offenses in the past and has not yet been propagated.

Does this also create the same issue as #1595 with Aggregate and proof subnet dos vector. Where we should consider a set of attester slash messages similar to a valid attestation aggregate. I.e. what if a batch of slashable attestations is sent out in increasing order from small to large.

[djrtwo]

So they could be sent out increasingly from small to large, or just with a single validator per attestation (totally non-aggregated). This is not as bad as the aggregation case because it does not allow all combinations of a committee but just a single additional message per unique validator.

My intuition here is that if we do limit it to max(1) message per validator by not broadcasting slashings without a validator that has not yet been seen as slashed, then we are fine. The cost to produce an additional valid message is to slash an additional validator which is a cost of at least 1 ETH and ejection from the validator set with ~36 days before withdrawability (EPOCHS_PER_SLASHINGS_VECTOR). In addition to this the amount burned increases the more you do this due to the variable slashing mechanism.