Subject: [quicwg/base-drafts] Definition of "active connection ID" is misleading (or the name is) (#3200)

From: Kazuho Oku <[email-masked]>
Date: Wed, 06 Nov 2019 17:21:54 -0800

In [section 5.1.1](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.5.1.1), we state that:
> An endpoint SHOULD ensure that its peer has a sufficient number of available and unused connection IDs. Endpoints store received connection IDs for future use and advertise the number of connection IDs they are willing to store with the active_connection_id_limit transport parameter. An endpoint SHOULD NOT provide more connection IDs than the peer’s limit.
> 
> An endpoint SHOULD supply a new connection ID when it receives a packet with a previously unused connection ID or when the peer retires one, unless providing the new connection ID would exceed the peer’s limit.

I think that these are correct. However, we also state:
> Connection IDs that are issued and not retired are considered active; any active connection ID can be used.

I think this is incorrect. This should instead state that "Connection IDs that are **unused and** not retired are considered active, ..."

That said, I think the name is confusing, as it is awkward to argue that the connection ID that is currently used is "active."

Maybe we should rename the parameter to something like "spare_connection_id_limit."

-- 
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/3200

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Nov 2019 17:51:44 -0800

Isn't it impossible to agree on whether a given connection ID was used?  In particular, connection IDs sent on unusable paths won't be received by the issuer to allow them to know that they a no longer unused.

-- 
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/3200#issuecomment-550583206

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 06 Nov 2019 18:30:31 -0800

> Isn't it impossible to agree on whether a given connection ID was used?

I hastily reused the term "unused" from the other text quoted above. So please interpret "unused" as "until receiving a packet with a previously unused connection ID."

-- 
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/3200#issuecomment-550592251

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 06 Nov 2019 18:38:55 -0800

FWIW, the alternative approach (that could better match people's intuition) would be to retain the definition of "active connection IDs" as _connection IDs that are issued and not retired are considered active_, and change the normative texts.

Actually, I think that might be a better choice, due to the following two reasons:
* Current text requires you to issue new CIDs under two conditions; i.e., when receiving a packet carrying a previously unused CID, or when receiving RETIRE_CID. We can get rid of the former.
* Current design has a potential DoS vector that could lead to memory exhaustion on the CID issuer. This is because the number of CIDs that the current text recommends an endpoint to retain is active_connection_id_limit + number_of_CIDs_in_use. The number of CIDs in use is something that the consumer of CIDs controls. Changing the number of CIDs to be retained to just the value of active_connection_id_limit eliminates that attack vector.

-- 
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/3200#issuecomment-550594170

---

From: Marten Seemann <[email-masked]>
Date: Wed, 06 Nov 2019 19:00:15 -0800

> FWIW, the alternative approach (that could better match people's intuition) would be to retain the definition of "active connection IDs" as connection IDs that are issued and not retired are considered active, and change the normative texts.

@kazuho I agree, that was my understanding of the spec, since this is what the definition of the TP implies to me:
> "An endpoint SHOULD supply a new connection ID when it receives a packet with a previously unused connection ID or when the peer retires one, unless providing the new connection ID would exceed the peer’s limit.

I think it might be worth considering to slightly change the definition of the TP though, such that it includes the CID used during the handshake (and the one provided in the SPA). Otherwise, when the peer provides the requested number *N* of CIDs, you actually have to store *N+1* CIDs, until you retire the CID used during the handshake. Furthermore, on the peer's side, after having provided *N* connection IDs, it must take care of NOT issuing a replacement for CID 0 when it is retired (whereas all other CIDs need to be replaced).

-- 
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/3200#issuecomment-550598930