Re: Space for Packet Metadata

Martin Thomson <> Sun, 04 March 2018 23:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 54B48126C25 for <>; Sun, 4 Mar 2018 15:03:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W1uFS9GW87XK for <>; Sun, 4 Mar 2018 15:03:44 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c0f::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9D845126B72 for <>; Sun, 4 Mar 2018 15:03:44 -0800 (PST)
Received: by with SMTP id 95so13356099ote.5 for <>; Sun, 04 Mar 2018 15:03:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=nWDPRlxEj7mLnOCgcCFMM8Il80i9RnK2oLqLntNQVUw=; b=AqYtPhKlqhiCF0GWaKFybFPcHInYM14XRKzBD1beqdSztz/l3QTfsp/+Tr1x3EGq/y TbwmAYFPKsxY9yL4rWZp/LdDzKE2zEexNNnYBHC5/3Op6EGILBPkc3n4l+EvAhyYB1LP IUCymcEb41RflOpdMdRQftP+lrDZtDDf5z3yNaAEnULILFDxr+wkpMLCtmhdvUTKtXzr f0ONFcrQky9YeQOcyqbVgdIycY6hiwv2JiSfxHErJvOB1EmLkCe1JNaEfeeGJ/1xR+w0 wOwL/YmlYZaIDSWjpA3VAAMBNT4Eqr8VEmi0TYCkfH2ckoNx2Sx9bT8XYCvKIAKaycfm vMvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=nWDPRlxEj7mLnOCgcCFMM8Il80i9RnK2oLqLntNQVUw=; b=UdTo+ZVZ1C971gd+LZ35g4STWVYPTGTLfjpK7A5sRmSVCRNmXER2SOnsoaXJlxdp2z C1Q8Vskz94RfmSJEuBW4hP1OLEeNBCHfdmAwg0oolfta5Hr1eh/FTiu7ZgoBsRDGAVoo Os1lMz97ZaJHufWD4j5s5TXx2T41obt+W5Lwnogj50a6Jy/ewwWtop/sezQXwuEhAyeW Tq7njRD3sKGg3GMKnHd19vT6iZmJunwQHtMMCd/9RXMODbjNFhOJTLrmmNdmPpZIFP/K cSUaOLOlo+3DUDLeax0jjbWc1lEQ5lNtgsVFBQwnY5h9kUpO8UQIZmebkNN2ZVe5uqr1 LZpQ==
X-Gm-Message-State: AElRT7HRDfeKfbgGAnuycdBUltLLkhWnoitfjYm5PV/4XoK12/qmxXDE GhSV/811/4mXmUfXygrTawRpKs/vzlkdoRiDjLA=
X-Google-Smtp-Source: AG47ELuuDjcS4T20pdZ08Fg8XnoKhZ7dKxMnDy+P2bLqsMZw8IbyQSnv2hQyx2f9lgd7t0hcP3ZO2uyIr/NXJID5btA=
X-Received: by with SMTP id 68mr8616244ota.392.1520204623827; Sun, 04 Mar 2018 15:03:43 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 4 Mar 2018 15:03:43 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Martin Thomson <>
Date: Mon, 05 Mar 2018 10:03:43 +1100
Message-ID: <>
Subject: Re: Space for Packet Metadata
To: Praveen Balasubramanian <>
Cc: huitema <>, "" <>, Nick Banks <>, Mikkel Fahnøe Jørgensen <>, IETF QUIC WG <>, "Eggert, Lars" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 04 Mar 2018 23:03:46 -0000

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