# Eth 2.0 DoS Workshop

29/10/2018 - Ethereum 2.0 workshop in Prague.

Attendees:
- Paul Hauner
- Nishant
- Jacek
- Mikerah
- Medhi
- Mike
- Mamy

## Objectives

1. Create a list of potential DoS vectors.
2. Explore mitigations for identified vectors.
3. Recommendations

## DoS Overview

Denial of Service attacks prevent a service from performing it's duty. Typically they involve the consumation of all available resources so that a service can no longer function.

In the context of Ethereum 2.0, some things to consider may involve:
* Mechanisms that causes nodes of the P2P network from functioning.
* A flaw in implementation could cause a node crashes on a block, or suffer a memory leak. ([e.g.](https://blog.ethereum.org/2016/09/18/security-alert-geth-nodes-crash-due-memory-bug/))
* If attacking a small subset of nodes could prevent messages from being delivered in a timely manner.
* An onerous requirement of the specification which is not considered.
* Certain operations may require an unexpectedy large amount of resources. ([e.g.](https://blog.ethereum.org/2016/09/22/ethereum-network-currently-undergoing-dos-attack/))
* Promising that a large amount of data would be sent, then proceeding to "drip feed" the data, maintaining a large number of open sessions
* A method to leverage traffic in the P2P network for amplification
* A small amount of data can trigger a large amount of data. ([e.g.](https://en.wikipedia.org/wiki/Denial-of-service_attack#Amplification))
* Any kind of "broadcast" messages.

## Attack Vectors

### 01: Storing Early Blocks

An attacker could create many blocks that from "the future" which a client would need to store, potentially filling up RAM/disk.

#### Mitigations

1. Ensure that there is some safe maximum to the amount of blocks that are queued awaiting a future slot.

### 04: Czech Roulette (more formally known as the Non-Deterministic Shuffling Problem (NDSP))
taking the randomness seed from the head block of the chain, means that any short range fork that also triggers that state transition might have a different randomness seed. This would cause multiple valid shufflings for the next cycle which would make it not possible to reject blocks from validators that don’t fit your world view of the shuffling. This is bad because it opens up a serious dos vector.

The further back you put the seed into the chain (say you get the seed from N cycles ago, rather than from the current cycle), then the higher likelihood that the seed is coming from a block you see as finalized and thus at least a deterministic seed.

This doesn’t actually solve the problem though because of the variability of whether a validator set change happened at the state transition. Say block A comes in and triggers a state transition but does not include enough attestations/crosslinks to trigger a validator set change. Block B (a shortrange fork) comes in, also triggers the state transition, but includes enough attestations/crosslinks to trigger a validator set change. Even if A and B agree on what seed they should use if there is a reshuffling, A would cause the reshuffling while B would so you’d have mismatched expected proposers
that’s a quick dump of the range of the problem.
(Taken from Danny's answer in Gitter. Will need to clean up and make clearer later)

### 02: Invalid `AttestationRecord` Signatures in Blocks

An attacker could create blocks which contain a majority _valid_ `AttestationRecord` signatures, however have a single _invalid_ signature which makes the entire block invalid.

This would cause the client to waste CPU cycles in validation BLS signatures.

#### Mitigations

1. Ensure the block proposer `AttestationRecord` (the 0'th) is validated before all other `AttestationRecords`. This reduces the space of attackers to only the designated block producer.
2. Do a "coin flip" to determine the order in which `AttestationRecords` are verified, with the exception of the 0'th record. This would mitigate for the scenario where an attacker always knows that the last record in the array will be the last to be verified. Processing records concurrently would also assist making it difficult to predict the last record to be processed.

### 03: Invalid "free" `AttestationRecords`

An attacker could produce "free"`AttestationRecords` (ones that are not included in blocks) that have an invalid signature and waste client CPU cycles.

#### Mitigations

See 02.

### More to come..

--------------

## Notes

### Specification Vectors

_(can someone do the notes here?)_

### Implementation Vectors

### Network Vectors

### Questions
1. How does libp2p rank peers?
2. In particular, how does it define a "bad" peer?
3. How does it deal with "bad" peers?
2. Does a malicious validator bring down other valiators if they send an invalid block (or any misbehavior)?