Re: Space for Packet Metadata

[Martin Thomson <[e-mail]>]

The current text says that if you need to exceed 3x, then you need to
do address validation.

"Servers MUST NOT send more than three Handshake packets without
receiving a packet from a verified source address. Source addresses
can be verified through an address validation token, receipt of the
final cryptographic message from the client, or by receiving a valid
PATH_RESPONSE frame from the client."

Certificate messages are big.  I see no trend toward smaller
certificates, but 3600 is getting decently large.  Certificate
compression *might* help with that.

Servers that accept 0-RTT are exposed to denial of service.  That's
entirely voluntary though.  Having to support fragmented Initial
packets would not be.

On Sun, Mar 4, 2018 at 7:40 AM, Praveen Balasubramanian
<pravb=[e-mail]> wrote:
> We could still require that the server not send any response until it gets a CI worth at least 1200 bytes and to do that we will need the CI to encode information to be able to span multiple UDP/IP packets and get reassembled at QUIC layer. But then there is this text that points out the DoS vector from stateful processing and reassembly:
>
> The initial cryptographic handshake message MUST be sent in a single
>    packet.  Any second attempt that is triggered by address validation
>    MUST also be sent within a single packet.  This avoids having to
>    reassemble a message from multiple packets.  Reassembling messages
>    requires that a server maintain state prior to establishing a
>    connection, exposing the server to a denial of service risk.
>
> But then some of that risk already exists for the optional handling of reordered 0-RTT data before the client initial:
>
>    0-RTT packets might be received prior to a Client Initial packet at a
>    server.  If the version of these packets is acceptable to the server,
>    it MAY buffer these packets in anticipation of receiving a reordered
>    Client Initial packet.
>
> Hmm even 3X sounds bad but Nick tells me there is text that requires server to do source address validation before sending such large certs.
>
> -----Original Message-----
> From: QUIC [mailto:[e-mail]] On Behalf Of Christian Huitema
> Sent: Saturday, March 3, 2018 12:01 PM
> To: Praveen Balasubramanian <pravb=[e-mail]>; [e-mail]; Nick Banks <[e-mail]>
> Cc: Mikkel Fahnøe Jørgensen <[e-mail]>; IETF QUIC WG <[e-mail]>; Eggert, Lars <[e-mail]>
> Subject: Re: Space for Packet Metadata
>
> On 3/3/2018 10:54 AM, Praveen Balasubramanian wrote:
>
>> By mandating a minimum MTU that is greater than the IP protocol minimum, are we assuming a fallback to TCP at application layer? I think the right thing to do for QUIC to stand on its own as a transport is proper PMTUD and be handle to min IPv4 MTU gracefully? Looking forward to the data about path MTUs.
>
> There is another reason -- avoiding DOS amplification. If the number of bytes in the client hello is much smaller than the number of bytes in the server first flight, adversaries can use that to amplify their DOS attacks. Not quite as bad as memcached, but still bad.
>
> The current spec mitigates this problem by requiring that the CI be padded to at least 1200 bytes. That's a partial mitigation, since the server first flight is "a few hundred bytes and a certificate", and the certificate can easily be over 2KB. So we have an amplification factor of 2 or 3. If the CI was only padded to 512 bytes, the amplification factor would be 5 or 6, which is quite bad.
>
> -- Christian Huitema
>