Draft: draft-ietf-quic-load-balancers

Commentary: Upon further consideration , any TP to provide CIDs for future connections should be in a different document . 
 LBs that are doing  routing are a special case . ( 1 ) If the Initial CID is routable , they ca n'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 does n't allow this , and it should . ( 2 ) that mode does n't work for unknown QUIC versions , obviously . ( 3 ) For QUIC versions the SNI - LB does n'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  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 NEWCONNECTIONID 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  routing is just incompatible with version - independent QUIC - LB ? 
 The down side of just saying " do n't do that ' is that then SNI Load balancing ca n't work with version aliasing , which would be sad because VA helps hide the SNI . 
 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()if it becomes RFC , maybe LB can not 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 . 
 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
Load balancers MUST forward packets with routable DCIDs to a server
in accordance with the chosen routing algorithm.
Load balancers MUST forward packets with routable DCIDs to a server
in accordance with the chosen routing algorithm.  Exception: if the
load balancer can parse the QUIC packet and makes a routing decision
depending on the contents (e.g., the SNI in a TLS client hello), it
MAY route in accordance with this instead.  However, load balancers
MUST always route long header packets it cannot parse in accordance
with the DCID (see version-invariance).
Some load balancers might inspect elements of the Server Name
Indication (SNI) extension in the TLS Client Hello to make a routing
decision.  Note that the format and cryptographic protection of this
information may change in future versions or extensions of TLS or
QUIC, and therefore this functionality is inherently not version-
invariant.
Some load balancers might inspect elements of the Server Name
Indication (SNI) extension in the TLS Client Hello to make a routing
decision.  Note that the format and cryptographic protection of this
information may change in future versions or extensions of TLS or
QUIC, and therefore this functionality is inherently not version-
invariant.  See also unroutable for other considerations about this
case.  Note that an SNI-aware load balancer, faced with an unknown
QUIC version, might misdirect initial packets to the wrong tenant.
While inefficient, this preserves the ability for tenants to deploy
new versions provided they have an out-of-band means of providing a
connection ID for the client to use.