Re: Questions about QUIC and Anycast

[Martin Thomson <[e-mail]>]

On Wed, Dec 19, 2018 at 5:47 AM William Herrin <[e-mail]> wrote:
> On Mon, Dec 10, 2018 at 4:41 PM Martin Thomson <[e-mail]> wrote:
> > On Tue, Dec 11, 2018 at 11:18 AM William Herrin <[e-mail]> wrote:
> > > Question 3: What picks the connection ID? Does the API allow the
> > > application software to influence the selection of connection ID in
> > > any way?
> >
> > The server picks connection IDs that the client puts in packets.  That
> > selection really has to be done in consultation with load balancers or
> > the folks managing routing configurations.
>
> How does short header versus long header impact this? Can the server
> instruct the client to use the full destination connection ID in both
> headers so that the full connection ID is available to a middlebox in
> every packet?

The destination connection ID included, in full, in every packet.  The
point of that is to ensure that that any middlebox that cooperates
with the server can use it.  (I say cooperates because the value can
change over time.)

> > > Question 2: Which packet contains the server preferred address?
> >
> > In practice, taking some of the less-used exchanges (Retry, Version
> > Negotiation, a TLS HelloRetryRequest) out of the picture, the server
> > will often include the value in the first flight of packets it sends.
> > However, that can be a couple of round trips away from the end of the
> > handshake, because the handshake is multiple packets and might need to
> > be repaired due to packet loss.
>
> Hmm. I'm curious what the reasoning is here. TLS would have to satisfy
> the same cryptography regardless of which address is used, would it
> not? Presumably the client could return to the original address upon
> failed communication with the preferred address, including a failure
> to negotiate TLS. How does requiring the TLS negotiation to complete
> before attempting the preferred address end up enhancing security in
> the bigger picture?

Yes, TLS can complete using multiple paths - it doesn't care.
However, we treat it like a black box, only releasing information once
it has been authenticated.  So while the preferred address might
appear in a packet, it won't be available until the handshake
completes.  Best case, that's immediately, because the server's
handshake fits into our amplification limit and there is no packet
loss.  However, that's not guaranteed.

We also simplify the protocol analysis by limiting the handshake to
the same address tuple.  Migration to a different address comes with a
bunch of other problems that we decided weren't worth grappling with,
like ensuring that the other endpoint genuinely can receive packets at
that address, and so forth.  Perhaps that is something that might be
improved with some work, but work is the scarce resource right now and
we're spending all we can on completing the other bits of the protocol
that we know need to be fixed.

> Does the preferred address have another use case besides load
> balancing? The load balancing process could be stateless if it could
> rely on the client shifting to the preferred address on packet #2. It
> seems to me that making the load balancing process stateless,
> especially in the anycasted CDN case, would be a big win if it could
> be done securely.

Yep, that "done securely" qualifier is the real catch.  See above.