Re: [quicwg/base-drafts] amplification attack using Retry and VN triggered by coalesced Initial packets (#2259)

Kazuho Oku <notifications@github.com> Tue, 01 January 2019 06:09 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 31E6712D84D for <quic-issues@ietfa.amsl.com>; Mon, 31 Dec 2018 22:09:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.065
X-Spam-Level:
X-Spam-Status: No, score=-8.065 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 rXq35K5T4b1m for <quic-issues@ietfa.amsl.com>; Mon, 31 Dec 2018 22:09:38 -0800 (PST)
Received: from out-7.smtp.github.com (out-7.smtp.github.com [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2839A12D4EF for <quic-issues@ietf.org>; Mon, 31 Dec 2018 22:09:38 -0800 (PST)
Date: Mon, 31 Dec 2018 22:09:35 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1546322975; bh=x0qJIQ/wqX5s1wz7mp4cJl0gy/wE72ZJl/oOzP4UDzI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=KyffZo2Np3JZajnz3+IyGoniaP/kY1laIj0de4bDV5AgK9E2xSmXwr9yMb2RbH1km 33E2CI/UA/l39YUZQrgicc/XrHfswYdkd4kPG4RkNLAqTiPju0vsSV1DT0cA4To5cw V29cNzv9cZ8ymrtgboG5Sza8YgURk5oRxO8EnD5Q=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abc3e9368d97c00a7f18eb7dd5cde2314a022fafb092cf000000011842c61f92a169ce177f0208@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2259/450711758@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2259@github.com>
References: <quicwg/base-drafts/issues/2259@github.com>
Subject: Re: [quicwg/base-drafts] amplification attack using Retry and VN triggered by coalesced Initial packets (#2259)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c2b041fd0bda_2b213ffcd16d45bc3030d3"; 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/phJqp_AzSBQ43BCa0Co0dcTLgR4>
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: Tue, 01 Jan 2019 06:09:40 -0000

> State is exactly what I'm concerned about. I'd like to avoid allocating state for 67 QUIC packets due to a single datagram. With my proposed requirement, you can at most have 4 QUIC packets per datagram.

I do not get the same numbers.

With @martinthomson's approach, an endpoint needs one boolean when parsing a datagram. The value is flipped when you send a Retry, and prohibits the rest of the packets belonging to the same boolean from issuing another Retry.

With your proposal, an endpoint needs to maintain at least four booleans to detect if any of the packets have been seen more than once in a datagram.

Therefore, I think that @martinthomson's approach requires less state.

> I haven't implemented PMTUD yet, and as far as I can see, the PMTU section doesn't say anything about coalesced packets.

In Kista, we discussed about prepending long header packets (that do not authenticate) that contain enough information for the load balancer to forward ICMP response to the server.

-- 
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/2259#issuecomment-450711758