libp2p / libp2p/go-libp2p

Allow specifying allowed source address(es)

Open
#1,064 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

effort/days exp/expert kind/enhancement
Dominant language
Go
Stars
6.9k
Forks
1.3k
Avg merge
13d 21h
Merged PRs (30d)
1

Description

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 https://github.com/libp2p/go-libp2p/issues/1063 for motivation.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the motivation in issue #1063 and tracing how listen-address configuration reaches each transport in go-libp2p. Define how a single allowed source address would be propagated and enforced across transports before considering multiple addresses; done requires transport-wide support with documented limitations.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
networking
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.