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

fix(identify): Skip invalid multiaddr in listen_addrs #3246

Merged
merged 3 commits into from
Dec 17, 2022

Conversation

mxinden
Copy link
Member

@mxinden mxinden commented Dec 14, 2022

Description

With this commit libp2p-identify no longer discards the whole identify payload in case a listen addr of the remote node is invalid, but instead logs the failure, skips the invalid multiaddr and parses the remaining identify payload.

This is especially relevant when rolling out a new protocol to a live network. Say that most nodes of a network run on an implementation version v1. Say that the multiaddr implementation is not aware of the webrtc/ protocol. Say that a new version (v2) is rolled out to the network with support for the webrtc/ protocol, listening via webrtc/ by default. In such case all v1 nodes would discard all identify payloads of v2 nodes, given that the v2 identify payloads would contain the webrtc/ protocol in their listen_addr addresses.

See #3244 for details.

Notes

  • This pull request targets the v0.50 branch such that we can release a patch version of libp2p-identify.
  • I suggest we do the same for the v0.49 release family.
  • We can then backport the patch to master to be included in v0.51.

Links to any relevant issues

#3244

Open Questions

Change checklist

  • I have performed a self-review of my own code
  • I have made corresponding changes to the documentation
  • I have added tests that prove my fix is effective or that my feature works
  • A changelog entry has been made in the appropriate crates

With this commit `libp2p-identify` no longer discards the whole identify payload in case a listen
addr of the remote node is invalid, but instead logs the failure, skips the invalid multiaddr and
parses the remaining identify payload.

> This is especially relevant when rolling out a new protocol to a live network. Say that most nodes
> of a network run on an implementation version v1. Say that the `multiaddr` implementation is not
> aware of the `webrtc/` protocol. Say that a new version (v2) is rolled out to the network with
> support for the `webrtc/` protocol, listening via `webrtc/` by default. In such case all v1 nodes
> would discard all identify payloads of v2 nodes, given that the v2 identify payloads would contain
> the `webrtc/` protocol in their `listen_addr` addresses.

See libp2p#3244 for details.
@mxinden mxinden added the priority:important The changes needed are critical for libp2p, or are blocking another project label Dec 14, 2022
Ok(a) => a,
Err(e) => {
debug!("Unable to parse multiaddr: {e:?}");
Multiaddr::empty()
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not ideal but in my eyes not worse than the status quo. Downstream code has to handle a Multiaddr::empty due to the unwrap_or_default anyways.

One might first think that a remote could never return an observed address, i.e. an address that it observes the local node as, that the local node doesn't know. One would expect that the local node supports the multiaddr to all all its supported transport protocols. One exception is a relayed address though. The relay between A and B might use a protocol to B that A does not support nor be able to parse.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One might first think that a remote could never return an observed address, i.e. an address that it observes the local node as, that the local node doesn't know.

A remote can return all sorts of garbage :)

How big is the impact if we make this field an Option? That would be cleaner IMO.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed that Option would be the way to go here. That said, I think we should keep the patch release minimal, i.e. only do this on latest master.

Copy link
Contributor

@thomaseizinger thomaseizinger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM as a bug fix. Long-term we might want to make better use of the type-system.

Copy link
Member

@jxs jxs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@mxinden mxinden merged commit fd48971 into libp2p:v0.50 Dec 17, 2022
@mxinden
Copy link
Member Author

mxinden commented Dec 17, 2022

Tagged and published libp2p-identify v0.41.1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority:important The changes needed are critical for libp2p, or are blocking another project
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants