IETF Logo Mail Archive

Re: Fast Address Validation - about

Töma Gavrichenkov <ximaera@gmail.com> Fri, 01 November 2019 13:00 UTC

Return-Path: <ximaera@gmail.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 D2B81120125 for <quic@ietfa.amsl.com>; Fri, 1 Nov 2019 06:00: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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.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 rJ9uP3mHrVhg for <quic@ietfa.amsl.com>; Fri, 1 Nov 2019 06:00:54 -0700 (PDT)
Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8C8F12002E for <quic@ietf.org>; Fri, 1 Nov 2019 06:00:53 -0700 (PDT)
Received: by mail-yb1-xb2a.google.com with SMTP id t11so3811416ybk.10 for <quic@ietf.org>; Fri, 01 Nov 2019 06:00:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1gn2N7ydt6GtwXN500LKpSt5mYpidoqjYhSHSIPX0ts=; b=e0UzYaFnpWvGSpKkKlB/V7+j+9vRAfVyqHPzipqhup8tCggBUQgxdUvilydvH5Cn/k s4lpSnKEb80uvE4Pkf/6sckXts2WuD0iDKFxetWAt1ms/8cC1jkhJFVs1ti4C1JQmX8C UkCr/Z6IpvIBGAD3Oqa44ycZLVzDcyRnWCroYpCxZlVMH/8XhQi2qqttj6ZIHyB2yqti YUXJk9RlfM/PgQA60Uq2QvR3xfIgPl0btrR4vlyxIlFvD4dOb8GoDaALObN6isJ36zRx Hw3plY0uU84D6BB7EEV+6TTK/tYwjWRwGYY0NY81KRKQiL49rkMo2tqav+XENoPVUqZM 1hiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1gn2N7ydt6GtwXN500LKpSt5mYpidoqjYhSHSIPX0ts=; b=IVMZAfA/iQJ4CIjx/ADE0CaQSl0tB3PU6Loqc3yhxQM8I2eXdn8C3B0cpZiGKsxJAZ d5m8VcHuChx3U8e48Vne1LwpY6WaQB1TrVpIEjOq1ynxUTnmZoi/yDahdWnG7DrNZNFA 8KcwnL//Yc+LBeCDBDTkhTX/u9icDmdlnZPHO9E1IoRw8apSN3xju9/ZuK/y1mN8AAK7 z68oN58mtkMqGEHKpUeDA5TfjMXA7kcZ5DsIh+kC9pp2EMrBbPSA0INzKkLqbiVTerFw L4WFxqN2XWXBppMXk8VwYSSJ6W2qeay5+FnY3uO4aNzctkG4ELPYiDZ0j5xny9woqkDF SZcA==
X-Gm-Message-State: APjAAAVzR7ojrcGGQ9+2Zt0vQ1hHkOuj8E9QtSl3VgySxQXjsqD4Njml eUi870nBkH59jYnlr4WvbS7wn4z7uZqvyiqZUsA=
X-Google-Smtp-Source: APXvYqxxPKwdgmePPnwcTSbpNjTR9++zls++Nh3SYy/oB3SZ6R5HFbEsD8qOxUsIWwoRZRHJuP4um4Teh1DAoDfSpMo=
X-Received: by 2002:a25:db46:: with SMTP id g67mr8727708ybf.312.1572613252726; Fri, 01 Nov 2019 06:00:52 -0700 (PDT)
MIME-Version: 1.0
References: <4974ed86-0fa9-435d-880f-80af637ef180.anqing.aq@alibaba-inc.com>
In-Reply-To: <4974ed86-0fa9-435d-880f-80af637ef180.anqing.aq@alibaba-inc.com>
From: Töma Gavrichenkov <ximaera@gmail.com>
Date: Fri, 01 Nov 2019 16:00:39 +0300
Message-ID: <CALZ3u+YyOQxA5zBxkhDj9-wObfqjxPxPyXH9PumaW79DNkKjsg@mail.gmail.com>
Subject: Re: Fast Address Validation - about
To: Qing An <anqing.aq@alibaba-inc.com>
Cc: IETF QUIC WG <quic@ietf.org>, "jri.ietf" <jri.ietf@gmail.com>, mt <mt@lowentropy.net>, "刘大鹏(鹏成)" <max.ldp@alibaba-inc.com>
Content-Type: multipart/alternative; boundary="0000000000004c45ad0596488edd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Al0SEznBQQbQnmT2-EmSj6JQeWA>
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:00:56 -0000

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