RE: Space for Packet Metadata

[Praveen Balasubramanian <[e-mail]>]

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