Support active connection migration from clients using zero-length connection IDs

[WesleyRosenblum]

Problem:

s2n-quic server endpoints do not currently support a peer client performing an active connection migration, if that client is receiving packets using a zero-length connection ID.

This is due to the implementation strictly enforcing the following requirement:

QUIC-9000§9.5:

an endpoint MUST NOT reuse a connection ID when sending to more than one destination address

The consensus among QUIC working group members is that this requirement should be interpreted as not applying to zero-length connections:

Konstantin Tsoy (mvfst):

My reading of the RFC (and subsequently what mvfst is doing) is that with client's zero length CID conn migration is allowed, and server can send the data without having to rotate the client's CID.

Benjamin Saunders(Quinn):

the length of CIDs you're receiving has no connection whatsoever to whether you can initiate migration

David Schinazi(Google):

The reason why the spec disallows reusing connection IDs is to avoid allowing two networks to correlate the two paths of a migrated connection. The zero-length CID doesn't have that issue. Chrome/Cronet uses zero-length CIDs in the server-to-client direction and does migration

Martin Thompson (Mozilla):

There are two things with zero-length connection IDs:

1. When you migrate to a new path, we assume that there are many other endpoints with a zero-length connection ID, so that your activity is hard to correlate as a result. So, while zero is just a different number, it is considered special, just as the text that Konstantin Tsoy cites says. Maybe think of this as a SQL NULL, where NULL != NULL always; similarly, two zero-length connection IDs are always different.
2. When a new path is used with a zero-length connection ID, it can be hard to re-identify the connection at the receiver end. That's the pull request 3563 subject. If you use zero-length connection IDs, then you need to use other cues to identify the connection. Having a unique destination port is a common trick that browsers use for that.

Solution:

Allow for connection migration to proceed when the peer is using a zero-length connection ID

• Does this change what s2n-quic sends over the wire? No
• Does this change any public APIs? --> No

Requirements / Acceptance Criteria:

Clients that use zero-length connection IDs must be able to probe on new paths and migrate paths

• RFC links: https://www.rfc-editor.org/rfc/rfc9000.html#name-privacy-implications-of-con
• Will the Usage Guide or other documentation need to be updated? Connection ID generator documentation should be updated to mention support for zero-length connection IDs
• Testing: Ideally a new integration test would be written to perform a connection migration while receiving on a zero-length connection ID. This may be difficult however, as s2n-quic does not support locally using zero-length connection IDs, and more critically, does not support initiating a connection migration. We can add support for zero-length connection IDs, but adding support for initiating connection migration is a larger ask.

Out of scope: