Re: [quicwg/base-drafts] Allow connections to share a port by adding restrictions on zero-length connection IDs (#2851)

[Martin Thomson <[e-mail]>]

martinthomson approved this pull request.

I like this.  It makes sense.  I've suggested a rewording of the text you proposed, but I think that this the right insight.  Namely, you can only use a zero-length connection ID if other information **that is under your control** is sufficient to identify a connection.

My only reservation is over the potential for an endpoint to be willing to use trial decryption here.  In theory, you could demux using trial decryption.  It seems crazy, but we've already got cases for ESNI where that turns out to be a useful concept.

> @@ -924,11 +924,14 @@ selected by the client, both to ensure correct routing toward the client and to
 allow the client to validate that the packet is in response to an Initial
 packet.
 
-A zero-length connection ID MAY be used when the connection ID is not needed for
-routing and the address/port tuple of packets is sufficient to identify a
-connection. An endpoint whose peer has selected a zero-length connection ID MUST
-continue to use a zero-length connection ID for the lifetime of the connection
-and MUST NOT send packets from any other local address.
+A zero-length connection ID MAY be used when the connection ID is not needed
+for routing and the destination address and port of incoming packets is
+sufficient to identify a connection (e.g., when there is a single connection
+on a given local port). Note that it is not possible to use the source address
+and port of incoming packets to demultiplex them across connections because a
+peer might multiplex multiple connections on a single address and port and rely
+on its connection IDs for demultiplexing, and the peer's connection IDs are not
+transmitted in the short header packets they send.

Suggestion: A zero-length connection ID can be used when a connection ID is not needed to correctly route to the correct endpoint.  An endpoint MUST NOT use a zero-length connection ID unless it can use only its IP address and port to identify a connection.  The IP address and port used by a peer cannot be used for routing as these values can change or be used for additional connections.

>  
-If the Destination Connection ID is zero length and the packet matches the
-address/port tuple of a connection where the host did not require connection
-IDs, QUIC processes the packet as part of that connection.  Endpoints SHOULD
-either reject connection attempts that use the same addresses as existing
-connections, or use a non-zero-length Destination Connection ID so that packets
-can be correctly attributed to connections.
+If the Destination Connection ID is zero-length and the packet matches the
+local address and port of a connection where the host used zero-length
+connection IDs, QUIC processes the packet as part of that connection.
+Endpoints that share a local address and port across multiple connections MUST

I think that we can drop this final sentence here.  The text above (L933-ish) will do.

> @@ -1793,9 +1796,7 @@ An endpoint also MUST NOT initiate connection migration if the peer sent the
 `disable_migration` transport parameter during the handshake.  An endpoint which
 has sent this transport parameter, but detects that a peer has nonetheless
 migrated to a different network MAY treat this as a connection error of type
-INVALID_MIGRATION.  Similarly, an endpoint MUST NOT initiate migration if its
-peer supplies a zero-length connection ID as packets without a Destination
-Connection ID cannot be attributed to a connection based on address tuple.

Nice.

-- 
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/pull/2851#pullrequestreview-259270833