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

Allow specifying allowed source address(es) #1064

Open
Stebalien opened this issue Mar 5, 2021 · 0 comments
Open

Allow specifying allowed source address(es) #1064

Stebalien opened this issue Mar 5, 2021 · 0 comments
Labels
effort/days Estimated to take multiple days, but less than a week exp/expert Having worked on the specific codebase is important kind/enhancement A net-new feature or improvement to an existing feature

Comments

@Stebalien
Copy link
Member

Currently, it's possible to specify listen addresses, but not source addresses for dials. It would be nice to be able to actually specify source addresses.

Specifically:

  1. An initial implementation would allow specifying a single allowed source address. This option would need to be piped through to all transports and transports would need to be updated to obey it. Unfortunately, this would likely prevent, e.g., loopback dials. This trivial from a purely technical perspective, but we don't currently have a nice way to reliably pipe this information through from go-libp2p to the individual transports.
  2. After the initial implementation, support for multiple allowed source addresses. Unfortunately, this is significantly more complicated to implement.

At the moment, the best solution here is to sandbox your application (i.e., use a network namespace) so libp2p simply doesn't have access to interfaces it's not allowed to use. Furthermore, restricting the application to a single interface/source address isn't something go-libp2p can actually enforce (i.e., some transports may ignore the setting and/or have bugs). Even if/when this feature is implemented, users should continue to sandbox libp2p if they don't want it to use/see some set of interfaces.

See #1063 for motivation.

@Stebalien Stebalien removed the feature label Mar 27, 2021
@marten-seemann marten-seemann added kind/enhancement A net-new feature or improvement to an existing feature exp/expert Having worked on the specific codebase is important effort/days Estimated to take multiple days, but less than a week labels Jun 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort/days Estimated to take multiple days, but less than a week exp/expert Having worked on the specific codebase is important kind/enhancement A net-new feature or improvement to an existing feature
Projects
None yet
Development

No branches or pull requests

2 participants