On 3/30/2023 11:00 AM, Marten Seemann wrote:
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.
I think my objection sums up to "server will need to trust that the
client will send a packet on a Probe Timeout (PTO)". If the client does,
then fine. But if it doesn't, then the server is stuck.
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.
I would advise bundling a PING with the ACK in that case. Seems better
than risking being stuck waiting for the PTO to elapse.
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.
It is definitely not a huge issue. The initial handshake provides an
early estimate of the RTT, which of course will need to be refined with
further measurements.
-- Christian Huitema
On Fri, 31 Mar 2023 at 00:40, Christian Huitema <[email protected]> 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
