SNI Routing
martinduke opened this issue · comments
LBs that are doing SNI routing are a special case.
(1) If the Initial CID is routable, they can't just take that as good; they have to assume that it was random and inspect the SNI to make a decision. Section 4.1 doesn't allow this, and it should.
(2) that mode doesn't work for unknown QUIC versions, obviously.
(3) For QUIC versions the SNI-LB doesn't understand, I think this is the best we can do:
a) For QUIC versions it understands, the LB MAY find the SNI. It MAY use the SNI for unroutable CIDs. If a routable CID, it may override the encoded SID if that SID does not correspond to the provided SNI.
b) The QUIC-LB config explicitly states that the LB is doing SNI routing and the versions it supports
c) The server MAY send a TP that means "next time you connect with me, please use one of the connection IDs I provided in a NEW_CONNECTION_ID frame." This may also be useful for some persistence use cases.
The worst case is an unsupported version with a randomly generated CID. In this case, the LB will spray it and will only get lucky if it happens to get to the right tenant.
Sec 11.4 may also need a revision here.
Or maybe SNI routing is just incompatible with version-independent QUIC-LB?
The down side of just saying "don't do that' is that then SNI Load balancing can't work with version aliasing, which would be sad because VA helps hide the SNI.
(1) If the Initial CID is routable, they can't just take that as good; they have to assume that it was random and inspect the SNI to make a decision. Section 4.1 doesn't allow this, and it should.
Maybe specify a unique quic transport param is a better choice? For a web service, all requests just have same SNI, help nothing for distinguishing the Initial CID
Further more, there is a draft about encrypted client hello(https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-13)，if it becomes RFC, maybe LB cannot get information about clientHello or there must be some ways to synchronize the server private-key to LB
Further more, there is a draft about encrypted client hello(https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-13)，if%EF%BC%8Cif) it becomes RFC, maybe LB cannot get information about clientHello or there must be some ways to synchronize the server private-key to LB
synchronizing the server private-key is exactly what happens; that is what the "client-facing server" is in that draft.
(1) If the Initial CID is routable, they can't just take that as good; they have to assume that it was random and inspect the SNI to make a decision. Section 4.1 doesn't allow this, and it should.
Maybe specify a unique quic transport param is a better choice? For a web service, all requests just have same SNI, help nothing for distinguishing the Initial CID
I'm not sure what you're proposing here. My hope is not introduce a regression relative to current capabilities, but it sounds like you're talking about an L7 load balancer that's doing deep packet inspection. If so, that's out of scope for this document.
I'm not sure what you're proposing here. My hope is not introduce a regression relative to current capabilities, but it sounds like you're talking about an L7 load balancer that's doing deep packet inspection. If so, that's out of scope for this document.
OK, I got it