rust-libp2p icon indicating copy to clipboard operation
rust-libp2p copied to clipboard

Strict checking for '/multistream/1.0.0' prefix in remote peer protocol negotiation is missing when rust-libp2p acts as dialer

Open frystal opened this issue 2 years ago • 2 comments

Summary

When rust-libp2p acts as the connection initiator (dialer), it appears that it does not strictly check whether the remote peer's (responder) protocol negotiation message always starts with "/multistream/1.0.0". From the implementation here, the code does not add a tag to show that "/multistream/1.0.0" has been sent from the responder; instead, it just continues with "AwaitProtocol". I also tested this and found that it does not check for "/multistream/1.0.0" during any of the protocol negotiation stages.

Expected behavior

When rust-libp2p acts as the connection initiator (dialer), it should strictly check whether the remote peer's (responder) protocol negotiation message always starts with "/multistream/1.0.0".

Actual behavior

When rust-libp2p acts as the connection initiator (dialer), it does not strictly check whether the remote peer's (responder) protocol negotiation message always starts with "/multistream/1.0.0".

Relevant log output

No response

Possible Solution

No response

Version

No response

Would you like to work on fixing this bug ?

Yes

frystal avatar Nov 02 '23 10:11 frystal

Thanks for opening this! Whilst I don't think it is much of an issue in practice, I am happy to be stricter here :)

thomaseizinger avatar Nov 02 '23 22:11 thomaseizinger

What would be the benefit of being more strict?

When in doubt, I suggest following the Robustness Principle:

"Be conservative in what you do, be liberal in what you accept from others."

mxinden avatar Nov 12 '23 16:11 mxinden