vacp2p/rfc
1
0
Fork 0
mirror of https://github.com/vacp2p/rfc.git synced 2025-02-22 11:48:25 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update README.md

Browse Source
This commit is contained in:
Jimmy Debe 2024-02-08 01:10:58 -05:00 committed by GitHub
parent d2dcf66af8
commit 59048bcec7
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 39 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

74
content/docs/rfcs/10/README.md
View File

@ -245,7 +245,7 @@ See the sequence diagram below for an overview of how different protocols intera
![Overview of how protocols interact in Waku v2.](../../../../static/rfcs/10/overview.png)
0. We have six nodes, A-F.
We have six nodes, A-F.
The protocols initially mounted are indicated as such.
The PubSub topics `pubTopic1` and `pubsubTopic2` is used for routing and
indicates that it is subscribed to messages on that topic for relay,
@ -253,31 +253,31 @@ see [11/WAKU2-RELAY](/spec/11) for details.
Ditto for [13/WAKU2-STORE](/spec/13),
where it indicates that these messages are persisted on that node.
2. Node A creates a `WakuMessage` with a ContentTopic `contentTopic1`.
1. Node A creates a `WakuMessage` `msg1` with a ContentTopic `contentTopic1`.
See [14/WAKU2-MESSAGE](/spec/14) for more details.
If `WakuMessage` `version` is set to 1,
we use the [6/WAKU1](/spec/6) compatible `data` field with encryption.
See [7/WAKU-DATA](/spec/7) for more details.
4. Node F requests to get messages filtered by PubSub topic `pubTopic1` and
2. Node F requests to get messages filtered by PubSub topic `pubTopic1` and
ContentTopic `contentTopic1`.
Node D subscribes F to this filter and, in the future,
will forward messages that match this filter.
See [12/WAKU2-FILTER](/spec/12) for more details.
5. Node A publishes `msg1` on `pubTopic1` and
3. Node A publishes `msg1` on `pubTopic1` and
subscribes to that pubsub topic so relay node B can receive it.
It then gets relayed further from B to D, but
not C since it doesn't subscribe to that pubsub topic.
See [11/WAKU2-RELAY](/spec/11).
7. Node D saves `msg1` for possible later retrieval by other nodes.
4. Node D saves `msg1` for possible later retrieval by other nodes.
See [13/WAKU2-STORE](/spec/13).
8. Node D also pushes `msg1` to F, as it has previously subscribed F to this filter.
5. Node D also pushes `msg1` to F, as it has previously subscribed F to this filter.
See [12/WAKU2-FILTER](/spec/12).
9. At a later time, Node E comes online.
6. At a later time, Node E comes online.
It then requests messages matching `pubtopic1` and `contentTopic1` from Node D.
Node D responds with messages meeting this (and possibly other) criteria.
See [13/WAKU2-STORE](/spec/13).
@ -320,18 +320,18 @@ The following are **not** considered as part of the adversarial model:
##### Pseudonymity
Waku v2 by default guarantees pseudonymity for all of the protocol layers since parties do not have to disclose their true identity and
Waku v2, by default, guarantees pseudonymity for all of the protocol layers since parties do not have to disclose their true identity and
instead they utilize libp2p `PeerID` as their identifiers.
While pseudonymity is an appealing security feature,
it does not guarantee full anonymity since the actions taken under the same pseudonym
i.e., `PeerID` can be linked together and potentially result in the re-identification of the true actor.
it does not guarantee full anonymity since the actions taken under the same pseudonym i.e.,
`PeerID` can be linked together and potentially result in the re-identification of the true actor.
##### Anonymity / Unlinkability
At a high level, anonymity is the inability of an adversary in linking an actor to its data/performed action
(the actor and action are context-dependent).
To be precise about linkability, we use the term,
Personally Identifiable Information (PII) to refer to any piece of data that could potentially be used to uniquely identify a party.
Personally Identifiable Information (PII) refers to any piece of data that could potentially be used to uniquely identify a party.
For example, the signature verification key, and
the hash of one's static IP address are unique for each user and hence count as PII.
Notice that users' actions can be traced through their PIIs
@ -348,7 +348,7 @@ due to the data fields of pubsub messages that count as PII for the publisher mu
**Subscriber-Topic Unlinkability**:
This feature stands for the unlinkability of the subscriber to its subscribed topics in the [11/WAKU2-RELAY](/spec/11) protocol.
The [Subscriber-Topic Unlinkability](/spec/11/#security-analysis) is achieved through the utilization of a single PubSub topic.
As such, subscribers are not re-identifiable from their subscribed topic IDs as the entire network is linked to the same topic ID.
As such, subscribers are not re-identifiable from their subscribed topic IDs(pubsub topic) as the entire network is linked to the same topic ID(pubsub topic).
This level of unlinkability / anonymity is known as [k-anonymity](https://www.privitar.com/blog/k-anonymity-an-introduction/),
where k is proportional to the system size (number of subscribers).
Note that there is no hard limit on the number of the pubsub topics, however,
@ -356,28 +356,30 @@ the use of one pubsub topic is RECOMMENDED for the sake of anonymity.
##### Spam protection
This property indicates that no adversary can flood the system (i.e., publishing a large number of messages in a short amount of time), either accidentally or deliberately, with any kind of message i.e. even if the message content is valid or useful.
Spam protection is partly provided in `11/WAKU2-RELAY` through the [scoring mechanism](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#spam-protection-measures) provided for by GossipSub v1.1.
At a high level, peers utilize a scoring function to locally score the behavior of their connections and remove peers with a low score.
This property indicates that no adversary can flood the system
(i.e., publishing a large number of messages in a short amount of time),
either accidentally or deliberately, with any kind of message i.e. even if the message content is valid or useful.
Spam protection is partly provided in `11/WAKU2-RELAY` through the
[scoring mechanism](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md#spam-protection-measures) provided for by GossipSub v1.1.
At a high level, peers utilize a scoring function to locally score the behavior of their connections and
remove peers with a low score.
##### Data confidentiality, Integrity, and Authenticity
Confidentiality can be addressed through data encryption whereas integrity and authenticity are achievable through digital signatures.
Confidentiality can be addressed through data encryption whereas integrity and
authenticity are achievable through digital signatures.
These features are provided for in [14/WAKU2-MESSAGE (version 1)](/spec/14#version-1)` through payload encryption as well as encrypted signatures.
## Security Considerations
**Lack of anonymity/unlinkability in the protocols involving direct connections including `13/WAKU2-STORE` and `12/WAKU2-FILTER` protocols**:
The anonymity/unlinkability is not guaranteed in the protocols like `13/WAKU2-STORE` and `12/WAKU2-FILTER` where peers need to have direct connections to benefit from the designated service.
The anonymity/unlinkability is not guaranteed in the protocols like `13/WAKU2-STORE` and
`12/WAKU2-FILTER` where peers need to have direct connections to benefit from the designated service.
This is because during the direct connections peers utilize `PeerID` to identify each other,
therefore the service obtained in the protocol is linkable to the beneficiary's `PeerID` (which counts as PII).
For `13/WAKU2-STORE`, the queried node would be able to link the querying node's `PeerID` to its queried topics.
For `13/WAKU2-STORE`, the queried node would be able to link the querying node's `PeerID` to its queried topics(`contectTopic`).
Likewise, in the `12/WAKU2-FILTER`, a full node can link the light node's `PeerID`s to its content filter.
<!-- TODO: to inspect the nim-libp2p codebase and figure out the exact use of PeerIDs in direct communication, it might be the case that the requester does not have to disclose its PeerID-->
<!--TODO: might be good to add a figure visualizing the Waku protocol stack and the security features of each layer-->
### Appendix C: Implementation Notes
#### Implementation Matrix
@ -388,8 +390,8 @@ There are multiple implementations of Waku v2 and its protocols:
- [go-waku (Go)](https://github.com/status-im/go-waku/)
- [js-waku (NodeJS and Browser)](https://github.com/status-im/js-waku/)
Below you can find an overview of the specs that they implement as they relate to Waku v2.
This includes Waku v1 specs, as they are used for bridging between the two networks.
In the following overview, you can find the implemented specifcations utilizing Waku v2.
This includes Waku v1 specifications, as they are used for bridging between the two networks.
| Spec | nim-waku (Nim) | go-waku (Go) | js-waku (Node JS) | js-waku (Browser JS) |
| ---- | -------------- | ------------ | ----------------- | -------------------- |
@ -412,12 +414,11 @@ This includes Waku v1 specs, as they are used for bridging between the two netwo
*js-waku implements [13/WAKU2-STORE](/spec/13) as a querying node only.
**js-waku only implements [19/WAKU2-LIGHTPUSH](/spec/19) requests.
### Recommendations for clients
To implement a minimal Waku v2 client, we recommend implementing the following subset in the following order:
To implement a minimal Waku v2 client, the following subset of protocols is RECOMMENDED to implement in the following order:
- [10/WAKU2](/spec/10) - this spec
- [10/WAKU2](/spec/10) - this specification
- [11/WAKU2-RELAY](/spec/11) - for basic operation
- [14/WAKU2-MESSAGE](/spec/14) - version 0 (unencrypted)
- [13/WAKU2-STORE](/spec/13) - for historical messaging (query mode only)
@ -430,28 +431,31 @@ To get compatibility with Waku v1:
For an interoperable keep-alive mechanism:
- [libp2p ping protocol](https://docs.libp2p.io/concepts/protocols/#ping),
with periodic pings to connected peers
with periodic pings to connected peers.
### Appendix D: Future work
The following features are currently experimental and under research and initial implementation:
The following features are currently experimental, under research and initial implementations:
**Economic Spam resistance**:
**Economic Spam Resistance**:
We aim to enable an incentivized spam protection technique to enhance `11/WAKU2-RELAY` by using rate limiting nullifiers.
More details on this can be found in [17/WAKU2-RLN-RELAY](/spec/17).
In this advanced method, peers are limited to a certain rate of messaging per epoch and an immediate financial penalty is enforced for spammers who break this rate.
In this advanced method, peers are limited to a certain rate of messaging per epoch and
an immediate financial penalty is enforced for spammers who break this rate.
**Prevention of Denial of Service (DoS) and Node Incentivization**:
Denial of service signifies the case where an adversarial node exhausts another node's service capacity (e.g., by making a large number of requests) and makes it unavailable to the rest of the system.
Denial of service signifies the case where an adversarial node exhausts another node's service capacity
(e.g., by making a large number of requests) and makes it unavailable to the rest of the system.
DoS attack is to be mitigated through the accounting model as described in [18/WAKU2-SWAP](/spec/18).
In a nutshell, peers have to pay for the service they obtain from each other.
In addition to incentivizing the service provider, accounting also makes DoS attacks costly for malicious peers.
The accounting model can be used in `13/WAKU2-STORE` and `12/WAKU2-FILTER` to protect against DoS attacks.
In addition to incentivizing the service provider,
accounting also makes DoS attacks costly for malicious peers.
The accounting model can be used in [`13/WAKU2-STORE`](/spec/13) and
[`12/WAKU2-FILTER`](/spec/12) to protect against DoS attacks.
Additionally, this gives node operators who provide a useful service to the network an incentive to perform that service.
See [18/WAKU2-SWAP](/spec/18) for more details on this piece of work.
## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).