Server-proposed connection ID

[martinthomson]

QUIC currently has the ability to embed this in the source address token. I guess that this is primarily because they both happen at the same time (during a stateless reject).

We could turn this into a transport parameter, I guess, but that doesn't work for HelloRetryRequest.

[igorlord]

When a client is using a Server-proposed connection ID, it would be best for the client to indicate that it is doing so in Version Negotiation packets. That can affect a decision by some servers to perform a Stateless Reject with a new Server-proposed connection ID again.

[kazuho]

We'd like to have this feature go into the spec for the following reason.

We have anycast IPs mapped to multiple POPs, and want to continue serving requests if the packets start arriving at a different POP.

With QUIC, since the source address changes, it is much more likely than TCP/IP that packets will start arriving at a different POP mid-connection. In such case, we want to forward packets between the POPs so that we can continue serving responses in-flight.

For the purpose it would be beneficial if we generate connection ID on the server side, with the POP ID included as part of the connection ID.

[martinthomson]

@igorlord the normal order of operations is version negotiation THEN stateless reject. If you want to allow a server to redirect to another node, THEN do version negotiation, things are going to get crazy at the client. The client has just seen a server accept its selected version, but then it sees it reject that version.

BTW, I am assuming that stateless reject has to come after version negotiation, as it does in the current design.

[igorlord]

@kazuho This is a part of our use case as well. In fact, to help with anycast routing, I opened another issue #205 to allow for more bits for this routing information (I am worried about running out of entropy).

@martinthomson The idea would be that the server accepts the client's Version AND (in the same packet) tells the client to go away and come back with a given ConnectionID.

[mnot]

Discussed in Tokyo; clients will not include a connection ID in the first flight of packets until it receives one from the server, i.e., we're moving to server-generated connection IDs

[martinthomson]

Note: the obvious way to address this issue is to just change the connection ID. However, that creates a problem if the new connection ID is sent with a HelloRetryRequest (i.e., stateless reject). A client that receives a HelloRetryRequest will be unable to verify that the server actually received its packet. A client can't know if it is reacting to an off-path attacker. It will only learn later when its handshake falls apart.

If echoing 31 bits of entropy is sufficient, this can be addressed by requiring that the server also ACK the ClientHello. #283 means that the server would have to have seen the randomized packet number.

[ianswett]

A note on mnot's summary. This was correct when written, but since then it seems everyone is moving towards a model where the client provides a connection ID and the server replaces it. I support this change, but I wanted to note it's different from what was agreed upon in Tokyo.

I support requiring acking the CHLO in the same packet as the HRR, as it makes the recovery doc cleaner and isn't that difficult to implement.

The HRR could also contain a new connection id in it, for use by the client. This is what QUIC currently does for stateless rejects.

This would mean for the first full round trip, the client proposed connection id would be used, and then the connection switches to the new connection id. In the case of a stateless reject(or version negotiation), I believe we want to use a new connection id anyway, since it's a new connection.

[martinthomson]

I don't think that we want or need to have a new connection ID in the HelloRetryRequest. We want the server to be able to propose a new connection ID without adding a round trip, so I'm going to suggest that we just have the server include a new connection ID in the header when it answers. That can be on the stateless reject, or when the server continues the connection (ServerHello).

Stateless reject can't really be a properly "new" connection, at least from the client perspective: the TLS handshake transcript includes the initial ClientHello, the HelloRetryRequest and second ClientHello.

[mirjak]

Or if you have a random packet number and a packet number echo (#269) this anyway gives you a way to verify that the server received your packet.

[ianswett]

@martinthomson Ok, that's very different from how I thought stateless reject was going to work. Does the server need to include the entire ClientHello in the source address token to allow it to be stateless, or can it send a hash of some sort?

Also, if you put the new connection ID in the HRR, why would that cost a round trip?

Either way, I think acking the packet is sufficient entropy, so I believe that solution closes this issue. Acking is better than packet number echo in the sense that the ack would remove the packet from flight, stop retransmissions, etc.

[martinthomson]

The server can pickle hash state into the cookie. There's some continuing discussion about the details of that in TLS, but that only really affects how easy it is to implement and the cookie size.

It's not the source address token, that would be separate information.

Using HRR would cost an extra round trip if that was your only way to propose a new connection ID. In the normal, happy case we would want to avoid using HRR because it imposes a round trip penalty.

[MikeBishop]

#361 purports to address this; please re-open or file a new issue if that's incorrect.