I can't speak to the security concerns MT raised, but if we do use NEW_CONNECTION_ID to populate the initial DCID in later connections, I *do* think we need to write down this expectation somewhere, and QUIC-LB may be as good a place as any.
1. How does the client know that the resumption state is local, and therefore that it should use a previously provided connection ID? 2. A Retry would hopefully not divert this to a different server (but maybe under Retry conditions killing resumptions is acceptable) On Wed, Jul 28, 2021 at 10:08 AM Christian Huitema <[email protected]> wrote: > > On 7/27/2021 11:42 PM, Martin Thomson wrote: > > On Wed, Jul 28, 2021, at 11:55, Christian Huitema wrote: > >> [...] reuse one of the NEW TOKENS as Initial CID, [...] > > Are you talking about NEW_CONNECTION_ID here? > > Yes. Sorry for the confusion. (Skipping comments on the progressive > effect of aging on Christian's brain cells.) My initial idea was for > creating an extension frame, with the server providing a new connection > ID for the specific purpose of use in resumption of this connection. In > a private message, Martin Duke suggested that clients could just as well > use one of the NEW CONNECTION ID provided by the server. Clients can do > that today, no change in spec required. > > > If you are talking about the client taking a connection ID from an old > connection and using that when establishing a new connection, that's an > interesting choice. I don't think it works because it undermines the > return routeability check for the subsequent connection. The server now > knows what the connection ID might be. I can't think of an exploit for > that given that the server has already demonstrated that it is on path, but > we do pretty much say that the connection ID can't be predictable like > that, and there are no firm requirements that the subsequent connection > attempt follow the same network path in any way. > > I was not suggesting that placing a specific value in the ICID replaces > the need for tokens and checking return routeability. Now, it is true > that the servers and the load balancers could also coordinate their > handling of token, and achieve the desired effect of sending connection > resumption attempts to the same server as the original connection. That > may very well be a better design than relying on the client to put > specific values in the ICID. > > > I had assumed that the load balancer would be able to identify an > initial and then route based on the Token field in that packet, rather than > the connection ID. Maybe that's too complicated, but it is something that > could be used without protocol modifications. > > Yes. Looks like the way to go if we want to experiment with STEK-less. > > I think placing the NEW CONNECTION ID in an ICID has a different usage > -- testing the robustness of load balancing... > > -- Christian Huitema > > >
