libp2p / specs

Technical specifications for the libp2p networking stack
https://libp2p.io
1.56k stars 273 forks source link

connections/hole-punching: Update with WebRTC and WebTransport #422

Closed mxinden closed 2 years ago

mxinden commented 2 years ago

First off this pull requests changes the text based format to a table based format. In addition it references the recent WebTransport effort. Lastly it updates outdated information in regards to WebRTC, based on the recent discussions in https://github.com/libp2p/specs/pull/412.

mxinden commented 2 years ago

In a nutshell, this pull request introduces the table below:

↓ establishing connection to → public non-browser private non-browser private browser
public non-browser TCP or QUIC Destination has reservation with [circuit-relay-v2]. Source connects to destination via relay. Source triggers connection (TCP or QUIC) reversal with destination via [DCUTR]. Destination has reservation with [circuit-relay-v2]. Source connects to destination via relay. Source triggers connection (WebSocket (trusted TLS cert),[WebRTC] or [WebTransport]) reversal with destination via [DCUTR].
private non-browser TCP or QUIC Source and destination use [identify] and [AutoNAT]. Destination has reservation with [circuit-relay-v2]. Source connects to destination via relay. Source and destination coordinate hole punch (TCP or QUIC) via [DCUTR]. Source uses [identify] and [AutoNAT]. Destination has reservation with [circuit-relay-v2]. Source connects to destination via relay. Source and destination coordinate hole punch ([WebRTC]) via [DCUTR].
private browser If source trusts destination's TLS certificate WebSocket else [WebRTC] or [WebTransport] [WebRTC] [WebRTC]
mxinden commented 2 years ago

You can holepunch from browser to non-private nodes (in principe). Should that be reflected in the table?

I am not sure I follow. Why would a browser hole punch to a public ("non-private") node?

marten-seemann commented 2 years ago

Sorry, I meant:

You can holepunch from browser to private non-browser nodes (in principe). Should that be reflected in the table?

mxinden commented 2 years ago

You can holepunch from browser to private non-browser nodes (in principe). Should that be reflected in the table?

Sorry, confused once more.

The cell "private browser"/"private non-browser" is currently only linking to the WebRTC specification draft, given that we have not yet figured out how to support this use-case, i.e. how to hole punch between a browser and a private non-browser using WebRTC.

What are you referring to with "holepunch" @marten-seemann? With a different protocol stack than WebRTC?

marten-seemann commented 2 years ago

The cell "private browser"/"private non-browser" is currently only linking to the WebRTC specification draft, given that we have not yet figured out how to support this use-case, i.e. how to hole punch between a browser and a private non-browser using WebRTC.

In my understanding this table is aspirational, isn't it? Hole punching a WebSocket / WebTransport connection from a browser should be possible via DCUtR, right? Browser and server agree on the timing, and then the browser establishes WebSocket / WebTransport connection, while the server does a TCP Sim Open (we'd need to write this up in the WebSocket transport) or sends random UDP garbage to open the hole on its side of the firewall.

mxinden commented 2 years ago

Hole punching a WebSocket / WebTransport connection from a browser should be possible via DCUtR, right?

I would expect the browser to use a new TCP port for each outgoing WebSocket connection, and thus there being no way for the private non-browser node to predict the port to connect to and thus not be able to punch the hole into its firewall. Is that not the case @marten-seemann?

What is the browser behavior on WebTransport? Do multiple outgoing connections use the same UDP port? I am guessing, even if not, some firewalls in front of private non-browser nodes will still let UDP packets through even though no UDP packet went out to that particular remote port before.

mxinden commented 2 years ago

Friendly ping @marten-seemann.

marten-seemann commented 2 years ago

What is the browser behavior on WebTransport? Do multiple outgoing connections use the same UDP port?

We should investigate. This would be not too hard to implement, as you can demultiplex QUIC connections by their QUIC Connection ID, but I'm not sure what browsers do.

mxinden commented 2 years ago

Approving, with the understanding that we can update this when we find out more about browser port usage for WebSocket and WebTransport, which might unlock options to do holepunching in the browser -> private non-browser case.

:+1: Very much. This is a living document not cast in stone.