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

Marten Seemann <notifications@github.com> Wed, 26 December 2018 16:29 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 E369A13103D for <quic-issues@ietfa.amsl.com>; Wed, 26 Dec 2018 08:29:50 -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 zEPyWxBZo1EH for <quic-issues@ietfa.amsl.com>; Wed, 26 Dec 2018 08:29:48 -0800 (PST)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69360131045 for <quic-issues@ietf.org>; Wed, 26 Dec 2018 08:29:48 -0800 (PST)
Date: Wed, 26 Dec 2018 08:29:47 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1545841787; bh=n502PLBNSyf45tTjrOCj81vRmXuGlGBd/KawFPV+hc8=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=Ih/FGzxSIUKAvtU8bwWevSgPQztUH615H1tNK8x3IFXZ0DI4iBFyeZUz7XBYvE4D6 2u4OCAoKdVkUVvN5ww+egqR6wsD/0mFv7w8djkWso7k5wRMH768eg5xlcABnO5fi45 dhxtoe3XAC1uprG1ZBOkBuy49CFwVV+21gqQV/Ac=
From: Marten Seemann <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab158506048bd9fba351f68589a38eab33cd0418cf92cf00000001183b6e7b92a169ce177f0208@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@github.com>
Subject: [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_5c23ac7b32953_2ae03fdadced45bc434453"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: marten-seemann
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/VaeKTIbu0COrucfCM5--IpLNV0c>
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, 26 Dec 2018 16:29:58 -0000

An Initial packet can be made pretty small, if I counted correctly the smallest size for a valid Initial is 18 bytes. That means that if I coalesce 67 of these packets, I can fill up one UDP datagram that fulfills the minimum size requirement of 1200 byte.

A naive server implementation might first split the coalesced packet into those 67 QUIC packets, decide that it wants to do address validation and then send a Retry packet for every one of them. Considering that a token will be at least around 40 bytes long (if the server is using authenticated encryption), and that there's UDP and IP overhead, that's a nice amplification factor in itself already, in addition to the fact that the attacker just converted a single large datagram into a lot of small datagrams.
I'm not sure if this is covered by the text yet. We say that

> Prior to validating the client address, servers MUST NOT send more than three times as many bytes as the number of bytes they have received.

However, since the retries are supposed to be stateless, it's not clear how this would work.

The same applies to Version Negotiation packets. With the coalesced packet described above, a single packet could be used to elicit the sending of 67 VN packets. We currently have some text that a server MAY limit the number of VN packets it sends, but unless we come up with a better defense against this attack, I think we'll need stronger language here.

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