Move connection ID change to only Server Cleartext

[martinthomson]

Closes #588

[MikeBishop]

This says the connection ID field contains the original packet's packet number. Don't think that's correct.

[martinthomson]

I believe that it is correct.

[MikeBishop]

No, the packet number field should contain the client's packet number, and the connection ID field should contain the client's connection ID. Otherwise, this is just... weird.

[igorlord]

So if I have 50% of the backend servers upgraded to a newer QUIC version, how do I make sure that client comes back to the same server after Version Negotiation? I.e. I think what you are doing here is removing Server Connection ID from Version negotiation packets.

[chocis]

Why such design changes? I want to selectively decide which server will load balance asymmetric cryptography (heavy processing) of TLS handshake. With this design its not possible.

[martinthomson]

@chocis, That was discussed here at the interim as being a primary advantage of the current design. No one spoke in favour of retaining that.

[janaiyengar]

This sentence is slightly misleading, since 0-RTT packets will continue using the client Connection ID. I would remove this sentence since paras below cover everything else.

[martinthomson]

"... for all packets other than 0-RTT packets." ?

[MikeBishop]

@huitema also spoke against that, since it becomes easy for an attacker to forge.

[chocis]

Well then I would like to propose to reconsider that. Is there any reason why Server Stateless Retry couldn't change CID?

1. Firstly, in my opininon server without using Server Stateless Retry (without verifying src address/port) is simply asking to be DOS attacked. I could fill server's RAM with Raspberry Pi by simply spoofing src address. Thats why I am talking about situation where that check is enabled.

2. Secondly, imageine that you want to use CID for load balancing your clients. In current solution you would have to support accepting TLS handshake on all backends and when initial request is validated the partial TLS and QUIC state must be serialized and somehow transported to decided loadbalanced server (with the new CID) - and thats not easy AT ALL. I think, that this can be solved by simply returning new CID in Server Stateless Retry without doing any work or state transportation on backend.

[igorlord]

The way I would implement the load balancer:

1. If the packet has CCID, consistent hash it into the pool of backend servers for this dest IP or hostname based on the 6-tuple (5+tuple + CCID) and forward the packet.
   1a. The backend server replies with a Version Negotiation packet (too bad cannot use SCID here). or
   1b. The backend server replies with a SCID to continue the handshake.

2. If the packet has SCID, validate that SCID seems ok and forward the packet to the identified server.