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

From: Martin Thomson <[email-masked]>
Date: Mon, 08 Jul 2019 22:11:58 -0700

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

---

From: David Schinazi <[email-masked]>
Date: Tue, 09 Jul 2019 13:41:46 -0700

@DavidSchinazi pushed 1 commit.

93185582222626bad7f217199d35de05f81ced11  Comments from MT

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2851/files/fd79b81d1b2040440e09e2c49c7f8b8842224c60..93185582222626bad7f217199d35de05f81ced11

---

From: David Schinazi <[email-masked]>
Date: Tue, 09 Jul 2019 13:42:16 -0700

DavidSchinazi commented on this pull request.

Fixed by applying MT's suggestion

-- 
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#discussion_r301784570

---

From: David Schinazi <[email-masked]>
Date: Tue, 09 Jul 2019 13:42:38 -0700

Applied the suggestion with minor changes.

-- 
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#discussion_r301784731

---

From: David Schinazi <[email-masked]>
Date: Tue, 09 Jul 2019 13:42:53 -0700

Agreed, done.

-- 
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#discussion_r301784837

---

From: David Schinazi <[email-masked]>
Date: Tue, 09 Jul 2019 13:45:56 -0700

Thanks @martinthomson . I think the current text doesn't explicitly ban trial decryption: technically that endpoint is able to identify the connection using only its IP and port so it's good to go. The important bit is that it doesn't require the peer to alter its behavior.

-- 
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#issuecomment-509800630

---

From: Martin Thomson <[email-masked]>
Date: Wed, 10 Jul 2019 00:10:10 -0700

-- 
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-259904978

---

From: ianswett <[email-masked]>
Date: Sat, 20 Jul 2019 13:24:18 -0700

ianswett approved this pull request.

-- 
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-264510150

---

From: David Schinazi <[email-masked]>
Date: Tue, 23 Jul 2019 08:47:47 -0700

9616f24592d5d23bb927661917238d9de7f4df42  Change MUST to SHOULD

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2851/files/93185582222626bad7f217199d35de05f81ced11..9616f24592d5d23bb927661917238d9de7f4df42

---

From: David Schinazi <[email-masked]>
Date: Tue, 23 Jul 2019 08:54:16 -0700

f659c0d3731fd6d9b332011455857cf342e49b3d  Add clarification on consequences of violating SHOULD

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2851/files/9616f24592d5d23bb927661917238d9de7f4df42..f659c0d3731fd6d9b332011455857cf342e49b3d

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 23 Jul 2019 09:39:23 -0700

kazuho commented on this pull request.

:+1: The requirements look good to me. I only have one editorial suggestion.

-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 can be used when a connection ID is not needed
+to route to the correct endpoint. An endpoint SHOULD 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
+or connection identification as these values can change during a connection's
+lifetime, and the peer can reuse a given address and port for additional
+connections. Similarly, the peer's connection IDs cannot be used for routing
+or identification, as they are not transmitted in the short header packets
+they send. Note that multiplexing while using zero-length connection IDs and
+relying on the four-tuple of IP addresses and ports for routing will cause
+failures in the presence of connection migration, NAT rebinding, and client
+port reuse; and therefore MUST NOT be done unless an endpoint is certain that
+those protocol features are not in use.

I think it might be a good idea to move the "MUST NOT unless" up front, then explain the cases where a zero-length connection ID can be used. E.g.,

"Multiplexing while using zero-length connection IDs and relying on the four-tuple of IP addresses and ports for routing will cause failures in the presence of connection migration, NAT rebinding, and client port reuse; and therefore MUST NOT be done unless an endpoint is certain that those protocol features are not in use. A zero-length connection ID can be used when a connection ID is not needed to route to the correct endpoint. An endpoint SHOULD NOT use a zero-length connection ID unless it can use only its IP address and port to identify a connection. ..."

-- 
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-265535844

---

From: David Schinazi <[email-masked]>
Date: Tue, 23 Jul 2019 11:01:06 -0700

I think that becomes harder to read, but I think that's editorial so I'll let the editors decide how best to write this if we have consensus on the concept

-- 
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#discussion_r306455993

---

From: Igor Lubashev <[email-masked]>
Date: Tue, 23 Jul 2019 13:03:46 -0700

igorlord commented on this pull request.

Yes, editorial, but what about just this -- it captures to normative meaning without being redundant with other parts of the spec.

_A zero-length connection ID can be used when a connection ID is not needed to route to the correct endpoint. Since relying on the IP address and port of the peer for routing or connection identification will cause failures in the presence of connection migration, NAT rebinding, and client port reuse for multiple connections, an endpoint MUST NOT do so unless it is certain that those protocol features are not used by the peer._

-- 
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#discussion_r306507445

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Jul 2019 07:06:17 -0700

> @@ -924,11 +924,19 @@ selected by the client, both to ensure correct routing toward the client and to

The substance of the discussion we had suggests that this "cannot" is really a SHOULD NOT.

-- 
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-265589221