IETF Logo Mail Archive

Re: Fast Address Validation - about

"Qing An" <anqing.aq@alibaba-inc.com> Fri, 01 November 2019 13:31 UTC

Return-Path: <anqing.aq@alibaba-inc.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD387120147 for <quic@ietfa.amsl.com>; Fri, 1 Nov 2019 06:31:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=alibaba-inc.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 93MPb2i6uAuU for <quic@ietfa.amsl.com>; Fri, 1 Nov 2019 06:31:54 -0700 (PDT)
Received: from out0-151.mail.aliyun.com (out0-151.mail.aliyun.com [140.205.0.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6A911200CE for <quic@ietf.org>; Fri, 1 Nov 2019 06:31:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1572615109; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=JLUcJ26an3+2l15srGbtI6dcOmV8uefbdg9fW13TICY=; b=r8YXYP0mqQ0S6+aVPYgUvhTw/qOdC4lJ2DRThN9u3mHVH2ge2Qp/fDAZKD/2aItiPgl9XYkJ1lLJO4X27QFVZ6iJOLG/72ItOkxqw1gDgtDYcygmLx+wuacJtib//dpdNIySMc6l1Y1BKmrVe9eeSQZBX78qoXwB0pWZoulR1Zc=
X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R181e4; CH=green; DM=||false|; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03303; MF=anqing.aq@alibaba-inc.com; NM=1; PH=DW; RN=5; SR=0; TI=W4_5657687_v5ForWebDing_0AB10114_1572614326929_o7001c328q;
Received: from WS-web (anqing.aq@alibaba-inc.com[W4_5657687_v5ForWebDing_0AB10114_1572614326929_o7001c328q]) by e02c03267.eu6 at Fri, 01 Nov 2019 21:26:24 +0800
Date: Fri, 01 Nov 2019 21:26:24 +0800
From: Qing An <anqing.aq@alibaba-inc.com>
To: Töma Gavrichenkov <ximaera@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>, "jri.ietf" <jri.ietf@gmail.com>, mt <mt@lowentropy.net>, "刘大鹏(鹏成)" <max.ldp@alibaba-inc.com>
Reply-To: Qing An <anqing.aq@alibaba-inc.com>
Message-ID: <6ab3b6d6-7638-4b96-b2a3-4212f747a7af.anqing.aq@alibaba-inc.com>
Subject: Re: Fast Address Validation - about
X-Mailer: [Alimail-Mailagent revision 2765257][W4_5657687][v5ForWebDing][Chrome]
MIME-Version: 1.0
References: <4974ed86-0fa9-435d-880f-80af637ef180.anqing.aq@alibaba-inc.com>, <CALZ3u+YyOQxA5zBxkhDj9-wObfqjxPxPyXH9PumaW79DNkKjsg@mail.gmail.com>
x-aliyun-mail-creator: W4_5657687_v5ForWebDing_NTMTW96aWxsYS81LjAgKE1hY2ludG9zaDsgSW50ZWwgTWFjIE9TIFggMTBfMTVfMCkgQXBwbGVXZWJLaXQvNTM3LjM2IChLSFRNTCwgbGlrZSBHZWNrbykgQ2hyb21lLzc4LjAuMzkwNC43MCBTYWZhcmkvNTM3LjM2XQ
In-Reply-To: <CALZ3u+YyOQxA5zBxkhDj9-wObfqjxPxPyXH9PumaW79DNkKjsg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_80694_54efd940_5dbc3280_353e92"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/AKawDI6CbwsfnV1Lwqgz_5DtXr8>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Nov 2019 13:31:56 -0000

Right, client address validation can provide protection against floods, but today's server often has other approaches to handle floods. In this case, IMHO it is reasonable to make it possible for server to choose whether or not to use Retry for client address validation


------------------------------------------------------------------


Peace,

On Wed, Oct 30, 2019, 4:41 PM Qing An <anqing.aq@alibaba-inc.com> wrote:
[QUIC-Trans] defines a token based scheme to facilitate address validation of a client. The token MUST be covered by integrity protection against modification or falsification by clients. The server remembers the value it sends to clients and validates the token sent back from a client.

About the only use case for the client address validation I can think of is the protection against Hello packet floods exhausting the resources (including memory) on the server.

In this case keeping any state for connections coming from potentially spoofed addresses on the server compromises the very concept of flood protection.  All the state must be kept in the Retry packet and promptly signaled back by the client.

The speed-up brought in by keeping the state is probably negligible (TODO: actual measurements) while with a today's average 300Mpps packet flood hardly any state could be kept for any reasonable period of time.

--
Töma

v2.23.0 | Report a Bug | By Email