Forced connection ID retirement

[martinthomson]

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.

[erickinnear]

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?

[kazuho]

@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.

[nibanks]

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).

[MikeBishop]

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.

[larseggert]

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.