-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
webtransport / quic: allow listening on the same UDP port #1759
Comments
Do you think there is value in being consistent on this across implementations? In other words, do you think it makes sense to move this to libp2p/specs? While we don't have to be consistent across implementations for compatibility, it might be nice to have this as a recommendation for other implementations. What do you think? |
This is purely an implementation decision. A libp2p node advertises its addresses, so we don’t have to care about consistency here. The main purpose is to allow kubo to enable WebTransport by default at some point, without allocating a new port. I wouldn’t be opposed to adding a sentence to the spec that collocating QUIC and WebTransport is possible. |
In principle, it should be possible to run a QUIC and a WebTransport listener on the same IP / port.
In practice, this is how this would play out:
GetConfigForClient
callback of thetls.Config
is called.Privacy Implications
There’ve been proposals to use the HTTP/3 ALPN instead of “libp2p”, to avoid observers from identifying libp2p connections. This clashes with this proposal, since it uses ALPN to decide which certificate to use and how to proceed with an established connection.
One might argue that this proposal was suboptimal to begin with. Using the HTTP/3 ALPN, but then not speaking HTTP/3 certainly isn’t the cleanest approach.
On the other hand, simply using WebTransport should be an acceptable tradeoff for peers that wish to evade ALPN-based censorship. Of course, there’s also ECH on the horizon, which would encrypt the entire ClientHello (including the ALPN values), which would allow such clients to use pure QUIC.
Implementation Considerations
It’s possible to add listen addresses at any point. Any solution we adopt needs to be handle initialization of QUIC and WebTransport in arbitrary order, with arbitrary time in between. This will probably make it necessary to introduce a more abstract QUIC / WebTransport listener, that’s then used by both transports.
Progress:
The text was updated successfully, but these errors were encountered: