additional attestation subnet validations for dos resistance

[djrtwo]

Attestation subnet dos vector

Once a validator has created a slashable message (yet before they are taken out of the active set), they can create any number of slashable messages without any further punishment. There are likely consensus related risks worth investigating, but this issue focuses on the p2p gossip network.

Although creating multiple attestations during a slot is slashable, multiple can still have valid signatures. The current attestation subnet validation conditions would allow any number of valid attestations through in the gossip channel an would not be seen as duplicates in normal caches. This leads to an obvious DoS vector with a clear and calculable cost, and for that cost it is repeatable until the validator is ejected from the v-set.

Suggestion

Add the following validation condition to committee_index{subnet_id}_beacon_attestation:

This is the first attestation for the validator at this slot on this subnet

Aggregate and proof subnet dos vector

beacon_aggregate_and_proof subnet has a similar problem. The aggregator can send any number of different aggregate and proof messages that have different combinations of participants (if they are at least one of the participants).

This attack is discussed by @hwwhww in #1570 in which another actor can forge their own messages as long as the aggregator is included.

a few potential solutions

1. Naively, we can just allow one aggregate_and_proof per aggregator per slot with a similar validation condition as above, but an attacker could forge the message with a much less optimal aggregate and try to block the original good aggregate from making it far in the gossip.

2. A better suggestion is to only propagate an aggregate_and_proof if it is better (includes more validators) than any before seen for that aggregator at this slot. This prevents a rogue attacker from flooding the network or blocking the aggregator's good attestation, but still leaves open the aggregator themselves for semi DoS'ing by sending many aggregates sequentially from small to large (by val count). Some of these would manage make it through the network, but the extent of the attack is not as extreme.

3. The most extreme solution is to have the validator sign the aggregate_and_proof message itself and make double signing here slashable. This would close the attack vector, but would (1) add another consensus-message/slashing-condition, and (2) add another signature to verify when validating the gossip message (attestation_sig + proof_sig + aggregate_and_proof_sig

I'm thinking that (2) is a reasonable solution, but curious other's thoughts here.

[AgeManning]

Could we do a combination of 1 and 2 and cap the number of attestions from an aggregator per slot?

[djrtwo]

Yeah, that makes sense!

Any reason to not make that max 1?

[mkalinin]

What if aggregator signs AggregateAndProof message and then sends it to the gossip channel along with its signature? And there is a condition on propagation which drops messages with incorrect signature. Then we could identify each message and use option 1 to protect subnet from DoS attacks.

[djrtwo]

@AgeManning I think it was late on a Friday night when I agreed with combining of (1) and (2). Today, I'm not fully seeing why this is advantageous. By putting a limit on the number associated with an aggregator, we still allow the aggregator's neighbors to forge messages and try to block the actual "good" message that the aggregator created.

Is the idea that if we limit this to say 16 or 32 and combine it with (2), we increase the chance that the attacker will be able to forge enough worse messages to block the flow of the good message?

[djrtwo]

What if aggregator signs AggregateAndProof message and then sends it to the gossip channel along with its signature? And there is a condition on propagation which drops messages with incorrect signature. Then we could identify each message and use option 1 to protect subnet from DoS attacks.

Right, I see. As opposed to option (3), we don't enforce that the aggregator won't sign multiple via a slashing condition, but the condition (1) prevents the gossip channel from being DoS-able by the aggregator even if they sign multiple.

I like that.

The main downside is an additional signature verification per message. I'm not immediately certain if this is an efficiency loss we will care about

[djrtwo]

As discussed with an external contributor (not sure github handle), it is natural to add the same no-repeat-propagation condition for BeaconBlocks (associated proposer_index/slot)

[mkalinin]

The main downside is an additional signature verification per message. I'm not immediately certain if this is an efficiency loss we will care about

Right. Efficiency loss could be mitigated with techniques like double pairing: https://ethresear.ch/t/fast-verification-of-multiple-bls-signatures/5407/10.

[AgeManning]

@AgeManning I think it was late on a Friday night when I agreed with combining of (1) and (2). Today, I'm not fully seeing why this is advantageous. By putting a limit on the number associated with an aggregator, we still allow the aggregator's neighbors to forge messages and try to block the actual "good" message that the aggregator created.

Is the idea that if we limit this to say 16 or 32 and combine it with (2), we increase the chance that the attacker will be able to forge enough worse messages to block the flow of the good message?

I hadn't looked at @hwwhww's attack vector and hadn't thought about that in my original comment. Disregard the combination idea as it doesn't solve the issue you've pointed out. My bad

[djrtwo]

closed via #1615