RE: Space for Packet Metadata

Praveen Balasubramanian <> Sat, 03 March 2018 20:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D8ED5124217 for <>; Sat, 3 Mar 2018 12:41:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r2LdKYjosNlu for <>; Sat, 3 Mar 2018 12:41:01 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4442B1270A7 for <>; Sat, 3 Mar 2018 12:41:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iOOPfhaSLMCAg55qEME3y38NZ1g++sOrco/O4Lxqfqg=; b=XnRwCzLWBcA7bWyFfmbI5nnZxAs0FIVz0GdCbxayzCII5Y55kCf3eW/Aefqd3ScO2TIQSS1Ql+jl37+ngOt9XTwRRlvQa1dC2nJrjXCKjDblO/B9Y0rph0AQEDaKJ5l3/59UsnSjuVuL1VltbzN5w0F1fJbOgQaTNZjwXZnX+58=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.567.2; Sat, 3 Mar 2018 20:40:58 +0000
Received: from ([fe80::a029:9024:f580:374b]) by ([fe80::a029:9024:f580:374b%8]) with mapi id 15.20.0567.006; Sat, 3 Mar 2018 20:40:58 +0000
From: Praveen Balasubramanian <>
To: huitema <>, Praveen Balasubramanian <>, "" <>, Nick Banks <>
CC: Mikkel Fahnøe Jørgensen <>, IETF QUIC WG <>, "Eggert, Lars" <>
Subject: RE: Space for Packet Metadata
Thread-Topic: Space for Packet Metadata
Date: Sat, 03 Mar 2018 20:40:57 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: [2001:4898:80e8:7::97]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR21MB0127; 7:PEw2CIw2DalfuIxhvCYdvuoPy3S26XLb4GQUrDrsvIZgjU5bWMdhuKWyUnb8BnEClss2T/tehuJrmk7EyuGsNQMGmrHBEQMXFZrlnZlgiLp8T0x88ycD7yj9sJ+6gvynyw8pIkCXeomRMzR6r07kwgq7oXpYD9JXKCCATEw7m/Y3On8B3MATK6ZOTLB5hVQAGyhTKppIkXeHAtR6nMGveZ7F/cYyuBED/Cda7MQUdOV7C28581KiJgouHK3jxDdR
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 38ca86ca-0400-4c6f-c8b0-08d58147118e
x-microsoft-antispam: UriScan:(130329453890623); BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:MWHPR21MB0127;
x-ms-traffictypediagnostic: MWHPR21MB0127:
authentication-results: spf=none (sender IP is );
x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(89211679590171)(85827821059158)(130329453890623);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231220)(944501244)(52105095)(6055026)(61426038)(61427038)(6041288)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:MWHPR21MB0127; BCL:0; PCL:0; RULEID:; SRVR:MWHPR21MB0127;
x-forefront-prvs: 0600F93FE1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(366004)(39380400002)(376002)(396003)(13464003)(189003)(199004)(97736004)(8990500004)(316002)(186003)(2900100001)(3480700004)(305945005)(3660700001)(6116002)(93886005)(110136005)(81166006)(2501003)(8936002)(6436002)(7696005)(1511001)(76176011)(46003)(81156014)(33656002)(74316002)(54906003)(99286004)(53936002)(9686003)(10090500001)(478600001)(68736007)(86612001)(86362001)(102836004)(6506007)(10290500003)(2906002)(5660300001)(105586002)(14454004)(229853002)(53546011)(59450400001)(106356001)(39060400002)(25786009)(5250100002)(3280700002)(4326008)(2950100002)(7736002)(6246003)(55016002)(22452003)(8676002)(6636002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0127;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: TeFSOGObAGFJBVvoo2eMo6DOiQf+FGKrUVVJcZ8KLMGn9eRqzMpoEWX7B5Czp+9GqvGnWyk8L1r1ivQMttFPNR5zNUcY48LJBzbQoiXpACk5raoGmeLBHk2e2ZNwzPT6OMdE+4KzR4DF/UEjGqYmslVzTCj0qpzJYQYkB897lvY=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 38ca86ca-0400-4c6f-c8b0-08d58147118e
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2018 20:40:57.8523 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0127
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: Sat, 03 Mar 2018 20:41:04 -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 [] 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