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

P2P over NAT Improvement #4645

Closed
7 tasks
yangby-cryptape opened this issue Sep 12, 2024 · 2 comments
Closed
7 tasks

P2P over NAT Improvement #4645

yangby-cryptape opened this issue Sep 12, 2024 · 2 comments
Labels
stale To be closed due to a lack of activity t:enhancement Type: Feature, refactoring.

Comments

@yangby-cryptape
Copy link
Collaborator

yangby-cryptape commented Sep 12, 2024

P2P over NAT Improvement

Note

I'm not an expert on this field, maybe I have lots of misunderstanding.
Any correction is welcome!

Motivation

Most computers in the world are behind some kind of NAT. The main restriction
or disadvantage for a Device under a NAT is that it cannot accept outbound
connections.

The establishment of a P2P network requires direct connection between any two
nodes.
CKB, as a network service that based on P2P network, also has to face such
generic peer-to-peer problems.

Proposals

I have 2 proposals to improve P2P over NAT.

Proposal 1. Enhance Built-in P2P Discovery Function

After reading several articles about file sharing technologies12, I
summarized a series of common steps that establish a P2P connection behind
NATs:

  • First, tries UPnP IGD Protocol, NAT Port Mapping Protocol and
    Port Control Protocol to do automatic port forwarding.

    🚧 I have to learn more on them.

  • If all above protocols are not available, tries to do Hole Punching.

    Hole Punching works on the assumption, that a NAT/firewall is configured to
    allow outbound connections, but not inbound.
    So, making outbound connection attempts from both devices to each other,
    could cause the NAT/firewall on both sides to detect an (approved) outgoing
    connection, which will then unblock the flow of data, enabling an actual
    connection handshake.

    As some articles mentioned, this technique works fine within a CGNAT3.

    UDP hole punching is preferred.

Proposal 2. Support External P2P Services

  • In BIP-0155, there are 4 external P2P services are mentioned: Tor, I2P,
    Cjdns and Yggdrasil.

    All of those P2P services are support NAT traversal.
    Build our P2P connections over those services, NAT traversal would be
    supported.

  • There is another challenge: for clients in network-restrictive countries or
    regions (e.g. GFW), launch these P2P service over a VPN is required.

    So, proxy support should be built-in in Tentacle, and when to use a proxy
    should be configured: just when launch Tentacle, or whole time for all
    connections over those external P2P services.

Tasks

I split this improvement into several tasks:

  • Enhance Built-in P2P Discovery Function

    • Automatic Port Forwarding
      🚧 I have to learn more on them.

    • Hole Punching

      A new protocol should be added into CKB/Network:

      • Let denote A, B, S are 3 CKB nodes.
      • A sends S a request, that A want to build a connection with B.
      • S sends A’s address to B and B’s address to A.
      • A and B sends a message to each other.
      • A and B sends a message to each other, again.
      • Connection between A and B established.

      Here is only the simplest description, some security issues should be
      considered, for example, A (or B) shouldn't believe peers which given by S
      simply.
      The discussion of security part will be in the sub-issue.

  • Support External P2P Services

References

Documents:

Libraries:

Some P2P networks and clients which inspired me:

Thanks

  • @driftluo, who answered punch of my questions about Tentacle.

Footnotes

  1. Why device behind NAT is sometimes connected without relays in Syncthing?

  2. Clever tricks to solve some generic P2P problems in Crust (Safe Network)

  3. Carrier-Grade NAT

@yangby-cryptape yangby-cryptape added the t:enhancement Type: Feature, refactoring. label Sep 12, 2024
Copy link

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

@github-actions github-actions bot added the stale To be closed due to a lack of activity label Oct 14, 2024
Copy link

This issue was closed because it has been stalled for 5 days with no activity.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Oct 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale To be closed due to a lack of activity t:enhancement Type: Feature, refactoring.
Projects
None yet
Development

No branches or pull requests

1 participant