[quicwg/base-drafts] Linkability with preferred_address usage (#3559)

[Martin Thomson <[e-mail]>]

One way in which a server might use preferred_address is to enable routing based on the server address alone.  Just as a client might benefit from a zero-length connection ID by selecting a unique address from which to initiate a connection (i.e., an ephemeral source port), this enables the server to pick an address that is unique to the connection.

Such a server can then establish a connection by routing based on the source tuple, then move to a preferred address that is unique to the connection.  This assumes that clients aren't using connection IDs to multiplex multiple connections to the same server, or that they only open one connection at a time, or that servers are willing to do trial decryption during handshakes (that last one being unlikely. because in the general case it is more than just trial decryption).

As a result, the server does not have to request that the client not migrate.  The server can use this unique address at its end to identify which connection packets belong to.

That's all great, but it creates linkability for the client.  When it migrates, the destination address is unique to that connection, for at least as long as that connection is live (which includes the idle timeout, which we have to assume is known to an attacker).

It also potentially creates address exhaustion problems at the server as the server has to keep address allocations for a fairly long time to allow for idle connections to time out.  Stateless resets are possible, but challenging, because the server has to rely on state in order to generate one.  Stateless resets can't be static unless a port is only ever used exactly once (which seems ludicrous).

I might conclude here that a zero-length connection ID for a server is just a bad idea, as the server address is stable across migrations and links flows on different paths.  There is some uncertainty about linkability when it comes to port reuse, but this does undermine guarantees that clients might assume they have.  

I see two choices:

1. Prohibit (active) migration when there is a zero-length connection ID at the server end.  This would be on the basis that there is a privacy leak that is not obvious.

2. Acknowledge that this happens and leave this to client discretion.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3559