libp2p / specs

Technical specifications for the libp2p networking stack
https://libp2p.io
1.56k stars 273 forks source link

pubsub/: Use timestamp to filter out repeated messages #346

Closed TheDiscordian closed 3 years ago

TheDiscordian commented 3 years ago

I'm proposing a timestamp field be added to the Message object, and used to expire messages after a TTL. Similar to how messages are forgotten in gossipsub after seen_ttl. I discovered this while working on a new chat project: http://portal.thedisco.zone/testing/chat_experiments/

I noticed repeated messages, which led me to file https://github.com/ipfs/js-ipfs/issues/3724. What happens is nodes are innocently rebroadcasting messages after losing connection, but this makes it appear as if new messages are being received, and they are processed as such. This to me though seems like it might not always be in an innocent scenario, couldn't a malicious node harvest messages I post in a public room on Disco Chat, and later replay them, impersonating me? It's one example, but I see how someone building an application could miss this, and the solution seems to me, to embed a timestamp into the message. I think it makes more sense for the protocol to do that, as it seems to be an inherit problem that'd need solving if someone is to rely on from.

Specifically I'd be proposing a structure like this:

message Message {
    optional string from = 1;
    optional bytes data = 2;
    optional bytes seqno = 3;
    repeated string topicIDs = 4;
    optional bytes signature = 5;
    optional bytes key = 6;
    optional uint64 timestamp = 7;
}

As a start. Then I see at least 2 options:

  1. The application could check the timestamp themselves, compare it to a TTL (easy to implement, but IMO not ideal)
  2. Check the timestamp against a TTL much like seen_ttl, but instead maybe stale_ttl, and after the TTL, the message is considered stale, and rejected. Much like the signature verification options, this could come with options to be disabled entirely if wanted (omitting timestamp from transmission).

I couldn't find any write-ups about this, and to me, it seems without some sort of expiry, it's difficult to just rely on the authenticity of a message (has it been reused?). What do you think?

TheDiscordian commented 3 years ago

CC @fusetim, who helped me navigate the specs :).

mxinden commented 3 years ago

@vyzo: Would you mind taking a look?

vyzo commented 3 years ago

I think this should be left up to the application validator.

On Fri, Jul 2, 2021, 17:44 Max Inden @.***> wrote:

@vyzo https://github.com/vyzo: Would you mind taking a look?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/libp2p/specs/issues/346#issuecomment-873051764, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAI4ST5VIY4IEUZMQLP6I3TVXGEDANCNFSM47VUQGLQ .

mxinden commented 3 years ago

With @vyzo's reply above and given that the issue has stalled I will close here.

@TheDiscordian please comment in case you think we should continue the discussion.