Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

additional attestation subnet validations for dos resistance #1595

Closed
djrtwo opened this issue Jan 24, 2020 · 9 comments
Closed

additional attestation subnet validations for dos resistance #1595

djrtwo opened this issue Jan 24, 2020 · 9 comments

Comments

@djrtwo
Copy link
Contributor

djrtwo commented Jan 24, 2020

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.

@djrtwo djrtwo changed the title additional attestation subnet validations additional attestation subnet validations for dos resistance Jan 24, 2020
@AgeManning
Copy link
Contributor

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

@djrtwo
Copy link
Contributor Author

djrtwo commented Jan 25, 2020

Yeah, that makes sense!

Any reason to not make that max 1?

@mkalinin
Copy link
Collaborator

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
Copy link
Contributor Author

djrtwo commented Jan 28, 2020

@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
Copy link
Contributor Author

djrtwo commented Jan 28, 2020

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
Copy link
Contributor Author

djrtwo commented Jan 28, 2020

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
Copy link
Collaborator

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
Copy link
Contributor

AgeManning commented Jan 30, 2020

@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
Copy link
Contributor Author

djrtwo commented Feb 12, 2020

closed via #1615

@djrtwo djrtwo closed this as completed Feb 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants