Re: Proposal: Increase QUIC Amplification Limit to 5x
Christian Huitema <huitema@huitema.net> Wed, 31 July 2024 15:14 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 9C0F7C14F71E; Wed, 31 Jul 2024 08:14:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iKQEofAJ4iR; Wed, 31 Jul 2024 08:14:39 -0700 (PDT)
Received: from se03.mfg.siteprotect.com (se03.mfg.siteprotect.com [64.26.60.166]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98119C14F70A; Wed, 31 Jul 2024 08:14:39 -0700 (PDT)
Received: from smtpauth01.mfg.siteprotect.com ([64.26.60.150]) by se03.mfg.siteprotect.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1sZB1y-004h7M-Uu; Wed, 31 Jul 2024 11:14:38 -0400
Received: from [192.168.1.104] (unknown [172.56.168.245]) (Authenticated sender: huitema@huitema.net) by smtpauth01.mfg.siteprotect.com (Postfix) with ESMTPSA id 4WYwcD4Mtqz163NrG; Wed, 31 Jul 2024 11:14:20 -0400 (EDT)
Message-ID: <ac725575-da13-4365-90ce-8ea55bc46e72@huitema.net>
Date: Wed, 31 Jul 2024 08:14:20 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Proposal: Increase QUIC Amplification Limit to 5x
To: Paul Vixie <paul=40redbarn.org@dmarc.ietf.org>, IETF QUIC WG <quic@ietf.org>, Nick Banks <nibanks=40microsoft.com@dmarc.ietf.org>
References: <BL1PR21MB31152570F4497EBE91B3AF9FB3B02@BL1PR21MB3115.namprd21.prod.outlook.com> <4aac2fae-ddc6-453c-b974-751a7a37967c@redbarn.org>
Content-Language: en-US
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; keydata= xjMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1RmvN J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsKWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAzjgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB8J+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH
In-Reply-To: <4aac2fae-ddc6-453c-b974-751a7a37967c@redbarn.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Authentication-Results: mfg.siteprotect.com; auth=pass smtp.auth=huitema@huitema.net
X-Originating-IP: 64.26.60.150
X-SpamExperts-Domain: mfg.outbound
X-SpamExperts-Username: 64.26.60.150/31
Authentication-Results: mfg.siteprotect.com; auth=pass smtp.auth=64.26.60.150/31@mfg.outbound
X-SpamExperts-Outgoing-Class: ham
X-SpamExperts-Outgoing-Evidence: Combined (0.14)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT/cgTGH4wv6xcdSmD/O+ikhPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5y5A3J/XeA3xuAAR4Cx82+59KphrYT9NN0V5qN5wMrVncwe zNAtHeV2uihR9qZ4QThOGnnBU+4EowaLW7o+NQSMs5tbPPVBNOjwDBndhhXbUXERkqlX+IiDbciA F1uLI/y+ISrFe72eyO6n5th9UY3qQxw3PrweOe3KpETp0FwHPdfwYErb4UK8xFf97EoF4gzVUXAB MXPTRDioluV7ZUTUnsq4c1pop2DuIERl592w1ULOhIBnncXrr36zKwEYxTxmGDMcE5+3EdfnOfUO fwZc5P2oEr7YLXtswl1tSZcF52fLO8D5CtqmmsWw+ZzmGhR+KKbc43dcz7HPP4ZtftkeGFvlHOQs i9fJrQH2HB7KcikRseCyBjclZpv6D8yHWO2ec6cBx3r3HXymDSnwWpGuuZvJzloHvXAavZZu2bOH z0lNEHF1LSWF/K4qKVXG9aNSdi4w6Ftrt79wp24mUxann7wMnWiT5RBoQAV/ex6l926dmAF+OLHI SZgPhpcYjbXmFpqRYVFFvALkazARQWaZC5dbLycEBP/mrvUyk8dwMwDk5nWIiIcthdTaotkIarSS MR40yJqlODklfkrIVQZ6r5wapHTXyYiKeetuTJS9jf2aR0fNtSN3o9F8slkM9GABIkUL/j1Y48Gv meURQjjE9jHxh+zpaH+cnZ5n8EWPPArWxILsnce/vzk7Sg5HsMV2356Ck2Dnf2ihf3r+rA+0gePO cpG/ftzEM8VJqlaxI4OmfLBscnl5VChK0waqFLT3kcpVFW7l7akUNjYEDr3/nuH7pYZ0ijOvnCUj 7jYwFDkt4W3lwein2F36yqDcD1BR7gKuJOz6hvTOYnc+46EeHqIVltBC2jYT8pNfFoy1GARzHffA uMlKphZyT4VfLQEccBIk1Sag4dKiqCrF8eZZzFQoIg49svw8zIml7hhcT5DUvM2zf3x3vNDKd3go N4At/wmLvJjAEaXJHyohq9QPg0qt0PlintGDAKzUEPnP3FH6KVCnFq4T5WCE/gwCMhd/BpxAWOBZ 2jJfguL+Ys0ayteGrTWWpYmV0lGtS4ksNxN8HSvO+1FTTle+91tO2wmaTnyqvrc2zgQXXhC+sSC+ L7hKYRBZB4Tbwzd5nYXtAw==
X-Report-Abuse-To: spam@se02.mfg.siteprotect.com
Message-ID-Hash: G75ESBEPLYLPRVOOWDB6VRGBGKFSTDKZ
X-Message-ID-Hash: G75ESBEPLYLPRVOOWDB6VRGBGKFSTDKZ
X-MailFrom: huitema@huitema.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-quic.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/HUub-bhCWWk4fj3KxPT53oTThUA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Owner: <mailto:quic-owner@ietf.org>
List-Post: <mailto:quic@ietf.org>
List-Subscribe: <mailto:quic-join@ietf.org>
List-Unsubscribe: <mailto:quic-leave@ietf.org>
On 7/30/2024 5:52 PM, Paul Vixie wrote: > Do we know a reason why the system's behavior won't move beyond the new > limit the same way it moved beyond the old one? If it's some bizarre > kind of leaky bucket let's have the showdown now rather than later when > everything is larger and ossification has begun. The concern is that the wily hackers will send a single UDP "initial" packet to a server, and the the server will reply with a complete flight of packets including key exchanges, parameters and certificates. Send 1.2KB to the server, see the server send back 5, 6 or maybe 10 packets to the source IP of the UDP packet. With that the DDOS attack has been "amplified" 5, 6 or maybe 10 times. The amplification limit is there to limit the usefulness of QUIC servers for these DDOS attackers. The value 3 was chosen because with "reasonable" configurations the server's first flight fits in 2 or 3 packets, and that there are many UDP services that provide more than 3x amplification (see https://www.cisa.gov/news-events/alerts/2014/01/17/udp-based-amplification-attacks) But if we loosen the QUIC amplification limit while other services are tightening, that situation will change. -- Christian Huitema
- Proposal: Increase QUIC Amplification Limit to 5x Nick Banks
- RE: Proposal: Increase QUIC Amplification Limit t… Nick Banks
- Re: Proposal: Increase QUIC Amplification Limit t… Matthias Waehlisch
- Re: Proposal: Increase QUIC Amplification Limit t… Paul Vixie
- Re: Proposal: Increase QUIC Amplification Limit t… Christian Huitema
- Re: Proposal: Increase QUIC Amplification Limit t… Ian Swett
- RE: Proposal: Increase QUIC Amplification Limit t… Nick Banks
- Re: Proposal: Increase QUIC Amplification Limit t… Martin Thomson
- Re: Proposal: Increase QUIC Amplification Limit t… Roberto Peon