Subject: RE: Space for Packet Metadata

From: Praveen Balasubramanian <[email-masked]>
Date: Sat, 3 Mar 2018 18:54:58 +0000

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.

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Gorry Fairhurst
Sent: Wednesday, February 28, 2018 8:07 AM
To: Nick Banks <[email-masked]>
Cc: Mikkel Fahnøe Jørgensen <[email-masked]>; IETF QUIC WG <[email-masked]>; Eggert, Lars <[email-masked]>
Subject: Re: Space for Packet Metadata

For IPv6 that may be fine.

The QUIC transport paper (*) Section 7.1 speaks of "Packet Size
Consideration"- as far as I know this is just UDP traffic from google Chrome clients to google servers. They showed 3% unreachable for 1200 B payloads. Other networks could well be different.

We are in the midst of a large measurement campaign related to our work in TSVWG on path MTU discovery. I would expect a wide variety of Path MTUs - even though the current majority of paths will support 1280 bytes, many IPv4 paths do not - there are also many paths that support much more.

Gorry

*
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdelivery.acm.org%2F10.1145%2F3100000%2F3098842%2Fp183-Langley.pdf%3Fip%3D212.159.18.54%26id%3D3098842%26acc%3DOA%26key%3D4D4702B0C3E38B35%252E4D4702B0C3E38B35%252E4D4702B0C3E38B35%252E5945DC2EABF3343C%26__acm__%3D1519833743_fa365ff0c9cc6c6e266add2dba8f385f&data=04%7C01%7Cpravb%40microsoft.com%7C06b35440043a44c5741708d57ec55f30%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636554308540125446%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=xUQP43CnIUkTU7lavv5i8GMNo5DK2Zkf9QbwhYo8SPY%3D&reserved=0

On 28/02/2018, 15:30, Nick Banks wrote:
> According to spec, QUIC requires at least 1280 (from 9.4):
>
> "QUIC depends on the network path supporting a MTU of at least 1280 octets. This is the IPv6 minimum MTU and therefore also supported by most modern IPv4 networks. An endpoint MUST NOT reduce its MTU below this number, even if it receives signals that indicate a smaller limit might exist.'
>
> - Nick
>
> -----Original Message-----
> From: QUIC<[email-masked]>  On Behalf Of Eggert, Lars
> Sent: Wednesday, February 28, 2018 7:12 AM
> To: Mikkel Fahnøe Jørgensen<[email-masked]>
> Cc: IETF QUIC WG<[email-masked]>
> Subject: Re: Space for Packet Metadata
>
> On 2018-2-28, at 16:03, Mikkel Fahnøe Jørgensen<[email-masked]>  wrote:
>> Yes, but can it go below 1200? It seems the handshake aims to squeeze up near the minimum guaranteed (required) PMTU and QUIC implementations would probably not expect to maintain a connection that drops below PMTU 1200.
> The minimum IPv4 MTU is 576, so I'd expect QUIC stacks to probe as least that low.
>
> Lars

---

From: Christian Huitema <[email-masked]>
Date: Sat, 3 Mar 2018 12:00:50 -0800

> 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 tran…

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

---

From: Christian Huitema <[email-masked]>
Date: Sat, 3 Mar 2018 12:00:50 -0800

-- Christian Huitema

---

From: Praveen Balasubramanian <[email-masked]>
Date: Sat, 3 Mar 2018 20:40:57 +0000

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:[email-masked]] On Behalf Of Christian Huitema
Sent: Saturday, March 3, 2018 12:01 PM
To: Praveen Balasubramanian <pravb=[email-masked]>; [email-masked]; Nick Banks <[email-masked]>
Cc: Mikkel Fahnøe Jørgensen <[email-masked]>; IETF QUIC WG <[email-masked]>; Eggert, Lars <[email-masked]>
Subject: Re: Space for Packet Metadata

> 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 tran…

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

---

From: Praveen Balasubramanian <[email-masked]>
Date: Sat, 3 Mar 2018 20:40:57 +0000

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Christian Huitema
Sent: Saturday, March 3, 2018 12:01 PM
To: Praveen Balasubramanian <pravb=[email-masked]>; [email-masked]; Nick Banks <[email-masked]>
Cc: Mikkel Fahnøe Jørgensen <[email-masked]>; IETF QUIC WG <[email-masked]>; Eggert, Lars <[email-masked]>
Subject: Re: Space for Packet Metadata

-- Christian Huitema

---

From: Martin Thomson <[email-masked]>
Date: Mon, 5 Mar 2018 10:03:43 +1100

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.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 5 Mar 2018 10:03:43 +1100