Re: QUIC handshake challenges -- Share your experiences

[Christian Huitema <[e-mail]>]

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 <[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
>>
>>
>