Re: QUIC handshake challenges -- Share your experiences

[Marten Seemann <[e-mail]>]

Christian, I don't think that's correct. We discussed this during our work
on RFC 9000, and there's section 8.1 addresses exactly that problem:

> Loss of an Initial or Handshake packet from the server can cause a
deadlock if the client does not send additional Initial or Handshake
packets. A deadlock could occur when the server reaches its
anti-amplification limit and the client has received acknowledgments for
all the data it has sent. In this case, when the client has no reason to
send additional packets, the server will be unable to send more data
because it has not validated the client's address. To prevent this
deadlock, clients MUST send a packet on a Probe Timeout (PTO); see Section
6.2 of [QUIC-RECOVERY]. Specifically, the client MUST send an Initial
packet in a UDP datagram that contains at least 1200 bytes if it does not
have Handshake keys, and otherwise send a Handshake packet.

The easiest solution to the problem is to just send an ACK, but not the
certificate. This might mean sending a few additional bytes, but as I've
said in the meeting today, those won't suddenly make this an interesting
amplification vector.
Starting with a slightly higher RTT estimate is also not the end of the
world, especially if you're using a loss-based congestion controller that
will cause queues to build up at the bottleneck link during the connection.



On Fri, 31 Mar 2023 at 00:40, Christian Huitema <[e-mail]> wrote:

>
>
> On 3/30/2023 12:37 AM, Martin Thomson wrote:
> > On Thu, Mar 30, 2023, at 15:57, Marcin Nawrocki wrote:
> >> Unfortunately, I ran out of time before presenting the third challenge:
> >> An Initial containing both, the ACK and ServerHello, can skew the RTT
> >> estimation of the client for some deployments (e.g., CDNs). This is
> >> because the QUIC server can be separate from the process that has
> >> access to TLS material, so there is a noticeable delay for fetching the
> >> required TLS data.
> >
> > Yes, this will affect RTT estimates, but the effect will wash out over
> time.  The net effect is an inflated RTT estimate.
> >
> > You can maybe correct for this using ACK Delay.
> >
> >> Opinions on how to deal with this? Some CDNs split the Initial ACK and
> >> Initial ServerHello into two packets, leading to more padding bytes.
> >> Please see my slides 15-21 [1] for more information.
> >
> > I believe that some people already do this split, yes.  I would prefer
> that servers use subcerts for this:
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts
> >
>
> There is another issue. It is a bit risky for the server to send the ACK
> Initial before the client IP is validated. If the server ACKs the
> client's initial packets, the client does not need to send any further
> traffic until it has received the server hello. If the server hello is
> lost, the server will have to resend it, and it will have to do so
> within the amplification budget -- which in some cases may not be possible.
>
> There are potential workarounds of course. For example, the server could
> bundle a PING with the ACK, to force the client to send more initial
> packets and thus complete address validation.
>
> We may also lift the requirement that all server initial packets be
> padded to 1200 bytes, which would allow for better use of the
> amplification budget. But that's for QUIC v3...
>
> -- Christian Huitema
>
>