Re: [quicwg/base-drafts] How long is a validated address good for? (#3880)

Kazuho Oku <notifications@github.com> Thu, 09 July 2020 06:20 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 483673A0968 for <quic-issues@ietfa.amsl.com>; Wed, 8 Jul 2020 23:20:53 -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 gDwfg982-m4k for <quic-issues@ietfa.amsl.com>; Wed, 8 Jul 2020 23:20:51 -0700 (PDT)
Received: from out-24.smtp.github.com (out-24.smtp.github.com [192.30.252.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94BF13A08E4 for <quic-issues@ietf.org>; Wed, 8 Jul 2020 23:20:51 -0700 (PDT)
Received: from github-lowworker-d1d6e31.ash1-iad.github.net (github-lowworker-d1d6e31.ash1-iad.github.net [10.56.105.50]) by smtp.github.com (Postfix) with ESMTP id C34326A1D19 for <quic-issues@ietf.org>; Wed, 8 Jul 2020 23:20:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1594275650; bh=K6gPM9zRhVdbv0EQrCxJgnc/QyLohvUO+iOB48IrLlg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=w4D8ay2tXu54UiJu179BNiNoLwYAUEG45FjgS0hILWrcPbMFRBTMc7XQJEVr5L5E3 2o27dbTA3bdWSYhlKCoKyvsi55X0qWBwkI8Q9wL1JBOfBM5Q0ZOS1TqEOuS+34BioV WhWD5sQ3o89Zv6rUt775PP4r/6GSsUB43b1vQxEY=
Date: Wed, 08 Jul 2020 23:20:50 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3HU4PUNSRPLKOWWXF5CKMEFEVBNHHCN572XY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3880/655926117@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3880@github.com>
References: <quicwg/base-drafts/issues/3880@github.com>
Subject: Re: [quicwg/base-drafts] How long is a validated address good for? (#3880)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f06b742b36ab_35273f95b84cd960440542"; 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/QAhE925sKtiMzqaTOQNhxleI8EY>
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: Thu, 09 Jul 2020 06:20:53 -0000

I do not think that we need to recommend a particular value. I might even ask if there is a need to have a time-bound.

The reason we have the 3x limit prior to address validation is because it is an DDoS attack vector. Compared to that, it is much harder to use old validated paths as an attack vector. Compared to the difficulty, the benefit that the attacker gains is rather small.

For the NEW_TOKEN case, the amplifier is 10x + alpha (assuming that IW is 10 packets), less than a magnitude different from the 3x limit.

For the path migration case, the amplifier becomes maybe two magnitudes greater, but the effectiveness of the attack is limited by the idle timeout, as path migration works only when the connection is kept alive.

-- 
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/3880#issuecomment-655926117