[Masque] QUIC non-encapsulation and CIDs

[Martin Thomson <[e-mail]>]

I've been looking more closely at draft-pauly-masque-quic-proxy.  I think that we can fix the protocol so that the use of this mechanism isn't a strict privacy reduction for the general case.  But I want to start with the connection ID design, which I find very confusing in its current form.

I wasn't able to tell exactly how the connection ID mappings work in the draft.  The structure of the document is a little confusing.  I really hoped that it would discuss how things work rather than just document state and capsule formats.

The idea something like this:

1. Client -> Server direction

The client tells the proxy about each connection ID used by the server.  The proxy tells the client which connection ID to use for that connection ID when sending packets to the proxy.

For this the client needs to tell the proxy:
a) the connection ID the server has provided
b) (maybe) the stateless reset token that the server will recognize if we want the proxy to be able to terminate the flow

I want to put a pin in the stateless reset design here, because there are a lot of requirements we might need to discuss regarding that.  More in a follow-up, I think.  Stateless resets that aren't visible to the proxy are not great, but we might want to avoid having the proxy be able to terminate the flow at the client.  There is a simple design for this too - maybe - but I need to think about that some more.

The proxy can then tell the client
a) the (virtual) connection ID that the proxy will map to the provided server connection ID

Here, the client is responsible for forwarding connection IDs from the server to the proxy so that it can be assigned a virtual connection ID.

Note that I think that virtual connection ID is not a great name, this is a mapped connection ID or a replacement connection ID.  Maybe an overlaid connection ID.


2. Server -> Client direction

The client will need to provide the server with connection IDs that the proxy will accept, so...

The client tells the proxy:
a) the connection ID it wants to use

The proxy responds with:
a) the connection ID that it wants the client to pass to the server

Basically, the client is responsible for putting connection IDs from the proxy into the connection on this side.


All of these are request-response exchanges, because the mapping will need to be clear.  Also, that same identifier can be used to remove connection IDs once the client or server retire them.  For that, I think that using the QUIC sequence number is fine as it might allow a bulk removal at the proxy if Retire Prior To is used.

Things I didn't solve: connection ID limits (the proxy will want some, how does the client convey this?), removal messages (easy), and connection ID length constraints and the effect of different lengths on MTU (this should be minor, but it will need to be mapped out).

With this design, the proxy could move all forwarding logic to a load balancer and never touch packets again.  The load balancer only needs to support QUIC-LB for that to work (with encrypted connection IDs, of course).  Of course, this will need to be revisited in my follow-up as the workload increases somewhat.

Cheers,
Martin