waku-org
/
research
mirror of https://github.com/waku-org/research.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

add notes on client as attacker

This commit is contained in:
Sergei Tikhomirov 2023-10-17 17:24:29 +02:00
parent 60f3aaa62e
commit 25bed7304a
1 changed files with 16 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
incentivization.md
View File

@ -71,14 +71,14 @@ See also: https://rfc.vac.dev/spec/17/
In the i13n context, we can't prove whether a message has indeed been broadcast in the past. In the i13n context, we can't prove whether a message has indeed been broadcast in the past.
Instead, we use RLN proofs as a proxy metric. Instead, we use RLN proofs as a proxy metric.
A valid RLN proof signifies that the message has been generated by a node with an active membership during a particular eposh. A valid RLN proof signifies that the message has been generated by a node with an active membership during a particular epoch.
TODO: make sure the above is correct: what exactly does RLN prove? TODO: make sure the above is correct: what exactly does RLN prove?
## Deviations from the desired behavior ## Deviations from the desired behavior
There are multiple ways for a node to deviate from the desired behavior. There are multiple ways for a node to deviate from the desired behavior.
TODO: are we talking only about the server here, or should also discuss client (e.g., DoS)? We look at potential misbehavior from the server side and from the client side separately.
### Slow response ### Server: Slow response
The server takes too long to respond. The server takes too long to respond.
Possible reasons: Possible reasons:
- the server is offline accidentally; - the server is offline accidentally;
@ -86,7 +86,7 @@ Possible reasons:
- the server is malicious and deliberately delays the response; - the server is malicious and deliberately delays the response;
- the server doesn't have some of the relevant messages and tries to request them from other nodes. - the server doesn't have some of the relevant messages and tries to request them from other nodes.
### Incomplete response ### Server: Incomplete response
A relevant message is missing from the response. A relevant message is missing from the response.
Possible explanations: Possible explanations:
- the server didn't receive the message when it was broadcast; - the server didn't receive the message when it was broadcast;
@ -96,15 +96,25 @@ Contrary to blockchains, Relay doesn't have consensus over relayed messages.
Therefore, it's impossible to distinguish between the two scenarios above. Therefore, it's impossible to distinguish between the two scenarios above.
TODO: given this fact, what's the best we can aim for? TODO: given this fact, what's the best we can aim for?
### Irrelevant response ### Server: Irrelevant response
The response contains a message that is not relevant. The response contains a message that is not relevant.
There are two scenarios here depending on whether RLN proofs are enforced. There are two scenarios here depending on whether RLN proofs are enforced.
If RLN is not enforced, a server may insert any number or irrelevant messages into the response. If RLN is not enforced, a server may insert any number or irrelevant messages into the response.
If RLN is enforced, a server can only do so as long as it has a valid membership to generate the respective proofs. If RLN is enforced, a server can only do so as long as it has a valid membership to generate the respective proofs.
This doesn't eliminate the attackbut limits its consequences. This doesn't eliminate the attack but limits its consequences.
TODO: what are the powers of a malicious server when it comes to generating proofs for irrelevant messages? Can the server generate proofs for past epochs? TODO: what are the powers of a malicious server when it comes to generating proofs for irrelevant messages? Can the server generate proofs for past epochs?
### Client: Too many requests
The client sends many request to the server within a short period of time.
This may be seen as a DoS attack.
### Client: Request is too large
The client sends a response that incurs excessive expenses on the server.
For example, the request covers a very long period in history, or, more generically,
a period that contains many messages.
This may also be seen as a DoS attack.
## Privacy considerations ## Privacy considerations
Light protocols, in general, have weaker privacy properties than P2P protocols. Light protocols, in general, have weaker privacy properties than P2P protocols.