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

Kazuho Oku <notifications@github.com> Sun, 25 October 2020 23:28 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 9EBB83A16D5 for <quic-issues@ietfa.amsl.com>; Sun, 25 Oct 2020 16:28:40 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 wO5smLJMF-1V for <quic-issues@ietfa.amsl.com>; Sun, 25 Oct 2020 16:28:39 -0700 (PDT)
Received: from out-23.smtp.github.com (out-23.smtp.github.com [192.30.252.206]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8D43A16D3 for <quic-issues@ietf.org>; Sun, 25 Oct 2020 16:28:38 -0700 (PDT)
Received: from github.com (hubbernetes-node-7ddeb4d.ac4-iad.github.net [10.52.118.69]) by smtp.github.com (Postfix) with ESMTPA id 1E803600D42 for <quic-issues@ietf.org>; Sun, 25 Oct 2020 16:28:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1603668518; bh=zefhSTFYxMygsI26NgTtQJW2DGnPjYYKqwxZOYotRNk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ig7tdGEORokdCfwhj94g4WNyObNkuTkXXvbrH9lqRvNP2/Srnf7Xb36twbsCnIabV QC/gJARqpF4MyYVrnD/nJibI+pDcbekwU6GeP3bKv0vFLX4WhmVmS66w7fEbyjGC5r WyDMfd+4/4NlHjaxe6ginnbhWNuLFuQWqH44rtQk=
Date: Sun, 25 Oct 2020 16:28:38 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7Y5W2ZX5EXCLQKU5N5UHVSNEVBNHHCWUAGFQ@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/716230658@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_5f960a2618f99_3c1519b410244d0"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/VkTjz9f3vDKWAsSZD05Z6ovQMFo>
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: Sun, 25 Oct 2020 23:28:41 -0000

> And, just so my understanding is clear, if I receive a minimum size packet (10ish byte UDP payload?) from an unvalidated path on average 1/2 x INIT_RTT, then I will be amplifying that traffic by ~100x, right?

For one unvalidated path, an endpoint would send no more than 2 MTU worth of data per every Initial RTT (333ms). Therefore, while the amplification factor will be large, the amount of traffic being sent is going to be small.

For all the unvalidated paths from which an endpoint might receive data, the upper bound would be 2 MTU multiplied by the number of paths that an endpoint can validate concurrently. From what I understand, each path validation attempt is abandoned by a timeout, that is greater than 2 seconds ([section 8.2.4](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-8.2.4-2)).

-- 
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-716230658