A way to make undialable peers dialable. Please read and consider

This is a letter to the developers of IPFS. Please read this and give the proposed solution some consideration.

I am aware that starting with go-ipfs 0.5, peers which are located behind a NAT or firewall are pruned from the DHT. While this improves performance, it fails to solve the underlying problem: all of the nodes without the privilege of a public ip address become clients while those with a public IP address become servers. This creates a slightly less centralized equivalent to the client-server architecture of http and falls short of the decentralization and censorship resistance which IPFS strives for. It also prevents those less fortunate users behind NATs and firewalls from contributing resources to the network or self hosting their own IPFS sites. Surely there is a better way than demoting undialable peers to second class “clients”.

There is a better way. Hyperswarm (part of Dat/Hypercore) includes it’s own distributed hole-punching mechanism to circumvent NATs and firewalls. This basically makes undialable peers dialable, meaning they can participate in all of the ways that a peer with a public IP address can participate.

Implementing similar mechanism into the IPFS DHT would go a long way towards making IPFS more user friendly and realizing the dream of a decentralized censorship-resistant web.

For information on Hyperswarm, please visit https://hypercore-protocol.org/#hyperswarm

If I understood correctly, Hyperswarm uses some peers of the network as TURN servers to connect the 2 peers who couldn’t talk to each other before, for example because of a symmetric NAT. I’m not sure about the fact that in IPFS 0.5, peers behind a symmetric NAT are just releguated to the rank of clients, because from what I read, IPFS uses a similar feature to Hyperswarm, it’s called Circuit Relay: https://docs.libp2p.io/concepts/nat/#circuit-relay-turn

This is a letter to the developers of IPFS

While the developer force sometimes overlaps, don’t forget these capabilities are part of the libp2p stack.

They could not do that before from behind a NAT. The problem is that other nodes still expected them to do so and everything sucked. They were a huge net-negative contribution to the network.

Implementing similar mechanism into the IPFS DHT

There are NAT-hole-punching mechanisms embedded already and workarounds (upnp and relays). There is no TURN-server mechanism but I think there are improvements planned or discussed in this area (falls within the “relays” land (need to ask libp2p folks)). Last time I looked, relays can only relay traffic, rather than setting things up for a successful hole punching. One of the blockers has been reliance on TCP transports which make it more difficult to punch through. Hopefully with the adoption of QUIC we can make some strides there.

Note that the libp2p DHT is an independent block in the stack here, unrelated to how we can establish connections etc.

Doesn’t QUIC utilize proprietary encryption?

I’m not so sure that that’s a good idea considering the large push toward placing backdoors in all encryption algorithms.

Nope, nothing propietary that I know of.

It’s been awhile since I looked at the documentation…

I see from the IETF docs that they use the phrase “loosely based on … proprietary…”

https://tools.ietf.org/html/draft-ietf-taps-transport-security-09#section-4.3

QUIC is a new standards-track transport protocol that runs over UDP,
loosely based on Google's original proprietary gQUIC protocol
[I-D.ietf-quic-transport] (See Section 4.3.4 for more details).  The
QUIC transport layer itself provides support for data confidentiality
and integrity.  This requires keys to be derived with a separate
handshake protocol.  A mapping for QUIC of TLS 1.3
[I-D.ietf-quic-tls] has been specified to provide this handshake.

It’s not clear that there are no proprietary encumbrances within the protocol… or I can’t find any definitive statement that indicates there are no encumbrances. Are we quite sure that the IETF version of the AEAD nor the implementation have proprietary architecture and/or coding?

As far as the crypto is concerned, it’s just TLS. Nothing novel about QUIC has anything to with cryptography (the expedited handshaking I would say is security-, not cryptography-related, as all the same underlying info is being exchanged. There is just more pipelining, and in the 0-round-trip case, caching.)

Documentation:

https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#name-cryptographic-and-transport

The keys are derived from TLS keys, but the AEAD uses its own crypto. I seem to remember that crypto was a proprietary process. My guess is the IETF implementation is not… but…

My concerns with QUIC are:

  1. Proprietary encumbrances which result in reliance on “black-box” coding from a single vendor.
  2. Denial of service based on changed parameters within that “black-box”.
  3. Weakened security due to proprietary key generation functions.

I looked at what you linked, and briefly https://quicwg.org/base-drafts/draft-ietf-quic-tls.html and https://quicwg.org/base-drafts/draft-ietf-quic-tls.html, and am not sure what you are talking about?

If neither of us can find the bad thing you “seem to remember” I wouldn’t worry about it?