Subject: [quicwg/base-drafts] Forced connection ID retirement (#3420)

From: Martin Thomson <[email-masked]>
Date: Wed, 05 Feb 2020 03:50:36 -0800

Requiring RETIRE_CONNECTION_ID has lead to all sorts of corner cases.  For instance, a server can force a client to retire the connection ID that is still in use for the handshake.  (We're uncertain yet as to whether the newly provided connection ID usable here, so this only *might* cause genuine problems.)

More to the point, this design assumes things about the nature of connection IDs and routing infrastructure that imply a coupling between path and endpoint state.  The reason you might want to retire a connection ID forcibly in this fashion is that it is no longer usable for routing purposes (or that it results in suboptimal routing, perhaps where packets need to be bounced between nodes in a cluster).

All of this implies that the address tuple is part of the routing assessment.  That makes this feature fragile and it also creates some uncertainty about whether it is possible to build such a system without having a stateless reset oracle.

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

---

From: Eric Kinnear <[email-masked]>
Date: Wed, 05 Feb 2020 03:53:56 -0800

Just to clarify, my understanding of the problem here isn't `RETIRE_CONNECTION_ID` itself, but rather that an issuer of a CID can send `RetirePriorTo` to require that the consumer MUST retire the CID immediately?

-- 
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/3420#issuecomment-582373152

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 05 Feb 2020 05:08:54 -0800

@martinthomson 
> More to the point, this design assumes things about the nature of connection IDs and routing infrastructure that imply a coupling between path and endpoint state.

I'm not sure if I follow what you state here.

Much like a TLS server having a master key that encrypts TLS session tickets, a server might have a master key that is used for encrypting all the CIDs, and it rotates that key periodically. In such a design (which I'd assume to be pretty normal), there is nothing related to paths.

-- 
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/3420#issuecomment-582399060

---

From: Nick Banks <[email-masked]>
Date: Wed, 05 Feb 2020 05:12:46 -0800

MsQuic also uses CIDs and RetirePriorTo to encode "on machine" routing information, such as per-CPU partitioning. When we rebalance load across these partitions, we generate new CIDs to match.

I also don't quite understand the point of this issue. If the problem is just that we don't want CIDs to change before a certain time, I'm fine with adding some extra restrictions on that. But I'm very strongly against removing this feature (assuming that's the goal of this issue).

-- 
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/3420#issuecomment-582400564

---

From: Mike Bishop <[email-masked]>
Date: Wed, 05 Feb 2020 05:15:18 -0800

This isn't about being bound to addresses, though.  It's about anything in the server infrastructure changing.  That could be rotation of the keys used to encrypt a structure to produce packet IDs.  I think there's a separate discussion about whether CIDs can be bound to server IPs for preferred addresses, but that's covered by #3354 already.

-- 
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/3420#issuecomment-582401610

---

From: Lars Eggert <[email-masked]>
Date: Wed, 05 Feb 2020 07:18:23 -0800

Discussed in ZRH. Proposed resolution is to prepare a PR that clarifies the consequences for both sides on what happens when an endpoint sends a NEW_CONNECTION_ID frame, and for the receiver for what it means if it doesn't retire. Also, remove PTO from text related to retirement.

-- 
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/3420#issuecomment-582457078