Strict checking for '/multistream/1.0.0' prefix in remote peer protocol negotiation is missing when rust-libp2p acts as dialer
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
Thanks for opening this! Whilst I don't think it is much of an issue in practice, I am happy to be stricter here :)
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."