Recommendations for Address Migration

[martinduke]

The best practice when clients migrate is not immediately obvious.

As the proxy's source IP does not change, changing the connection ID is not strictly necessary between proxy and target.

If a client migrates, clearly the virtual connection ID should change, to avoid linkability along the client/proxy path. But it's not totally clear to me if the "real" connection IDs should change.

If the connection IDs do not change, and an attacker is otherwise able to correlate client-proxy flows with proxy-target flows, then that makes things linkable.

However, changing the connection ID means short header packets start with a new connection ID, which is the signature of a migrating connection. This could actually allow an observer to correlate a client-proxy flow with a proxy-target flow.

I don't have a solution but I'm happy to help think through the tradeoffs here.

[huitema]

Maybe we should consider that as part of supporting multiple paths between the client and the target. I think that if the clients want some privacy with multiple paths, they will use a different proxy for each path, thus "the same proxy" should be considered a degenerate case. So maybe establish a separate CONNECT-UDP context for each of the paths, and treat the new path as a new connection: register the connection ID for the path, etc.

[huitema]

I have been looking at how to combine Masque and QUIC Multipath. I think the cleanest architecture is to map each QUIC path to a separate a CONNECT UDP context, defined by the IP Address and Port used by the proxy, and the IP Address and Path used by the target. But the client can only specify the target address in the CONNECT UDP request. So, today, the only way the client can create independent paths is to associate each QUIC path to a different proxy.

If the proxy is multi-homed, the client may be able to open several Masque connections to the different proxy addresses, knowing that the outgoing UDP packets will be source by that address.