Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

multistream: Dialer accepts multiple /multistream/1.0.0 headers #59

Closed
lexnv opened this issue Mar 18, 2024 · 0 comments · Fixed by #61
Closed

multistream: Dialer accepts multiple /multistream/1.0.0 headers #59

lexnv opened this issue Mar 18, 2024 · 0 comments · Fixed by #61
Assignees
Labels
bug Something isn't working easy Requires little knowledge of the codebase

Comments

@lexnv
Copy link
Collaborator

lexnv commented Mar 18, 2024

The dialer of the multistream protocol can accept multiple times the multistream V1 header:

Message::Header(v) if v == HeaderLine::from(*this.version) => {
*this.state = State::AwaitProtocol { io, protocol };
}

This may lead to peers keeping connections alive due to state mismatch.

My understanding of the libp2p spec is that the multistream header should be send once, as the first message. Then, peers should negotiate the protocol names they want to serve.

The listener code is correctly awaiting the header once:

*this.state = State::RecvHeader { io };

The issue is also present in the rust-libp2p repo, which is where I suspect our code took inspiration from.

Let's return ProtocolError::InvalidMessage if the header is sent multiple times.

cc @paritytech/networking

@dmitry-markin dmitry-markin moved this to Backlog 🗒 in Networking Mar 18, 2024
@dmitry-markin dmitry-markin added bug Something isn't working easy Requires little knowledge of the codebase labels Mar 18, 2024
@lexnv lexnv self-assigned this Mar 18, 2024
@lexnv lexnv closed this as completed in #61 Apr 24, 2024
lexnv added a commit that referenced this issue Apr 24, 2024
This PR ensures that the `/multistream/1.0.0` header can only be
received once during a protocol negotiation.
This is fixed for both the V1 and V1Lazy variations.


While at it, have added a few tests to check:
- protocol negotiation
- protocol negotiation failure due to unsupported protocols
- lazy protocol negotiation awaits protocol message before closing (to
be fixed by: #60)
- low level protocol listener that writes the expected messages
- low level protocol listener that submits multiple headers, both for V1
and V1 lazy

Closes: #59

cc @paritytech/networking

---------

Signed-off-by: Alexandru Vasile <[email protected]>
@github-project-automation github-project-automation bot moved this from Backlog 🗒 to Blocked ⛔️ in Networking Apr 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working easy Requires little knowledge of the codebase
Projects
Status: Blocked ⛔️
Development

Successfully merging a pull request may close this issue.

2 participants