Re: [quicwg/base-drafts] Path Challenge Padding and Amplification Protection (#4257)

Nick Banks <notifications@github.com> Mon, 26 October 2020 00:03 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6843A16F0 for <quic-issues@ietfa.amsl.com>; Sun, 25 Oct 2020 17:03:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.482
X-Spam-Level:
X-Spam-Status: No, score=-1.482 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
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 iTueQyas6EP9 for <quic-issues@ietfa.amsl.com>; Sun, 25 Oct 2020 17:03:48 -0700 (PDT)
Received: from out-24.smtp.github.com (out-24.smtp.github.com [192.30.252.207]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 287373A115E for <quic-issues@ietf.org>; Sun, 25 Oct 2020 17:03:48 -0700 (PDT)
Received: from github.com (hubbernetes-node-441b475.ac4-iad.github.net [10.52.113.61]) by smtp.github.com (Postfix) with ESMTPA id 42685600D8A for <quic-issues@ietf.org>; Sun, 25 Oct 2020 17:03:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1603670627; bh=oaX5jQV0gvyn82ZZoPipRYNy2INRefyr96OrHK4E8lU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=c3M0FuR/uNRFVZEv1G9BzM/YJMomI+SyU7FKS2emm7Uza13EkrYly5vElsvAaVX0s avmsI/iwspHXUYJ5yQJY2EdkyeT2Y09r1bzrbyMALXf0qXYMZMZRGwzcLqinVhbEO8 OQhgi+GWl39WngzXy0dbEvGenW4BEogAaqXg6+P4=
Date: Sun, 25 Oct 2020 17:03:47 -0700
From: Nick Banks <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7J22LVV3JITRPFGKN5UHZWHEVBNHHCWUAGFQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/4257/716235518@github.com>
In-Reply-To: <quicwg/base-drafts/issues/4257@github.com>
References: <quicwg/base-drafts/issues/4257@github.com>
Subject: Re: [quicwg/base-drafts] Path Challenge Padding and Amplification Protection (#4257)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f9612633e836_7a3519b4568552"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nibanks
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/fwjjIpKI-BBBXMkISSTA-MgY6ss>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Oct 2020 00:03:50 -0000

Ok. I did some excel math to get a more accurate number, and it seems at least for IPv4, the amplification ratio is closer to 25x. To make use of this though, as you indicated Kazuho, the attacker would be limited by the 2 MTU, per unvalidated path.

Assuming a server tracks only 4 paths max, per connection, and an attacker opens 1000 connections to the server and uses them as an amplification vector, the attacker can send packets at less than 10Mbps to get almost 250 Mbps send to the target. Do this with a couple different servers (which ever you find to track the most parallel paths) and I'd say you have a pretty good attack vehicle.

And as I mentioned above, a MoTS can copy/modify/race valid connection traffic to achieve similar results.

Obviously getting a connection to the handshake confirmed state before it can be used as an amplification vector is a hurdle, but I wouldn't say it a very large one. The attacker can open connection to **many** different servers to mask it's attack origin somewhat. IMO this still seem like a very valid threat we at the very least should mention in the spec, if not actually fix.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4257#issuecomment-716235518