Subject: Limiting connection ID supply

From: Martin Thomson <[email-masked]>
Date: Fri, 08 Feb 2019 13:55:01 +1100

https://github.com/quicwg/base-drafts/issues/2436 includes a simple issue: if someone starts retiring connection IDs aggressively, they can exhaust your supply.  Kazuho suggests that we allow endpoints to limit the number of connection IDs they supply.

There is a PR: https://github.com/quicwg/base-drafts/pull/2428

I don't think that this sort of rate limiting is generally advisable, because of the risk that this would discourage the use of new connection IDs.  Long connection IDs are a better solution, but those are inefficient and I don't want to get into a situation where connection ID rotation on shorter connection IDs is infeasible.  I think that the proposed text is worded carefully enough and strikes a good balance between these concerns.  I would like to merge this one.

---

From: Ian Swett <[email-masked]>
Date: Fri, 8 Feb 2019 09:58:19 -0500

In the theme of "servers are going to do what they need to do", this text
acknowledges the reality that CIDs may be a limited resource and servers
will want to limit how many they provide to a peer.

Merge it!

On Thu, Feb 7, 2019 at 9:55 PM Martin Thomson <[email-masked]> wrote:

> https://github.com/quicwg/base-drafts/issues/2436 includes a simple
> issue: if someone starts retiring connection IDs aggressively, they can
> exhaust your supply.  Kazuho suggests that we allow endpoints to limit the
> number of connection IDs they supply.
>
> I don't think that this sort of rate limiting is generally advisable,
> because of the risk that this would discourage the use of new connection
> IDs.  Long connection IDs are a better solution, but those are inefficient
> and I don't want to get into a situation where connection ID rotation on
> shorter connection IDs is infeasible.  I think that the proposed text is
> worded carefully enough and strikes a good balance between these concerns.
> I would like to merge this one.
>
>

---

From: Ted Hardie <[email-masked]>
Date: Fri, 8 Feb 2019 09:44:18 -0800

On Thu, Feb 7, 2019 at 6:55 PM Martin Thomson <[email-masked]> wrote:

> I think this idea is generally good, but I have a slight concern that the
full text reads as if the connection-IDs should be provided just before
migration.  That's largely because the text above it has a just-in time
flavor:

> The endpoint SHOULD do this by supplying a new connection ID when a
> connection ID is retired by its peer or when the endpoint receives a packet
> with a previously unused connection ID, though it MAY limit the frequency
> or the total number of connection IDs issued for each connection to avoid
> the risk of running out of connection IDs (see {{reset-token}}).
>
> Endpoints that initiate migration and require non-zero-length connection
> IDs SHOULD provide their peers with new connection IDs before migration, or
> risk the peer closing the connection.
>
I'd suggest a slight adjustment, to link back to the minimum requirement:

"Endpoints that initiate migration and require non-zero-length connection
IDs SHOULD ensure that the pool of connection IDs available to their peers
allows them to use a new connection ID on migration, as the peer will close
the connection if the pool is exhausted."

Does that change work for you?

Ted

---

From: Martin Duke <[email-masked]>
Date: Sun, 10 Feb 2019 11:28:22 -0800

I strongly support limiting Connection ID pulls. For servers with a
relatively limited pool of connection IDs, for whatever reason, allowing an
attacker to open a connection and getting a large sample of connection IDs
from one server can open up various attempts to crack the route encoding
scheme.

On Fri, Feb 8, 2019 at 9:45 AM Ted Hardie <[email-masked]> wrote:

>> IDs..  Long connection IDs are a better solution, but those are inefficient

---

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Feb 2019 09:33:34 +1100

> the connection if the pool is exhausted."

Thanks Ted, That matches my understanding of the requirement much better.  I've updated the PR to match.