webtransport / quic: allow listening on the same UDP port

[marten-seemann]

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:

1. We accept a new incoming connection. The GetConfigForClient callback of the tls.Config is called.
2. In this callback, we have access to the ALPN that the client sent. If the ALPN is “libp2p”, we select a config that serves the libp2p-tls certificate and requires client auth. If the ALPN is HTTP/3, we use a config that serves the webtransport certificate, which doesn’t require client auth.
3. Once a QUIC connection is established, we either use it ourselves (for QUIC) or pass it to the WebTransport stack. This might require some refactoring in quic-go / webtransport-go.

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:

• http3: add http3.Server.ServeQUICConn to serve a single QUIC connection quic-go/quic-go#3579
• http3: expose ALPN values quic-go/quic-go#3580

[mxinden]

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?

[marten-seemann]

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.