IETF Logo Mail Archive

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

Martin Thomson <notifications@github.com> Wed, 21 October 2020 20:26 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 07BE83A02BC for <quic-issues@ietfa.amsl.com>; Wed, 21 Oct 2020 13:26:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.555
X-Spam-Level:
X-Spam-Status: No, score=-1.555 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_20=1.546, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, 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 rGDssUtEH_wX for <quic-issues@ietfa.amsl.com>; Wed, 21 Oct 2020 13:26:44 -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 4C1243A0140 for <quic-issues@ietf.org>; Wed, 21 Oct 2020 13:26:44 -0700 (PDT)
Received: from github.com (hubbernetes-node-d24e072.ac4-iad.github.net [10.52.102.69]) by smtp.github.com (Postfix) with ESMTPA id E771C600F30 for <quic-issues@ietf.org>; Wed, 21 Oct 2020 13:26:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1603312002; bh=YPgv2JLPBAdHx6P5mJ7Qd757wrFRhRsfCRiitxo+YBQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ln64vo1XW2A15gfy+usgcGDG7gnQ7Y9BAvH509TgwxF3IywgM+W+2LhJdxqKCegJ5 ZmFPeMqCDatrBmsHJEeXjikxjpBI8A2tgYlddQp03s/L3E82dVWQj0MZ9IS1phm8dy 6p5nigBnVChxCgmSY7fc/0IAK2Z8rQ8LBHLhb06s=
Date: Wed, 21 Oct 2020 13:26:42 -0700
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7TO563SESWYHFPV6N5TR5IFEVBNHHCWUAGFQ@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/713857504@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_5f909982e4806_a2419b466728"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/HTQ1Nawgr501aBEELTq9QoBfBfE>
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: Wed, 21 Oct 2020 20:26:46 -0000

Can you walk through the scenario?  The server observes a NAT rebinding or migration and decides that the new client address is not validated.  It sends PATH_CHALLENGE and pads, but the packets it has received thus far are too small and therefore it immediately exceeds the 3x limit?

This seems like it might be worth fixing.  Like you, I don't have an easy answer.  If the client probes the path, there is no issue.  However, a small non-probing packet can happen and we need an answer for the server in that case.

Curiously, you could send PATH_CHALLENGE in a small packet too, but not regard any response as path validation.  The client should send PATH_RESPONSE padded and open up the server sending quota, allowing the server to properly probe.

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

v2.23.0 | Report a Bug | By Email