[quicwg/base-drafts] Amplification attack using retry tokens and spoofed addresses (#2064)

Christian Huitema <notifications@github.com> Wed, 28 November 2018 19:47 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 74842130E14 for <quic-issues@ietfa.amsl.com>; Wed, 28 Nov 2018 11:47:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.459
X-Spam-Status: No, score=-9.459 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, 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, URIBL_BLOCKED=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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id EPLUEpsy0-3X for <quic-issues@ietfa.amsl.com>; Wed, 28 Nov 2018 11:47:00 -0800 (PST)
Received: from out-7.smtp.github.com (out-7.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F4C01277D2 for <quic-issues@ietf.org>; Wed, 28 Nov 2018 11:47:00 -0800 (PST)
Date: Wed, 28 Nov 2018 11:46:59 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1543434419; bh=eVjBLB/0jtWWttLiOS/y8muoSIxSr2Xa0iYCGjdvR9s=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=ZhuuOM+uF0/oUwPvPuK0IudgS2hcS6ANa3Sc2rS0OROC4RekGLq4D3rc6iPlTNBQJ tdX1MOBk1aVG0PEd2umSOjxMf7mQU8DunT/UY8Y1DGM0XISd2bw+21bTL/w0uLmnpK uw4WzBKRk/rotJEwUgVm7NYUkAAn61/7HE+BexMs=
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab157a44a32b07a88239be1f65b703db5430a84aeb92cf000000011816b2b392a169ce16f92d74@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2064@github.com>
Subject: [quicwg/base-drafts] Amplification attack using retry tokens and spoofed addresses (#2064)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bfef0b365453_58983fd551ed45c070820"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
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/tt9qCR5UrOUb58qSNd-RwS9Af3U>
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, 28 Nov 2018 19:47:03 -0000

We designed the Address Validation procedures to prevent QUIC servers from being used for UDP based DOS amplification attacks. By default, sending an Initial packet to a QUIC server results in up to 3 full size UDP packets sent back to the originating address, and perhaps several more if the server repeats packets on timeout. With address validation turned on, the server will only answer to Initial packets carrying a proof of origin, in the form of a "token". Once address is validated, servers are free to send many more than 3 packets in response to the Initial packets. I am concerned that the validation procedure can be bypassed with a replay attack.

Let's imagine that an attacker manages to locate itself close enough to its target to be able to observe an Initial/Retry exchange between the source address and a remote server, and obtain a copy of the Retry packet. The attacker now has enough information to manufacture an Initial packet that will pass address validation at the server, if sent from the spoofed address of the target. The attacker could then pass that information to a botnet. A large number of bots can send spoofed packets to the server, resulting in a massive attack against the target.

Whether the attack is plausible or not depends on how the server performs address validation. The current draft presents little guidance about that. If a server implementation simply verifies that the token was associated with the source address of the client, the botnet can run unimpeded. If the token also has some time to live, the attack will run unimpeded until that time. The attack will only be blocked if the server enforces that tokens are used only once, but the current draft does not require that.

I looked at how to modify the Picoquic implementation and protect against this attack. The simplest defense that I found was to embed in the ticket the Connection ID of the server. The connection ID is provided to the client as part of the retry packet, so that change is easy. Tokens could also be provided in New Token frames and sent by clients in Initial packet; the server could extract the CID from the token, and chose that for the new connection. The "server CID defense" is not perfect, but it ensures that the botnet will only be able to create one connection at a time. If tokens have a limited time to live, the attack is effectively thwarted.

I am not saying that all implementations should adopt the server CID defense. The goal is to prevent token reuse at the server, and there are certainly other ways to achieve that. I am just asking that we ask servers to prevent multiple reuses of the same token.
You can view, comment on, or merge this pull request online at:


-- Commit Summary --

  * Merge pull request #8 from quicwg/master
  * Ask servers to limit use of tokens to only once

-- File Changes --

    M draft-ietf-quic-transport.md (3)

-- Patch Links --


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: