mirror of https://github.com/waku-org/research.git
add notes on client as attacker
This commit is contained in:
parent
60f3aaa62e
commit
25bed7304a
|
@ -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.
|
||||
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?
|
||||
|
||||
## Deviations 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)?
|
||||
### Slow response
|
||||
We look at potential misbehavior from the server side and from the client side separately.
|
||||
### Server: Slow response
|
||||
The server takes too long to respond.
|
||||
Possible reasons:
|
||||
- the server is offline accidentally;
|
||||
|
@ -86,7 +86,7 @@ Possible reasons:
|
|||
- 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.
|
||||
|
||||
### Incomplete response
|
||||
### Server: Incomplete response
|
||||
A relevant message is missing from the response.
|
||||
Possible explanations:
|
||||
- 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.
|
||||
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.
|
||||
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 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?
|
||||
|
||||
### 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
|
||||
|
||||
Light protocols, in general, have weaker privacy properties than P2P protocols.
|
||||
|
|
Loading…
Reference in New Issue