Re: [quicwg/base-drafts] Invert the connection ID logic during the handshake (#442)

[Igor Lubashev <[e-mail]>]

The goal of the design is to support long-lived QUIC connections, especially across network migrations (wifi <-> cellular, for example).  The initial few packets would need to be handled "statefully" by the load balancers, but the server-generated ConnectionID would include bits that help the load balancers identify the server handling this connection.  Hence, CDN load balancers would be able to continue routing the packets correctly even if they start reaching a different load balancer, which can be in the same or even a completely different pop. 

    On Tuesday, April 25, 2017 4:46 PM, MikkelFJ <[e-mail]> wrote:
 

 Perhaps I am missing something fundamental, butIf a stream is set up during 0rtt or clear text, the stream cannot continue once the client id changes to server id if loadbalancers route traffic elsewhere when the id is updated. All the state machinery won't work.It's fine to have stateless setup, but then it needs to a UDP oriented approach such that streams and retransmissions are removed during this phase and replaced with a simpler retry until success. For example, periodically sent ClientHello until ServerFinal is received, and there would be no ServerNonFinal because that is stateful. ServerNonFinal is problematic regardless because it is not ordered by a stream, so this makes structuring the handshake rather complex.For 0RTT the entire point is to start early - so here the routing needs to reach a stateful server early. But then again, as long as replay attacks are not solved for 0RTT, they have limited.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread. 

   

-- 
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/442#issuecomment-297227297