Does the validation have access to IP addresses of peers, and blocking peers by IP addresses?

[estebanabaroa]

This is something our app requires.

[MichaelMure]

/read and /readall would give the peerID but not the IP. Could you explain why you care about this? Is that something that the kubo API expose?

[estebanabaroa]

/read and /readall would give the peerID but not the IP. Could you explain why you care about this? Is that something that the kubo API expose?

It is not something that the kubo RPC exposes, but it is something that our app needs, and for this we plan on writing a custom pubsub default validator.

The reason that I believe we need it (could be wrong), is that our protocol works like this:

1. author publishes a CHALLENGEREQUEST
2. community owner publishes a CHALLENGE
3. author publishes a CHALLENGEANSWER
4. community owner publishes a CHALLENGEVERIFICATION

The community owner is confirmed because the pubsub topic is a hash of his public key.

We need to block IP addresses to block a potential spam attack where an attacker would spam infinite CHALLENGEREQUEST, which are all valid messages until the community owner publishes a CHALLENGEVERIFICATION to mark them as invalid. It seems to me like peers must keep a history of the ratio of succeeded CHALLENGEREQUEST and block IP addresses of peers who relayed too many failed challenges. Otherwise the topic can be DDOSed.

[MichaelMure]

So if I read the subtext correctly, banning PeerIDs is not sufficient as it's easy to generate more keys, banning IPs is a stronger response?

The way I see it, the spec leave space for the service provider to implement filtering/banning however makes sense. That can include the service keeping a log of origin IPs from where filtered message came from, and then take the decision to filter the IP entirely (or even an IP range). That could fit in the "generic validation", without application specific logic.

It's debatable of course, but if that's sufficient we better keep the spec simple and not expose the source IP.

[pinnaculum]

The Kubo pubsub RPC API exposes the PeerID of the message sender. I think preventing topic DDOs is important and should be a priority even if the first version doesn't implement it. What would be nice is at least to give developers an API to add filters for a topic, a bit similar to what ipfs swarm filters add/rm provides, but ideally using PeerIDs instead of IPs.

[MichaelMure]

There is /filter-peerid that does that. The idea it to form a feedback loop between the client+server, where the client (that has the app logic and data) can tell the server about a bad peerID. The server can then implement filtering/banning.

What exactly that filtering is is unspecified (on purpose), but should at the minimum include (because that's the obvious, no edge case behavior):

• filter all future messages from that peerID
• prune any message from that peerID in the reading queue

After that, the server/service is free to go as far as it makes sense:

• also filter by IP, or IP range
• leverage understanding over different topics to identify earlier bad actors
• use denylist / allowlist
• AI

[pinnaculum]

Sounds good to me. Thank you for your work on this spec.

off-topic: Would be nice to have this implemented as a kubo plugin, don't know if that's possible.