IETF Logo Mail Archive

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

Nick Banks <notifications@github.com> Wed, 04 November 2020 15:45 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 BCA743A135D for <quic-issues@ietfa.amsl.com>; Wed, 4 Nov 2020 07:45:13 -0800 (PST)
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 8Yb5xNVgWP8f for <quic-issues@ietfa.amsl.com>; Wed, 4 Nov 2020 07:45:12 -0800 (PST)
Received: from smtp.github.com (out-17.smtp.github.com [192.30.252.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FFA23A137B for <quic-issues@ietf.org>; Wed, 4 Nov 2020 07:45:12 -0800 (PST)
Received: from github.com (hubbernetes-node-78109f1.va3-iad.github.net [10.48.22.22]) by smtp.github.com (Postfix) with ESMTPA id B757D5C0E9B for <quic-issues@ietf.org>; Wed, 4 Nov 2020 07:45:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1604504711; bh=SWU3axijAKkjuWNwY8v1chkpIDzo6e/0wYzZEIe+4UY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=RrmdnyMVjMkyGim7N3bGezfe1LN3vQgqhpBoTBNgcUjS782Hulv5Icl1Ou/KFBbOG OkKUFd9xF8S38RvUdKcV2IDUksiism5QfWqY6lqJQDW6eyG4iAYHu7Ss1cw1hNvWRX vfPt6KZnoWGibm1AbI79ivoz3heX7MtqkeW61D+Q=
Date: Wed, 04 Nov 2020 07:45:11 -0800
From: Nick Banks <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYKEXIJH7JSVW5WTS55V2WYPEVBNHHCWUAGFQ@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/721809411@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_5fa2cc87b46aa_503c19b4332745"; 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/6Otpa0z8XdQRYpJIUsYYNEpzIfI>
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, 04 Nov 2020 15:45:18 -0000

I agree with the sentiment that NAT rebinding is an edge case and it likely to have all sorts of performance related issues, and we don't really need to try to optimize for them. I personally think mentioning the known problems an possible solutions would be nice though.

The only real problem I left is that is seems there is some confusion (as seen from my discussion with Kazuho on the PR) about amplification protection and its relation to port-only NAT rebinding. Is it an exception to the rule or not? I didn't see any specific text on this one way or the other in the latest PR last I look, and I think it might be worth while to have some.

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

v2.23.0 | Report a Bug | By Email