Re: Space for Packet Metadata

Christian Huitema <huitema@huitema.net> Sat, 03 March 2018 20:01 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86A9126E01 for <quic@ietfa.amsl.com>; Sat, 3 Mar 2018 12:01:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHQZNZ7DKmVk for <quic@ietfa.amsl.com>; Sat, 3 Mar 2018 12:01:32 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF54C12008A for <quic@ietf.org>; Sat, 3 Mar 2018 12:01:03 -0800 (PST)
Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx65.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1esDL3-0004cb-Ep for quic@ietf.org; Sat, 03 Mar 2018 21:01:02 +0100
Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1esDKz-0002IK-2p for quic@ietf.org; Sat, 03 Mar 2018 15:00:58 -0500
Received: (qmail 9453 invoked from network); 3 Mar 2018 20:00:55 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.241]) (envelope-sender <huitema@huitema.net>) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for <lars@netapp.com>; 3 Mar 2018 20:00:54 -0000
To: Praveen Balasubramanian <pravb=40microsoft.com@dmarc.ietf.org>, "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, Nick Banks <nibanks@microsoft.com>
Cc: =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= <mikkelfj@gmail.com>, IETF QUIC WG <quic@ietf.org>, "Eggert, Lars" <lars@netapp.com>
References: <CAN1APdfx4Y4MUm5iAF99Vn1Svck5y2e6_qrNbozkwJWics17eQ@mail.gmail.com> <96577B0E-502B-4723-9A9B-63D8B365D5AA@netapp.com> <CAN1APddJJHrpKBjn+U=rYYzxnuwyRYvA3++0T_ZRMy15fCJgbQ@mail.gmail.com> <FC9963A9-F5B4-4A4B-8DE9-FB938B390BB0@netapp.com> <DM5PR2101MB09010484CA0782C13E43C2C4B3C70@DM5PR2101MB0901.namprd21.prod.outlook.com> <5A96D399.4010300@erg.abdn.ac.uk> <CY4PR21MB0630399F691CCDD4BE128043B6C40@CY4PR21MB0630.namprd21.prod.outlook.com>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <f6824550-fcfd-2f60-8de8-c7f51ec48146@huitema.net>
Date: Sat, 3 Mar 2018 12:00:50 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <CY4PR21MB0630399F691CCDD4BE128043B6C40@CY4PR21MB0630.namprd21.prod.outlook.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Subject: Re: Space for Packet Metadata
X-Originating-IP: 168.144.250.190
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.18)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5kAzlGCb/scI7JDT002R//1602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVi7gAqgPXI2+DQYaDPREWzic7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBuzDn5j2tUhjYPVPi3bwTCB/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjSYb8Ll5Ew7esaVIVXxqL4mdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3upW940lL8kAcN44/h+EKQYbFsSSg3Wl95M4olDAUfl jmDPqNS87uypj9BGYBqAWP1cHW0PW4JWJhYU/TTlqwtVrj3ufUCIoIEGM6ervFCViNm1LR/Rkhms gi1bNni1Nx10xK5dOvm4pbg8CBiJcsFLIaKLZaIWHErhz1UEr981hLCx4eCSemGsHMs75OfoLqfN rvZnZQMmDvpiQ5lk4oTQpyI1J519bLUrM3neslGWzki/rf8tKY4HamJqFKZJr3jouROe77KOt1v8 CMoiiVQVf/qOH8le3Zo2iD646pXyZ4OQYXJpH/D0tmDFepUle/YKcZIuviiTlhP5iKsKcxHR+Qog qeKyP7VkdiNECHuevToUd/Fji/4E0A1Wfl7CNnoniG/Mx18wh299NVDnPvmw8t3Xj/LzZ5s/OJg1 L2asZ1FPmtYUPwECbZov76lmox9FrrkXXOH9yk2+X2eiUHXZfks5suSVIgIg9uJ3gfzn7g==
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/aLiOanMGcodlDuhHqwTlVpAPGwA>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Mar 2018 20:01:34 -0000

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